Вокруг «большой зеленой кнопки» для релиза много споров: кому-то она кажется естественным этапом развития CI/CD, а ее отсутствие — признаком незрелого процесса. В этой статье на примере одного проекта объясним, почему мы сознательно отказались от «большой зеленой кнопки», как у нас устроен релизный процесс, сколько в нем автоматизации и есть ли в нем место ручному управлению.
Почему вокруг «большой зеленой кнопки» столько споров
Идея полностью автоматизированного релиза очень привлекательна: одна кнопка → один клик → система сама собирает, выкатывает, проверяет и при необходимости откатывается. Но на самом деле все сложнее. Часто «большая зеленая кнопка» превращается в ящик Пандоры: нажал — и дальше либо повезло (релиз выкатился штатно или обновление не прошло, и информационная система вернулась в исходное состояние), либо команда срочно тушит пожар посреди ночи.
В продуктовых командах с относительно простой архитектурой это действительно работает: микросервисы, быстрый откат в исходное состояние, минимум интеграций. Там «большая зеленая кнопка» со временем становится естественным развитием цикла разработки.
Проблема начинается, когда эта картинка превращается в догму: если у вас нет одной кнопки, значит вы «обновляетесь неправильно» или «еще до нее не доросли».
В реальности же «большая зеленая кнопка» — это не универсальный признак зрелости, а всего лишь один из возможных вариантов, подходящий далеко не всем. В сложных системах с регламентами, внешними ведомствами и длинными цепочками согласований окон обновлений цель во что бы то ни стало прийти к «магической кнопке» часто заканчивается обратным: больше стресса, больше попыток релизов, больше неожиданных срывов.
Формально все хотят одного — безопасных и предсказуемых релизов. Но под этим каждый понимает свое. Менеджеры видят в «большой зеленой кнопке»:
предсказуемый сценарий («всегда делаем одинаково»);
прозрачность процесса (понятно, кто, когда и что запустил);
снижение зависимости от конкретных людей («нажать кнопку сможет любой дежурный»).
DevOps‑инженеры видят:
рост скрытых рисков — одно действие запускает длинную цепочку эффекто
в;потерю гибкости — либо едем до конца, либо откатываем все целиком;
необходимость поддерживать хрупкий сценарий, который ломается при любом изменении внешних сервисов или регламентов.
По сути спор идет не только о технологии обновлений, но и об ответственности. Менеджеры хотят, чтобы процесс был простым и воспроизводимым. DevOps-инженеры хотят, чтобы процесс был безопасным и учитывал реальную инфраструктуру.
Почему в нашей системе нет «большой зеленой кнопки»
Мы работаем с системой, у которой:
много внешних интеграций и сервисов;
жесткие требования к окнам обновления;
регламентированное время на откаты.
Каждое обновление — это не только наш код, но и:
состояние внешних API;
доступность смежных систем;
внешние ограничения.
С нашей точки зрения в такой среде полностью автономный деплой типа «нажал и ушел» создает больше рисков, чем пользы. Один неожиданный тайм-аут или непредвиденная ошибка сервиса — и «большая зеленая кнопка» запускает цепочку проблем, которые все равно придется разруливать инженеру.
Один из кейсов — когда один или более серверов не ответили за отведенное время. Процесс обновления выстроен так, что предварительные шаги выполняются параллельно на всех серверах. На этом этапе неприятно, но не опасно потерять связь с одним из серверов.
В нашем проекте продуктивный контур имеет специфические каналы связи с рядом ограничений. Рассмотрим конкретный пример. Представьте: в процессе релиза из серверов (назовем его app1) не ответил за отведенное время. Это приведет к тому, что CD обозначит его как недоступный и прервет выполнение обновления на нем: дальнейшие шаги не будут выполняться и появится сообщение об ошибке. Время ответа сервера зависит от его загруженности в данный момент, проверок систем ИБ и других возможных факторов, которые в итоге не являются противопоказаниями к обновлению. DevOps-инженер, выполняющий обновление, при таких ошибках может повлиять на ситуацию и запустить дополнительно обновление выпавших серверов из основного процесса.
Применение новой версии приложения происходит последовательно: релиз не накатится на выпавший app1. И даже если он «пострадал» на каком-то из этапов, он просто не пройдет проверки работоспособности и будет исключен из работы системы до устранения причин поломки. Это не является проблемой для приложения, поэтому app1 можно будет обновить после устранения причин долгого ответа.
В случае с мифической «большой зеленой кнопкой» и полной автоматизацией процесса обновления при выпадении из деплоя сервера app1 должен запуститься откат изменений. Это может привести к к потерянному окну обновления, поискам DevOps-инженера, чтобы он разобрался в причинах проблемы, недовольству заказчика.
Поэтому мы выбрали другой подход: максимальная автоматизация операций, но человек — на уровне запуска и контроля.
Автоматизация есть, автономии нет
У нас реализована максимально возможная техническая автоматизация, но не «автоматика ради автоматики».
CI/CD‑конвейер делает за инженера почти всю рутину:
сборка артефактов;
прогон unit‑тестов;
статический анализ;
упаковка релизного пакета;
подготовка окружения;
деплой;
выполнение миграций;
проверки после обновления;
мониторинг ключевых метрик.
Ручными остаются:
запуск релиза;
контроль ключевых точек и, при необходимости, принятие решения об изменении параметров прохождения релиза.
Человек видит контекст, которого нет в метриках: состояние смежных систем, текущие риски, регламентные ограничения, планы заказчика. Ни один дашборд пока не умеет складывать всё это в осознанное решение «выкатываем обновление сейчас или нет».
Как выглядит релизный процесс глазами DevOps-инженера
Разработчик коммитит изменения — автоматически запускается проверка кода.
В нужный момент менеджер запускает сборку, которая собирает артефакты и формирует релизный пакет.
Разработка передает изменения конфигураций и релизные примечания.
DevOps оценивает внешние факторы: состояние смежных сервисов, текущую нагрузку, регламентные ограничения и окна обновления.
Инженер дает команду на запуск деплоя.
CD выполняет деплой автоматически: доставляет и модифицирует конфигурации, запускает миграции ,проверяет контрольные точки.
Инженер проводит финальный осмотр системы: проверяет логи, графики, ключевые метрики.
При необходимости выполняется откат, предварительно согласованный с менеджером.
Таким образом, весь операционный слой автоматизирован, но стратегическое решение — запуск, пауза, откат — принимают DevOps-инженер и менеджер.
Почему у нас нет автоматического отката
Логичный вопрос: если мы так за автоматизацию, почему бы не сделать полностью автоматический откат?
Наши аргументы:
обновления проходят в жестко ограниченные регламентные окна;
доставка и миграции могут занимать ощутимое время;
нештатные ситуации могут быть разного масштаба.
Если проблема понятна и решается за несколько минут, автоматический откат только навредит: он съест окно обновления, отложит релиз и создаст дополнительную нагрузку на команду.
Мы считаем более зрелой моделью, когда:
все, что можно, делает пайплайн;
решение «чинить или откатывать» принимает инженер и менеджер, которые видят всю картину — от логов до звонков заказчика.
Когда «большая зеленая кнопка» действительно уместна
Есть системы, где полностью автоматический деплой — хороший и экономически оправданный выбор. Например:
продукт с небольшим количеством интеграций;
нет жестких регламентных требований к окнам обновлений;
деплой и откат занимают минуты, а не часы.
В таких условиях «большая зеленая кнопка» — это реально удобный инструмент, а не источник хронического стресса.
Что в итоге
В нашей команде релизный процесс выглядит так:
широкая автоматизация всех технических операций в CI/CD‑пайплайне;
инженерное управление контрольными точками;
ручное принятие решений о запуске релиза и откате.
Мы не гонимся за мифической «большой зеленой кнопкой», потому что живем в инфраструктуре с реальными ограничениями. При этом мы обеспечиваем:
предсказуемость;
безопасность;
повторяемость;
прозрачность процессов;
минимизацию операционных ошибок.
Мы выбрали максимальную автоматизацию операци��, но оставили человека на уровне запуска и контроля. Расскажите, удалось ли вам внедрить свою «большую зеленую кнопку»? Поделитесь в комментариях реальными кейсами: что сработало, что пришлось пересобрать, где автоматизация не оправдала себя, а где — помогла усилить команды.
