Rose debug info
---------------

От задачи к релизу

В предыдущем посте я описал как выглядит Jira Workflow и пайплайн задач в кросс-функциональной команде разработки. В этой заметке, которая писалась как шпаргалка для внутреннего использования, вы найдете более полное описание процесса от момента постановки задачи до ее релиза для конечного пользователя. А еще, она точно не понравится адептам канонического Scrum.

Команда состоит из:

  • Владельца продукта
  • Delivery-менеджера
  • Тимлида
  • Двух бэкенд-разработчиков
  • Двух фронтенд-рабработчиков
  • QA
  • DevOps-инженера

Используются следующие инструменты:

  • Jira — таск-трекер
  • Confluence — командная Wiki
  • Slack — основной месседжер
  • Gitlab — управление репозиториями кода и CI + CD
  • Artifactory — репозиторий пакетов и Docker-образов
  • Sentry — отслеживание исключений
  • EFK — стек для сбора и обработки логов
  • Prometheus + Graphana — метрики
  • OpenShift — PaaS для cloud-native окружения

Теперь о процессе. Самое важное — у каждого шага пайплайна есть владелец, который мониторит его выполнение и проталкивает дальше по цепочке.

Требования к задаче

Каждая задача имеет как минимум:

  • Внятное короткое название
  • Развернутое описание, желательно со ссылками на спецификацию и дополнительные материалы
  • Компонент: бэкенд, фронтенд, инфраструктура
  • Исполнителя

Планирование и спринт

Задача привязана к эпику, эпик привязан к цели, цель — важная.

Владелец: product owner ⇢ delivery manager ⇢ тимлид.

Очередь работ

Общий процесс:

  • В бэклог проекта (не спринта) могут добавляться задачи в любой момент времени.
  • Product Owner определяет видение и будущие цели, которые разворачиваются в эпики (большие изменения).
  • На основе эпиков предварительно создаются спецификации.
  • Обсуждение спецификаций доступно всей команде, автор спецификации может обозначить SLA, по прошествию которого все обсуждения будут закрыты, т. е. спецификация считается готовой к реализации.
  • В конце текущего спринта (последний рабочий день) команда планирует новый спринт на основе эпиков, отдельно взятых задач и задач, которые остались невыполненными в текущем спринте (их приоритет может быть пересмотрен).
  • Владелец продукта и delivery manager определяют продуктовую цель спринта → создание спринта в Jira с указанием цели спринта на Scrum-доске.
  • В процессе планирования выполняется декомпозиция и оценка задач командой.
  • Для того, чтобы внести задачу в спринт, необходимо:
    • Понять суть задачи ⇠ выяснить непонятные моменты, поговорить с коллегами, дополнить описание и документацию
    • Проставить приоритет
    • Добавить оценку в сторипойнтах (числа Фибоначчи)
    • Выбрать спринт, сменить статус с Backlog на Todo, иначе она не будет отображена на Scrum-доске
    • Delivery manager стартует новый спринт в понедельник в 12:00

😲 Нужно сделать

Владелец:

  • на этапе формирования: delivery manager ⇢ тимлид ⇢ члены команды
  • на этапе спринта: QA ⇢ delivery manager / тимлид ⇢ члены команды

Данная колонка содержит бэклог спринта и формируется на основе предварительного планирования и декомпозиции. После старта спринта в нее могут добавляться только задачи высокого приоритета, например, неотложные баги.

Исполнитель выполняет задачи в рамках указанного приоритета. За актуальностью следят владельцы бэклога, однако любой член команды в праве обсудить и аргументировать свое видение порядка выполнения задач.

Крайне желательно избегать внеплановое пополнение спринта задачами на разработку новой функциональности. Такая ситуация может возникать в рамках плохого планирования и оценки. Под этим также понимается взаимодействие компонент проекта, например, бэкенда (API) и представления (фронтенд).

На данном этапе QA уже может начинать работу над тест-кейсами.

Совет: настроенные фильтрами позволяют увидеть статус по каждому члену команды.

💪🏻 В работе

Владелец: исполнитель задачи.

Задача, над которой в данный момент работает исполнитель, имеет соответствующий статус. В работе у исполнителя может быть одновременно не более двух задач. Идеальная ситуация — фокус на одной задаче.

Если задача заблокирована какими-то внешними факторами, то она должна быть возвращена в колонку «😲 Нужно сделать» с указанием причины в комментариях. При возникновении внутренних факторов, следует указать на них на ежедневном стендапе или в командном чате.

📝 Ревью

Владелец: ревьювер.

Исполнитель задачи после ее выполнения оформляет merge request в Gitlab согласно заданному шаблону, убеждается в том, что на CI выполнены успешно все шаги сборки и назначает подходящего по его (ее) мнению ревьювера. Задача переходит в статус «📝 Ревью» и остается в нем до тех пор, пока автор не внесет правки согласно комментариям ревьювера и изменения не будут одобрены для тестирования. Достаточно одного одобрения 👍🏻

SLA на ревью:

  • блокер: 1 час — автор изменений связывается лично с ревьювером в общем чате
  • высокий приоритет: 3 часа
  • нормальный приоритет: 1 день

На ревью должно накапливаться не более трех открытых MR.

Аналогичный процесс может быть не только для технических задач, но и, например, для спецификаций и документации.

После получения одобрения изменений ветка сливается с мастером (squash commits, fast forward merge) и MR автоматически закрывается. Задача в Jira переходит в статус «К тестированию», на нее назначается дежурный разработчик.

