CI/CD становится страховкой бизнеса, когда код пишут агенты

CI проверяет, работает ли правка с остальным продуктом. Автоматика собирает приложение и запускает проверки до слияния в основную ветку.

CI означает Continuous Integration, непрерывную интеграцию. Изменения проверяют регулярно, выпускать каждое клиентам необязательно.

CD готовит проверенную версию к выпуску или выпускает её автоматически. Delivery оставляет шаг согласования человеку, Deployment убирает этот шаг.

Пайплайн задаёт порядок действий. GitLab CI/CD хранит команды в файле репозитория, а раннер выполняет их на машине. Название сервиса не определяет проверки.

На публичном /open 7 октября видно 7 063 коммита за 98 дней с 1 июля. Коммит фиксирует правку в репозитории, включая тексты и документацию.

Коммиты не равны выпускам. Старый замер на /open считает 300 мержей за 11 суток, срез 26 августа 2026. Это слияния веток, названные там релизами.

Для такого потока /open описывает 2 685 тестов на каждом пуше плюс ревью. Пуш отправляет правки в репозиторий. Это наш контур на 7 октября, не норма для вашей компании.

Инженер ведёт машину агентов на нашем сайте, клиентского кейса CI/CD у нас нет. Эффект ИИ и DORA-метрики разобраны в статье «ИИ не ускорил разработку».

Проверки начинают с того, что бизнес боится потерять. Для оплаты это верное списание и доступ, для заявок нужно сохранить заявку. Число тестов этого не объясняет.

В примере ниже тест проверяет повторное уведомление об оплате. Доступ не должен выдаваться повторно. Это учебное требование, не история клиента.

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

Зелёные тесты не доказывают, что верная версия доехала до клиента. Ошибка бывает в сборке или порядке выпуска. Наши поломки ниже показывают эти места.

Продом называют рабочую версию для клиентов. Старый выпуск не должен перезаписать новый. GitLab описывает порядок и запрет устаревших заданий, проверено 7 октября.

Повтор сборки не устраняет нехватку памяти. Если отключить проверку типов, исчезнет красный сигнал вместе с проверкой. Условия выполнения надо исправить.

Тесты и сборка отвечают на разные вопросы. Проверена ли правка? Получился ли из неё пакет для выпуска? Одна зелёная отметка не должна заменять оба ответа.

Настройку CI принимают на заранее выбранной поломке в тестовой ветке. Команда должна показать остановку. Успешный запуск проверяет только рабочий путь.

Инженер выбирает сценарий и ожидаемый результат, агент готовит тест и поломку. Руководитель получает ссылку на запуск с причиной остановки и запретом слияния.

Исправление проходит новый запуск. Зелёный результат старого коммита не подтверждает новый код. GitHub позволяет требовать проверки перед слиянием.

Права обхода надо назвать заранее. Если агент может снять запрет, файл его не удержит. Про правила для ИИ-агентов есть отдельная статья.

Слияние принимает код в основную ветку, выпуск устанавливает версию. Задача бизнеса заканчивается, когда нужное действие работает для клиента.

После выпуска проверяют сценарий правки. У формы заявки проверяют получение заявки. Для оплаты заранее согласуют прогон без реального списания.

При сбое останавливают выпуски и восстанавливают работу по плану. Возврат кода не отменяет списаний. Кто принимает решения, разобрано в статье об ответственности за ошибки ИИ.

Причина поломки должна стать проверкой. После ошибки упаковки проверяют эту стадию до выпуска. После потери заявки проверяют её получение.

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

Настройку можно поставить в беклог подписки на агентную разработку. «Один проект» стоит 250 000 ₽ в месяц на 7 октября 2026; правки идут в репозиторий клиента.

«Задачи без лимита» на /services означают очередь, один поток ведёт одну задачу за раз. Подписку сравнивают с разовой настройкой CI, если других изменений нет.

1. CI/CD проверяет изменения и проводит выбранную версию к выпуску. Согласуйте, что именно он проверяет в вашем продукте.

2. Принимайте настройку на намеренно ошибочной правке: проверка находит сбой, слияние заблокировано.

3. Проверенный код, установленная версия и работающий сценарий клиента оставляют разные следы. Попросите показать каждый.

4. После поломки добавляйте проверку её причины. Следующая такая ошибка должна остановиться раньше клиента.