Rail Sakhaviev

Задание №2 - Описание жизненного цикла задачи (разработки нового функционала)

Методология работы в команде

Scrum или Kanban или Waterfall.

Мой идеальный вариант жизненного цикла задачи такой:

• В проекте появилась UserStory, ее поставил PM.

• Макет дизайна уже готов и согласован заказчиком, изменения дизайна возможно будут, но в адекватных пределах.

• DevTeam ознакомилась с user-story, по мере необходимости создает подзадачи уже самостоятельно.

• DevTeam разрабатывает функционал.

• DevTeam проводит код-ревью нового функционала.

• DevTeam покрывает функционал unit-тестами.

• DevTeam покрывает функционал сквозными-тестами(cypress). P.S.: для frontend.

• Задача выкладывается на staging-environment из feature-ветки.

• Прогоняются тесты.

• QATeam берут задачу в работу и проводят ручное тестирование до тех пор пока функционал не будет соответствовать требованиям качества QATeam идет цикл его доработки и тестирования.

• QATeam пишут интеграционные тесты.

• Задача мержится в dev-ветку и уходит на staging-environment.

• Происходит показ клиенту.

• Прогоняются тесты.

• QATeam берут задачу в работу и проводят тестирование в dev-ветке.

• PM показывает результат заказчику.

• Задача мержится в master-ветку и уходит на production-environment.

• Задачи DevOps-инженера в данном цикле разработке:

• Настройка инфраструктуры: staging-environment, production-environment.

• Настройка pipeline(автоматизация развертывания изменений).

• Настройка систем мониторинга.

• Контроль здоровья приложений.

• Реагирование на ошибки.

ПРО ИНФРАСТРУКТУРУ

Инфраструктура проекта будет на Kubernetes + cloud UI для Kubernetes. Поскольку это K8S - все проекты будут Docker’изированы. Образы и их версии будут храниться в хранилище облака.

Облако предоставляет возможность максимально просто и быстро через UI обновлять образы.

Сам по себе K8S позволяет работать с zero down-time access обновлением образов.

ПРО КОНТРОЛЬ ВЕРСИЙ

Код будет храниться в git на github/gitlab.

Методология работы с системой контроля версий - git-flow. Это подразумевает что будут следующие ветки:

master - для production environment dev - для staging environment feature - для development ПРО PIPELINE

Pipeline будет сконфигурирован так чтобы автоматически собирать новые образы из кода и пушить их в репозиторий образов с новым тегом. Тег образа будет определять его версию.

staging/production стенды будут обновляться при получении образов приложений новых версий. Триггер на staging - при слиянии в ветку в dev Триггер на production - при слиянии в ветку master

ПРО DEVELOPMENT-environment

Типовой интернет-магазины будет иметь в себе как-минимум следующие сервисы: backend-container, frontend-container, database-container.

При разработке не всегда с фичей идут изменения во все сервисы.

Для того чтобы тестировать фичи из feature-веток можно создать несколько дополнительных изолированных тестовых стендов и в них изменять необходимые образы вручную и тестировать.

ПРО ЛОГИРОВАНИЕ

Для меня идеально было бы чтобы все ошибки nginx(и от приложений которые выведены куда-то отдельно, например, sentry или обработанные в try/catch ошибки) валились в отдельный канал в slack или в telegram.

При возникновении определенной одной и той же ошибки более 100 раз, чтобы срабатывал триггер и отправлял мне на email сообщение с деталями, системно повторяющий баг.

В идеальном мире ошибок не должно быть на production, но такого не бывает. Такой контроль поможет увеличить uptime и надежность приложения.

ПРО ОСТАЛЬНОЕ

Terraform, Ansible, Prometheus, Sonarqube.