Как мы перестали деплоить на костылях: релизный workflow в Jira с нуля

Реальный кейс внедрения релизного процесса: 8 статусов, кастомные поля, роли и таймлайн

Я пришла в новую команду и сильно задумалась, так как текущие процессы напомнили мне "режим тушения пожаров", где деплой зависит скорее от случая, чем от регламента.

Главным препятствием для развития стал релизный процесс — а точнее, его отсутствие. За несколько недель мы нашли время, сели и спроектировали workflow в Jira, который перевернул всё. В этой статье — готовая схема, которую можно брать и внедрять.
Опубликовано: 03/05/2026

Кому пригодится эта статья

  • PM и тимлидам — чьи релизы похожи на русскую рулетку
  • DevOps-инженерам — кто устал от "а давай ещё один хотфикс"
  • Руководителям — кто хочет прозрачности и предсказуемости

Executive Summary

Команда работала почти без сна. Релизы были хаотичными, сроки — непредсказуемыми, а ответственность размытой. Мы внедрили структурированный релизный процесс в Jira, который:

  • Убрал неопределённость — каждый знал, на каком этапе релиз
  • Добавил прозрачности — все зависимости и блокировки стали видны
  • Снизил аварийность — обязательный Approve и пост-релизная проверка
  • Позволил измерять — время в статусах, даты, даунтайм

В этой статье — готовая схема workflow, роли и таймлайн.

Содержание

Признаки того, что релизный процесс сломан

До внедрения мы жили с этими симптомами:

  • Неопределённость сроков — "когда обновим? не знаем, мы заблочены другой командой"
  • Спонтанные доп. работы — "добавим одно, ещё одно, и ещё..." сроки поехали
  • Человеческий фактор — при обновлении могли что-то не учесть
  • Потеря аналитики — никто не знал, сколько времени уходит на подготовку, релиз и пост-фиксы

Если вы узнали себя — читайте дальше.

Что мы внедрили: два типа задач

В Jira мы ввели два новых типа задач:

  • Deployment — родительская задача на релиз в целом
  • Deploy — дочерняя задача на конкретный кластер/сервис

Deployment создаётся один на релиз. Deploy — на каждый компонент, который нужно обновить. Задачи связываются связью Parent-Child, а технические зависимости фиксируются через Depends On / Is blocked by.

В Jira мы ввели два новых типа задач

8 статусов, которые спасли команду

Весь релизный цикл проходит по строгой последовательности статусов. Никаких "перепрыгнуть" — только шаг за шагом.

СтатусКто делаетКратко о действиях
1. ЧерновикИнженер релизаСоздаёт задачу, проставляет зависимости, заполняет поля
2. На утвержденииРуководитель командыПроверяет чек-лист, подтверждает объём работ
3. ЗапланированоИнженер релизаПубликует анонс, фиксирует точное время
4. ПодготовкаИнженер релизаСоздаёт саб-таски, формирует pre-flight чек-лист
5. К исполнениюИнженер релизаФинальная проверка, Bake Period (для первого кластера)
6. Сам деплойИнженер + дежурныйВыполнение деплоя, фиксация Start Date
7. Проверка после рализаИнженер релизаПроверка метрик, линковка инцидентов
8. ЗакрытоИнженер релизаРезолюция: Готово / Отменено
В Jira мы ввели два новых типа задач

Ключевые правила на статусах

Черновик → Согласован

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

Согласован → Запланирован

Руководитель комманды проверяет, что все доп. работы прилинкованы, а финальный анонс опубликован. Approve — зелёный свет.

Запланирован → Подготовительные работы

Задача не может перейти дальше, если у неё есть открытые блокировки (is blocked by).

В плане → Релиз

Для первого кластера в цепочке обязателен тестовый период. Пока не прошёл — последующие задачи не трогаем.

Проверка после рализа → Готово

Нельзя закрыть задачу, пока есть открытые связанные инциденты.

Важное правило про Отменено

Задачу с резолюцией Отменена переоткрыть нельзя. Только новая задача с новым циклом согласования. Это гарантирует чистоту истории изменений.

Кастомные поля для сбора данных

Без данных мы не можем улучшать процесс. Вот какие поля мы добавили в типе Deploy:

