CI/CD простыми словами: что это и зачем бизнесу

Разработчик пишет в чат: «Фикс готов, выкачу вечером». Вечером сайт падает, а откатить изменения не получается, потому что выкладку делали руками и по памяти. Утром выясняется, что вместе с исправлением на сервер уехал недописанный кусок другой задачи. CI/CD нужен ровно для того, чтобы такие вечера перестали случаться.

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

Что такое CI/CD

Аббревиатура состоит из двух частей.

CI, непрерывная интеграция. Разработчики часто вливают свои изменения в общий код, а каждое вливание автоматически собирается и проверяется тестами. Фаулер (Martin Fowler), автор классической статьи о непрерывной интеграции, задаёт ориентир: каждый участник команды объединяет свои изменения с чужими хотя бы раз в день. Ошибка находится вскоре после появления, пока автор ещё помнит, что менял.

CD, непрерывная доставка или непрерывное развёртывание. Здесь есть тонкость. Непрерывная доставка (continuous delivery) означает, что код в любой момент готов к выпуску, а в продакшен его выкладывают по кнопке, когда решит команда. Непрерывное развёртывание (continuous deployment) идёт дальше: каждое изменение, прошедшее проверки, уходит к пользователям автоматически. Второе невозможно без первого. Термины путают даже в самих командах, поэтому на старте проекта договоритесь, что именно вы строите: автоматическую проверку, выкладку по кнопке или полностью автоматический релиз.

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

Как выглядит конвейер от коммита до продакшена

1. Коммит. Разработчик отправляет изменения в репозиторий, общее хранилище кода.
2. Сборка. Сервер собирает проект так же, как он будет работать в бою.
3. Автотесты. От быстрых проверок отдельных функций до сценариев целиком: регистрация, оплата, отправка формы.
4. Проверки качества и безопасности. Анализ кода, поиск уязвимых зависимостей, проверка, что в код не попали пароли.
5. Тестовый стенд. Сборка выкладывается на копию продакшена, где её смотрят тестировщики или заказчик.
6. Выкладка в продакшен. По кнопке или автоматически, в зависимости от того, какой CD у вас настроен.
7. Мониторинг и откат. Если после релиза растёт число ошибок, возвращается предыдущая версия.

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

Скорость здесь важна. Фаулер ссылается на правило из экстремального программирования: сборка примерно за десять минут считается разумной для большинства проектов. Если конвейер идёт час, разработчики начинают его обходить, и смысл пропадает.

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

Зачем это бизнесу, а не только программистам

• Маленькие и частые релизы. Меньше изменений за раз, меньше риск, проще найти причину поломки.
• Ошибки ловятся рано. Баг, найденный тестом до релиза, дешевле бага, о котором сообщил клиент.
• Предсказуемость. Путь от готовой задачи до пользователей занимает понятное время, а не «когда освободится тот, кто умеет выкладывать».
• Независимость от одного человека. Выкладка описана в конфигурации, а не живёт в голове единственного разработчика.
• Быстрый откат. Предыдущая рабочая версия всегда под рукой.
• История изменений. Видно, кто, что и когда выкатил.

Без конвейера каждый релиз превращается в маленький проект: договориться, кто выкладывает, проверить руками, держать всех на связи на случай поломки. Поэтому релизы делают реже, изменения копятся, и каждый следующий выпуск становится рискованнее предыдущего.

Результат можно измерить. Исследовательская программа DORA много лет изучает команды разработки и оценивает поставку ПО по двум группам метрик. Пропускная способность: как часто вы выкатываете изменения, сколько времени проходит от коммита до продакшена и как быстро команда восстанавливается после неудачного релиза. Стабильность: какая доля релизов требует срочного вмешательства и сколько выкладок приходится делать внепланово из-за инцидентов. Попросите подрядчика показывать эти цифры раз в месяц.

Инструменты: на чём собирают CI/CD

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

Где запускать: у платформы или на своём сервере

Раннеры можно взять у платформы или поднять свои. Свои нужны, когда сборке требуется доступ к внутренним системам компании или особое окружение. Раннеры платформы проще: их не нужно обслуживать и обновлять.

Где CI/CD ломается

• Нет тестов. Сборка проходит, а ошибки первыми находят пользователи.
• Нестабильные тесты. Их перезапускают, пока не позеленеют, и перестают доверять сигналу.
• Медленный конвейер. Люди копят изменения и выкатывают пачками, риск растёт.
• Секреты в коде. Пароли и токены должны храниться в защищённых переменных CI, а не в репозитории.
• Ручные шаги «только в этот раз». Одна ручная правка на сервере, и продакшен уже не совпадает с тем, что описано в коде.
• Стенд не похож на продакшен. Всё проверили, но в бою другая версия базы или другие настройки.
• Нет плана отката для базы данных. Код откатить легко, изменения в структуре данных сложнее.

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

Что спросить у подрядчика

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

• Где лежит код и оформлен ли репозиторий на нашу компанию?
• Что проверяют автотесты и сколько времени идёт конвейер?
• Как выглядит выкладка: кнопка, автоматика или ручные команды на сервере?
• Как откатить неудачный релиз и сколько это займёт?
• Где хранятся пароли и ключи доступа?
• Есть ли тестовый стенд, похожий на продакшен?
• Как мы узнаем о падении раньше клиентов?

Хороший ответ звучит конкретно: «конвейер идёт двенадцать минут, откат одной кнопкой, пароли в хранилище секретов». Размытые формулировки вроде «у нас всё налажено» стоит уточнять.

Особенно важен первый пункт. Репозиторий, конвейер и доступы к серверам должны быть оформлены на вашу компанию. Тогда смена подрядчика станет рабочим вопросом, а не катастрофой.

CI/CD и нейросети

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

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

С чего начать

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

Если не хочется выстраивать это самому, команда заказной разработки Neurounit собирает проекты сразу с конвейером: от репозитория на вашем аккаунте до автоматической выкладки и мониторинга.