Что такое CI/CD и зачем он нужен каждой команде

CI/CD часто произносят как одно модное слово, но на самом деле это две отдельные идеи, склеенные вместе: непрерывная интеграция и непрерывная доставка (или развёртывание). Если разобраться в них по отдельности, всё становится гораздо менее абстрактным.

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

Непрерывная доставка идёт на шаг дальше: как только код проходит CI, он автоматически упаковывается и готовится к релизу — иногда в тестовую среду (staging), иногда вплоть до продакшена. Непрерывное развёртывание — более радикальный вариант, при котором код, прошедший все автоматические проверки, выходит в прод без того, чтобы кто-то нажимал кнопку. Большинство команд выбирают что-то среднее: автоматически — до staging, ручное подтверждение — перед продакшеном.

Что на самом деле делает пайплайн

CI/CD-пайплайн — это просто последовательность автоматических шагов, которые выполняются при каждом изменении кода. Типичный пайплайн выглядит примерно так:

• Получить новый код и установить зависимости
• Запустить линтеры и статический анализ, чтобы быстро отловить очевидные ошибки
• Прогнать автоматические тесты: сначала модульные, потому что они дешёвые, затем более медленные интеграционные
• Собрать артефакт для развёртывания — Docker-образ, скомпилированный бинарный файл, бандл статического сайта
• Развернуть его в тестовой или продакшен-среде
• Выполнить смоук-тест на развёрнутой версии, чтобы убедиться, что она действительно запустилась и работает

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

Почему это важнее, чем кажется

Без CI/CD деплой превращается в событие. Кто-то назначает «день деплоя», все немного нервничают, а если что-то ломается, выяснять, какое из двадцати изменений с прошлого деплоя стало причиной, — сущее мучение. С CI/CD каждое изменение небольшое, протестировано отдельно и развёртывается само по себе. Поэтому, когда что-то всё-таки ломается, вы точно знаете, какое изменение из пяти строк это вызвало, ведь больше ничего не выпускалось.

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

Где команды ошибаются

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

Успех CI/CD зависит не столько от выбранного инструмента — GitHub Actions, GitLab CI, Jenkins, CircleCI одинаково хорошо справляются, — сколько от реальных вложений в быстрые и надёжные тесты и от того, чтобы сам пайплайн оставался достаточно простым: тогда люди ему доверяют, а не ищут обходные пути.

Это ключевая часть нашей работы с инфраструктурой в Burncode: мы настраиваем CI/CD-пайплайны, которые работают достаточно быстро, чтобы инженеры действительно на них полагались, и выстраиваем мониторинг, который ловит сбои, не замеченные самим пайплайном.