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

марта 28, 2021· #менеджмент #jira

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

Состав команды

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

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

Задачи:

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

Инструменты

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

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

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

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

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

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

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

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

Story Map

Пайплайн

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

Владелец:

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

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

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

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

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

Быстрые фильтры

💪🏻 В работе

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

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

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

📝 Ревью

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

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

SLA на ревью:

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

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

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

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

🟡 Деплой для QA

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

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

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

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

📥 Релиз в Jira

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

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

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

Владелец: QA.

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

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

Владелец: QA.

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

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

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

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

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

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

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

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

🟢 Релиз

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

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

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

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

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

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

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

🔥 Hotfixes

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

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

🍾 Выполнено

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

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

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

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

См. Риск-менеджмент в продуктовой команде

Содержание
Состав команды
Дежурные разработчики
Инструменты
Требования к задаче
Планирование и спринт
Общий процесс
Пайплайн
- 😲 Нужно сделать
- 💪🏻 В работе
- 📝 Ревью
- 🟡 Деплой для QA
- 📥 Релиз в Jira
- 🔅 К тестированию
- 🐹 Тестирование
- 🚢 Готово к релизу
- 🟢 Релиз
- 🔥 Hotfixes
- 🍾 Выполнено
Управление рисками