Ответ
Мы работали по адаптированной под DevOps-культуру методологии, сочетающей Scrum для планирования и Kanban для оперативной работы инфраструктурной команды.
Ключевые элементы процесса:
- Планирование: Двухнедельные спринты с планированием (Sprint Planning), где мы, как DevOps-инженеры, брали в бэклог задачи по инфраструктуре, автоматизации, безопасности и поддержке пайплайнов разработчиков.
- Ветвление и код: Использовали упрощенный GitFlow. Каждая фича или багфикс создавались в отдельной ветке от
develop. Обязательным этапом был Merge Request (MR) в GitLab. - Code Review: Каждый MR требовал апрува минимум от одного коллеги. В ревью мы уделяли внимание не только коду Terraform/Ansible, но и безопасности (Secrets в коде?), корректности CI-конфигурации и соответствию стандартам.
- Непрерывная интеграция/доставка (CI/CD): Пуш в ветку автоматически запускал пайплайн: линтинг (
terraform validate,hadolint), сборку образов, прогон тестов инфраструктуры (Terratest,kitchen-ci). Успешный MR вmainавтоматически запускал деплой в staging, а в prod — после ручного подтверждения. - Оперативная работа (Kanban): Для инцидентов, срочных запросов на конфигурацию или задач мониторинга мы использовали доску Kanban в Jira (столбцы: To Do, In Progress, Review, Done), что позволяло гибко реагировать на потребности.
- Коммуникация и документация: Ежедневные стендапы на 15 минут. Вся документация по инфраструктуре (схемы, runbooks, процедуры аварийного восстановления) велась в виде Markdown-файлов в том же Git-репозитории, что и код (docs-as-code).
Пример типичной задачи в спринте: "Автоматизировать создание изолированных preview-окружений для каждой feature-ветки с помощью Helm и GitLab CI Dynamic Environments".