Совет: при создании MR Gitlab автоматически берет в качестве заголовка заголовок первого коммита. Поэтому старайтесь писать понятные и короткие сообщения коммитов. В большинстве ситуаций за сообщение коммита можно взять название задачи из тикета Jira.

🎩 Дежурные разработчики

Меняются каждую неделю как со стороны бэкенда, так и со стороны фронтенда.

Задачи:

  • следить за SLA ревью
  • следить за событиями в Sentry, приоритизировать их с командой и при необходимости заводить задачи в Jira
  • собирать и разворачивать сборки для тестирования или по запросу членов команды
  • уведомлять о релизах в канале
  • переводить задачи на QA
  • собирать и разворачивать сборки для продакшен-окружения

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

🟡 Разворачивание на тестовом окружении

Владелец: разработчик, вмерживающий ветку в master.

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

Сборка и деплой на staging-окружение выполняется автоматически в рамках CI/CD при мерже в master.

Следует также учитывать fullstack-задачи, в случае которых бэкенд и фронтенд должны быть доставлены единовременно. В такой ситуации дежурные разработчики совместно обдумывают и выполняют план одновременного разворачивания приложений.

Релиз в Jira

  1. Создать новый релиз с тэгом, соответствующим Docker-образу (префикс компонента не требуется)
  1. Проставить релиз в поле «Исправить в версиях:» всех развернутых задач
  1. Скопировать информацию о релизе из Jira и отправить в канал #releases: в списке релизов кликнуть на версию → на странице релиза нажать ссылку «Описание релиза» → скопировать описание:
  1. Отправить скопированные release notes в канал.

После разворачивания новых изменений и информирования о релизе в канале #releases задачи в Jira назначаются на QA.

🔅 К тестированию

Владелец: QA.

Перед стартом тестирования QA проверяет:

  • Наличие всей необходимой информации по задаче — от описания до документации от разработчиков. Также полезно посмотреть на merge request в Gitlab и % покрытия тестами.
  • Развернута ли задача на тестовом окружении, см. канал #releases

🐹 Тестирование

Владелец: QA.

Тест-кейсы создаются в отдельной системе.

Все найденные дефекты указываются в комментариях к оригинальной задаче. Проблема должна быть внятно описана, указано окружение (ОС, браузер, разрешение экрана и пр.), при необходимости добавлены скриншоты.

Если недочеты мелкие и не влияют напрямую на реализованную функциональность, то они могут быть вынесены в отдельные задачи в будущих спринтах с сохранением ссылки на оригинальную задачу.

  1. Успешно протестирования задача получает статус «Готово к релизу».
  2. Задача, по которой найдены дефекты, получает статус «Нужно сделать», и итерация начинается с начала

В обоих случаях задача назначается на исполнителя, который над ней работал. Тестирование на этом заканчивается.

🚢 Готово к релизу

Владелец: дежурные разработчики.

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

🟢 Релиз

Владелец: дежурные разработчики.

Не блокирующие друг-друга фронтенд и бэкенд могут развертываться независимо.

Развертывание релиза в prod осуществляется в рамках CI/CD, но, в отличии от развертывания на staging, только по ручной запуску соответствующего job’а в pipeline Gitlab.

После сборки и успешного деплоя:

  1. статусы задач меняются на «Выполнено»
  2. релиз в Jira выпускается: список релизов → ... (действия) → выпустить (желательно указать дату релиза)
  3. копируются release notes (см. выше)
  4. создается уведомление о релизе в канале #releases со списком доставленных для конечного пользователя задач
  5. привлекается QA (при желании и команда) для базового тестирования самой критичной с точки зрения конечного пользователя функциональности:
    1. Успешная аутентификация в портальной части / CMS
    2. Свой профиль
    3. На главной отображается список всех новостей
    4. Доступно главное меню
    5. ...

Найденные на этом этапе дефекты заводятся новыми задачами.

В случае серьезного сбоя после развертывания изменений есть возможность откатиться на предыдущий тэг Docker-образа. Однако, для бэкенда необходимо поддерживать downgrade-миграции схемы данных.

🔥 Hotfixes

Если после выкатки релиза на прод обнаруживается наличие какого-то бага, который необходимо срочно поправить, то необходимо выполнить fix в коде, смержить его в master и тегнуть как v.0.59.1 , где .1 — номер фикса. После того, как pipeline выполнит сборку образов запустить job’ы раскатки этого фикса на prod’e. Оформлять новый релиз при этом не нужно.

Обратите внимание, что выполнить сборку фикса для prod можно не только из ветки master, но и ветки hotfix’a, не дожидаясь код-ревью. Для этого необходимо также как и описано выше назначить тег нужному коммиту в ветке hotfix’a.

🍾 Выполнено

Владелец: дежурные разработчики.

Развернутые на продакшен-окружении задачи. На этом цикл разработки заканчивается.

🆘 Управление рисками

Владелец: исполнитель.

Советы:

  • Всегда следите за ситуацией.
  • Если кажется что что-то идет не так, копните глубже и подумайте, как это можно сгладить — предлагайте варианты команде / менеджеру.
  • Все должны понимать все части проекта на высоком уровне — от сайта до влияния на бизнес.
  • Документирование стека, подходов, узких мест обязательно.
  • Когда работаете над новой задачей и делаете ее оценку, сначала сделайте небольшое исследование, проясните непонятные моменты и выставьте оценку с учетом рисков.
  • Честно подсвечивайте риски по мере их возникновения — это самое лучшее время. Второе лучшее время — это сейчас, а не позже.
Поделиться
Отправить
Запинить
 3760   7 мес   Менеджмент