Мы согласовывали релизный процесс три раза: я рисовал схемы, объяснял, куда вливать изменения и кто решает о продвижении релиза. Но правила всё равно приходилось объяснять снова: одни путали ветки, другие порядок действий, третьи не хотели их выполнять. Я чувствовал себя надзирателем.

Тогда я перестал напоминать и перенёс регламент в GitLab. Ключ — имя ветки `стадия/версия`, например `alpha/1.64.0`. Стадия и версия в имени дали CI однозначный сигнал, а у каждой задачи в Jira заранее указана версия релиза.

На каждый MR запускается скрипт `jira:check`. Он сверяет версию задачи с версией целевой ветки и статус задачи. Вот реальный отказ из лога: задача размечена в версию 1.65.0, а MR идёт в `develop/1.66.0`. MR создать можно, влить нельзя, пока данные не исправлены.

После слияния CI сам собирает нужный вариант, загружает APK в нужный контур, формирует release notes, отправляет ссылку тестировщику и переводит задачу в «К тестированию».

Людей это не отменило. Решение о переходе на следующую стадию, новые переменные следующего контура и выпуск в production остаются за человеком. CI проверяет номер версии, но не знает, на какой стадии релиз сейчас.

Правило, которое машина проверяет однозначно, не должно держаться на памяти лида.

В полной статье разобрал, как всё устроено: проверки, защита веток, выбор сборки по ветке и где автоматизация сознательно заканчивается: https://hram.github.io/articles/hram-git-flow-ci/