Когда пайплайн должен остановиться и ждать человека?

Представьте: у вашей команды отлаженный CI/CD пайплайн. Тесты запускаются автоматически. Сканеры безопасности проходят. Код собирается и разворачивается на стейджинге без участия человека. А затем, прямо перед выкатом в продакшен, пайплайн замирает. Приходит уведомление: «Требуется утверждение».

Кто-то должен нажать «Approve», чтобы деплой продолжился. Возможно, это ваш техлид. Или инженерный менеджер. А может, они сейчас на совещании или уже ушли на день. Деплой висит и ждёт.

Этот момент вскрывает напряжение, знакомое каждой команде. Насколько пайплайн должен решать самостоятельно? И когда ему стоит остановиться и попросить человека принять решение?

Два вида проверок

В каждом пайплайне есть контрольные точки. Прежде чем изменение перейдёт на следующий этап, что-то проверяет, безопасно ли продолжать. Эта контрольная точка может быть одного из двух типов: автоматический шлюз или ручное утверждение.

Автоматический шлюз — это проверка, которая выполняется внутри пайплайна без участия человека. Пайплайн запускает набор тестов или валидаций, а затем решает, может ли изменение двигаться дальше. Например, после того как разработчик запушил новый код, пайплайн запускает юнит-тесты. Если все тесты проходят, изменение продолжает путь. Если какой-то тест падает, пайплайн останавливается и уведомляет команду.

Ручное утверждение — это решение, принимаемое человеком. Обычно это ведущий инженер, техлид или кто-то, ответственный за конкретное окружение. Они просматривают изменение, оценивают контекст и либо утверждают, либо отклоняют его. Пайплайн ждёт, пока решение не поступит.

Оба подхода служат одной цели: не допустить продвижения плохих изменений. Но работают они принципиально по-разному.

Диаграмма ниже показывает, как эти два вида проверок встраиваются в пайплайн развёртывания:

flowchart TD A[Изменение попадает в пайплайн] --> B{Автоматический шлюз?} B -->|Да| C[Запуск автоматических проверок] C --> D{Успешно?} D -->|Да| E[Переход на следующий этап] D -->|Нет| F[Остановка и уведомление команды] B -->|Нет| G{Ручное утверждение?} G -->|Да| H[Ожидание решения человека] H --> I{Утверждено?} I -->|Да| E I -->|Нет| F E --> J[Следующий этап пайплайна]

В чём сильны автоматические шлюзы

Главный аргумент в пользу автоматических шлюзов — консистентность. Каждый раз, когда изменение попадает в пайплайн, выполняются одни и те же проверки одним и тем же образом. Ничего не пропускается, потому что кто-то забыл. Ничего не делается наспех из-за горящего дедлайна. Пайплайн не устаёт, не отвлекается и не играет в любимчиков.

Если ваши тесты тщательны, а проверки корректны, автоматические шлюзы дают надёжный базовый уровень. Каждое изменение, прошедшее эти шлюзы, соответствует минимальному стандарту. Вам не нужно гадать, не срезал ли кто-то углы или не пропустил ли шаг.

Автоматические шлюзы также масштабируются. Команда из пяти разработчиков, возможно, способна вручную проверять каждое изменение. Команда из пятидесяти — уже нет. Пайплайн может выполнить сотни проверок за минуты, тогда как человеку на ту же работу потребуются часы.

Где автоматические шлюзы пасуют

Но у автоматических шлюзов есть слепая зона. Они могут проверить только то, что вы запрограммировали. Они не чувствуют атмосферу в команде или состояние продакшена. Они не могут принять решение, основанное на опыте.

Пайплайн может проверить, что все юнит-тесты проходят. Он не скажет вам, безопасно ли деплоить это конкретное изменение во время «Чёрной пятницы». Он может проверить, что скрипт миграции базы данных выполняется без синтаксических ошибок. Он не скажет, плохая ли идея запускать эту миграцию во вторник в 15:00.

Автоматические шлюзы отлично отвечают на вопрос «соответствует ли это техническим критериям?». Они ужасны в ответе на вопрос «стоит ли нам делать это прямо сейчас?».

Когда нужен человек

Вот тут ручные утверждения и находят своё место. Люди могут учитывать факторы, которые не способен уловить ни один тест:

  • Подходящее ли сейчас время для деплоя? Возможно, продакшен уже нестабилен. Только что запустилась крупная маркетинговая кампания. Или дежурный инженер разбирает инцидент, и его не стоит отвлекать деплоем.

  • Требует ли это изменение координации? Возможно, деплой затрагивает сервис другой команды. Возможно, команде DBA нужно знать об изменении схемы. Или команда QA хочет прогнать финальный смоук-тест до того, как изменение дойдёт до пользователей.

  • Приемлем ли риск? Небольшой багфикс можно безопасно задеплоить в пятницу после обеда. Крупный рефакторинг — вряд ли. Человек может оценить риск, опираясь на опыт и контекст.

Ручные утверждения также создают подотчётность. Когда кто-то утверждает деплой, он ставит свою подпись. Речь не о поиске виноватых. Речь о чёткой записи, что кто-то просмотрел изменение и принял осознанное решение. Если что-то пойдёт не так, команда сможет оглянуться и понять, что учитывалось перед деплоем.

Как выбирать между ними

Часто задаваемый вопрос: какие проверки автоматизировать, а какие оставить человеку?

Ответ зависит от природы проверки. Технические валидации, которые можно закодировать, должны быть автоматическими шлюзами. Тесты, сканеры безопасности, линтинг, проверки форматирования, аудит зависимостей — всё это машина делает быстрее и консистентнее человека.

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

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

Они работают вместе, а не друг против друга

Автоматические шлюзы и ручные утверждения — не конкурирующие подходы. Они дополняют друг друга. Пайплайн берёт на себя повторяющиеся, консистентные, технические проверки. Люди — контекстуальные, ситуационные решения, основанные на суждении.

Хороший пайплайн использует автоматические шлюзы, чтобы отсеивать очевидные проблемы на ранних этапах. К тому моменту, как изменение доходит до шага ручного утверждения, оно уже прошло серию проверок качества. Человеку, утверждающему изменение, не нужно беспокоиться о том, компилируется ли код или проходят ли тесты. Он может сосредоточиться на более сложных вопросах: правильно ли это делать, в это время, в этом контексте?

Практический чек-лист

Проектируя контрольные точки своего пайплайна, задайте себе эти вопросы:

  • Можно ли полностью описать эту проверку в коде? Если да — автоматизируйте.
  • Требует ли эта проверка знания текущего состояния продакшена? Если да — оставьте ручной.
  • Нужно ли этой проверке учитывать бизнес-тайминг или координацию команды? Если да — оставьте ручной.
  • Является ли эта проверка чисто технической и повторяющейся? Если да — автоматизируйте.
  • Не лишит ли автоматизация этой проверки ценного человеческого контроля? Если да — оставьте ручной.

Вывод

Автоматические шлюзы дают скорость и консистентность. Ручные утверждения — контекст и суждение. Ни то, ни другое не заменяет друг друга. Стройте свой пайплайн так, чтобы использовать и то, и другое, и вы получите систему, которая движется быстро, но не пропускает сложные вопросы.