Релиз раз в квартал – это не осторожность, а риск. Чем больше изменений накапливается между выкатками, тем сложнее найти причину сбоя и тем дороже откат. Непрерывная доставка переворачивает логику: каждый коммит проходит через конвейер, который доказывает его готовность к продакшену. Вы не решаете «можно ли релизить» – вы решаете «когда нажать кнопку». Для корпоративных систем и госзаказа это означает предсказуемость, которой требуют регламенты приёмки.
Конвейер: от коммита до кандидата на релиз
Разработчик закоммитил – запускается сборка. Один артефакт собирается единожды и проходит все стадии: модульные тесты, развёртывание на тестовый стенд, интеграционные и приёмочные проверки, нагрузочный прогон. Если стадия падает, конвейер останавливается, и команда узнаёт об этом за минуты, а не на демонстрации заказчику.
Ключевое правило – собирать бинарник один раз. Тот же артефакт, что прошёл тесты, уходит в препрод и в продакшен. Пересборка под каждую среду рушит весь смысл: вы проверяли одно, а отгружаете другое. Конфигурацию выносите наружу, в переменные среды или хранилище настроек, чтобы окружение определялось параметрами, а не отдельной сборкой.
Конвейер беспощаден к ручным шагам. Любое действие, которое человек выполняет руками при релизе, рано или поздно будет выполнено с ошибкой. Развёртывание, миграции схемы БД, прогон smoke-тестов – всё это скрипты в системе контроля версий, а не инструкция в Confluence.
Автоматизация развёртывания и базы данных
Самое тонкое место – состояние. Код легко откатить, данные – нет. Поэтому миграции пишутся инкрементально и накатываются тем же конвейером: каждый скрипт версионируется, применяется ровно один раз и проектируется обратно совместимым. Сначала добавляете новую колонку, потом переключаете код, и только следующим релизом удаляете старую. Так выкатка не требует остановки сервиса, что критично для систем с режимом работы «24 на 7».
Развёртывание стоит делать поэтапным. Канареечный релиз на часть узлов или сине-зелёная схема с двумя идентичными средами позволяют переключить трафик мгновенно и так же быстро вернуться назад. Для распределённых архитектур, о которых мы писали в материале про микросервисы на горизонте, это особенно важно: сервисы выкатываются независимо, и конвейер должен уметь обновлять их по отдельности, не трогая остальные.
Культура и зона ответственности
Технология без процесса не работает. Непрерывная доставка требует, чтобы разработка и эксплуатация отвечали за результат вместе, – это прямое продолжение культуры DevOps, о которой мы рассуждали ранее. Сломанная сборка – приоритет номер один: пока конвейер красный, новые задачи ждут. Транковая разработка с короткими ветками и feature toggles держит основную ветку всегда готовой к выкатке.
Отдельный разговор – клиенты. Серверная часть выкатывается за минуты, а вот мобильные приложения проходят модерацию магазинов, и тут логика релиза другая, как мы разбирали в заметке про нативную и веб-разработку. Конвейер для бэкенда и для клиента живут в разном темпе, и это надо закладывать в план релизов.
Вывод
Непрерывная доставка – не про скорость ради скорости. Это дисциплина, которая превращает релиз из стрессового события в рутину. Для корпоративных систем бизнеса и госсектора конвейер становится фундаментом: он фиксирует, что именно отгружено, и даёт воспроизводимую процедуру приёмки. Начните с автоматизации тестов и единого артефакта – остальное достраивается шаг за шагом.
