В заказной разработке релиз – это не финал спринта, а постоянный поток изменений в систему, которой пользуется заказчик. Если каждую выкатку собирают руками, цена ошибки растёт с каждым месяцем: дольше готовится релиз, больше ручных шагов, выше риск уронить продакшен в пятницу вечером. CI/CD убирает этот ручной труд и делает доставку кода предсказуемой. Ниже – как мы строим конвейер для корпоративных и государственных проектов, где требований больше, а права на ошибку меньше.

Конвейер: от коммита до стенда

Базовый pipeline у нас состоит из трёх стадий. Первая – сборка и статический анализ: на каждый push в ветку запускается компиляция, проверка стиля и SonarQube. Вторая – тесты: юнит-тесты гоняем на каждом коммите, интеграционные и контрактные – на merge request. Третья – деплой: после прохождения тестов артефакт автоматически уезжает на стенд разработки, а на тестовый и предпродакшен – по кнопке с явным подтверждением.

Инструменты подбираем под инфраструктуру заказчика. Чаще всего это GitLab CI или Jenkins, сборка в Docker, оркестрация через docker-compose или Kubernetes там, где нагрузка это оправдывает. Артефакты складываем в Nexus, конфигурацию инфраструктуры держим в Ansible – стенды поднимаются из кода, а не из памяти администратора.

Отдельно проверяем контракты между сервисами. Когда система собрана из множества модулей, сломанный API одного сервиса тихо валит соседей. Поэтому контрактные тесты – обязательная стадия pipeline, и здесь напрямую работает API-first подход к интеграции: спецификация фиксируется заранее, а CI следит, чтобы реализация от неё не отклонялась.

Закрытый контур и импортозамещение

Госсектор и крупный бизнес почти всегда означают изолированную сеть без выхода в интернет. Привычная схема «pull из публичного registry» здесь не работает. Мы разворачиваем приватный реестр образов и зеркало пакетов внутри периметра заказчика, а runner'ы CI размещаем в той же сети. Сборка использует только проверенные зависимости из внутреннего хранилища – это и требование безопасности, и защита от внезапного исчезновения внешнего пакета.

Стек тоже подбираем с оглядкой на регуляторику. Если система идёт в эксплуатацию в органе власти, базовые компоненты должны проходить по реестру отечественного ПО: PostgreSQL вместо проприетарной СУБД, российские ОС на серверах, открытые средства автоматизации. CI/CD от этого не страдает – конвейер собирается на тех же открытых инструментах, а выкатка остаётся такой же автоматической.

Что это даёт заказчику

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

Для заказчика это означает прозрачность: видно, какая версия где развёрнута, кто и когда её собрал, какие тесты прошли. Для нас – возможность держать SLA и не выгорать на ручных выкатках.

Конвейер живёт ровно столько, сколько за инфраструктурой кто-то следит и обновляет её вместе с кодом, а не вспоминает о ней после очередного сбоя на проде.

CI/CD – не модный лозунг, а инженерная дисциплина: автоматизировать всё, что повторяется, и доверять зелёному pipeline больше, чем словам разработчика. В заказной разработке для бизнеса и госсектора это разница между управляемым релизом и постоянным авралом.