Год назад мы относились к CI/CD как к удобству: коммит запускает сборку, тесты горят зелёным – хорошо. Сейчас мы относимся к конвейеру как к производственному активу. За двенадцать месяцев он перестал быть скриптом на Jenkins и стал контрактом между разработкой, тестированием и заказчиком. Делюсь тем, что подтвердилось практикой, а не презентациями.

Конвейер – это дисциплина, а не инструмент

Главный урок банален и потому его игнорируют: инструмент не создаёт зрелость, её создаёт договорённость. Мы поставили Jenkins, GitLab и связку с Nexus за две недели. На то, чтобы команды перестали обходить конвейер ручными деплоями, ушло полгода.

Сработало три правила. Первое – единственный источник истины: артефакт собирается один раз, и в тест, и в продакшн едет один и тот же бинарь, а не пересобранный «такой же». Второе – каждый коммит в основную ветку обязан проходить полный набор быстрых тестов, и красная сборка блокирует мерж без исключений. Третье – окружения описаны кодом. Когда конфигурация сервера лежит в репозитории, а не в голове админа, разница между стендами перестаёт быть источником ночных инцидентов. Без воспроизводимых окружений и управляемых сред развёртывания автоматизация сборки даёт ложное чувство контроля.

Госсектор меняет правила поставки

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

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

Что мы автоматизировали зря, а что – поздно

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

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

Вывод

Зрелый CI/CD – это не «всё на кнопку», а предсказуемость: вы заранее знаете, что соберётся, что протестируется и как попадёт к заказчику. Инструменты вторичны, первична договорённость команды соблюдать конвейер даже в спешке. Если коротко подвести черту под годом, мы сделали это в итогах 2015-го и конвейеры там не случайно занимают отдельный пункт.