ПолеНазначениеКогда заполняется
Планируемая дата началаПлановая дата началаЧерновик
Планируемая дата окончанияПлановая дата окончанияЧерновик
Простой началсяДата начала простояПо факту
Простой закончилсяДата завершения простояПо факту
Дата началаФактическое время начала деплояАвтоматически при переходе в релиз
Дата окончанияФактическое время завершения работПри переходе в проверку после релиза
ВремяСуммарное затраченное времяАвтоматически / вручную

Роли и ответственность

РольОтветственность
Инженер релизаСоздание координационного инцидента. Заполнение дат и простоя. Выполнение работ по инструкции. Прохождение чек-листов. Парное дежурство.
Руководитель командыВалидация состава работ. Принятие решения о готовности к деплою. На утверждении → Запланировано.
Руководитель проектов/продукта/процессовВедение аналитики по Time Spent. Улучшение процесса. Контроль соблюдения workflow.

Сколько что должно длиться: таймлайн

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

СтатусЦелевой таймлайн
Draft (Черновик)5 дней
Approve (На утверждении)4 часа
Planned (Запланировано)4 часа
Preparing (Подготовка)4 часа
ToDo (К исполнению)4 часа
Deploy (Деплой)2 дня
Post-Release Check2 дня

* Таймлайн зависит от специфики вашей инфраструктуры. У нас были кластеры, требующие длительного Тестового периода.

Что изменилось после внедрения

  • Регулярность и прогнозирование — теперь все знают даты релизов и длительность даунтайма
  • Прозрачность — цепочка зависимостей кластеров и связанные работы чётко зафиксированы
  • Снижение аварийности — Bake Period и чек-листы предотвращают деградацию сервисов
  • Контроль качества — обязательный Approve, пост-релизная аналитика и поддержка

И главное — команда перестала работать по ночам.

Вывод

Релизный процесс — это не бюрократия. Это каркас, на котором держится предсказуемость и стабильность.

Если вы узнали свою команду в признаках сломанного процесса — не ждите. Соберите ключевых людей, нарисуйте workflow, настройте статусы в Jira. Начните с малого: Draft → Approve → Deploy → Closed. А потом доращивайте.

Наша схема — не истина в последней инстанции, но отличная отправная точка. Берите, адаптируйте под себя и переставайте деплоить на костылях.

FAQ

Как начать внедрение релизного процесса с нуля?

Начните с анализа текущих проблем: соберите команду, обсудите боли. Затем создайте минимальный workflow из 3-4 статусов (Draft, Approve, Deploy, Closed). Добавьте обязательные поля для дат и зависимостей. Постепенно расширяйте процесс, добавляя чек-листы и роли.

Что делать, если команда сопротивляется новым процессам?

Показывайте пользу на примерах: как процесс сокращает ночные дежурства и повышает предсказуемость. Вовлекайте команду в проектирование workflow. Начните с пилотного релиза, чтобы доказать эффективность. Не навязывайте — объясняйте преимущества.

Как измерить эффективность релизного процесса?

Отслеживайте метрики: время в статусах, количество инцидентов после релиза, процент успешных деплоев, время простоя. Сравнивайте показатели до и после внедрения. Регулярно анализируйте данные для улучшения процесса.

Нужно ли автоматизировать релизный процесс?

Автоматизация желательна, но не обязательна с самого начала. Начните с ручного процесса в Jira, чтобы отработать логику. Затем добавляйте автоматизацию: автоматическое заполнение полей, уведомления, интеграцию с CI/CD. Это повысит скорость и снизит ошибки.

Об авторе

Я проектный менеджер с 15-летним стажем. Начинала разработчиком, прошла путь до тимлида, а затем в управление проектами в enterprise-компаниях.

В этом блоге делюсь опытом, который проверила на себе. Без воды, только практика.

Читайте также:

Ключевые цифры внедрения

8 статусов в workflow
3 ключевые роли
7 кастомных полей
100% прозрачности

Главный вывод: хаос в релизах — это не норма. Даже самая простая структура лучше её отсутствия. Начните с трёх статусов, потом доращивайте до восьми. Главное — начать. В следующей статье — как распределить ответственность в команде. (RACI матрица)