CI/CD: что это, как устроен пайплайн и с чего начать бизнесу

Две буквы, две практики

CI, continuous integration, — непрерывная интеграция. Разработчики часто, хотя бы раз в день, сливают свои изменения в общую ветку кода, и каждое слияние автоматически собирается и проверяется тестами. Ошибка находится через минуты после того, как появилась, а не через три недели на общем тестировании.

CD расшифровывают двумя способами. Continuous delivery — непрерывная доставка: каждая проверенная версия готова к выкладке, и выложить её можно одной кнопкой. Continuous deployment — непрерывное развёртывание: прошедшая проверки версия уезжает на рабочий сервер сама, без кнопки. Большинству интернет-магазинов хватает первого варианта.

На AGDays 2025 я объяснял это залу собственников так: CI/CD — утилита, которая сокращает число действий, чтобы загрузить новую версию на сайт. Меньше ручных действий — реже ошибки и чаще релизы.

Что это даёт бизнесу

• Релизы каждую неделю или чаще вместо одного раза в квартал. Новые функции быстрее доходят до покупателя.
• Маленькие изменения. Если что-то сломалось, понятно, какое изменение виновато, и откатить его просто.
• Меньше зависимости от конкретного человека. Выкладка не держится на одном разработчике, который «знает, как деплоить».
• Предсказуемость. Каждая версия проходит одни и те же проверки.

Как устроен CI/CD-пайплайн

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

• Сборка. Код компилируется или собирается, ставятся зависимости.
• Проверка кода. Линтеры и статический анализ ловят опечатки и нарушения договорённостей команды.
• Автотесты. Модульные проверяют отдельные функции, сквозные проходят сценарии пользователя в браузере.
• Выкладка на тестовый стенд. Менеджер или тестировщик смотрит изменения руками.
• Выкладка на рабочий сервер. По кнопке или автоматически, лучше сначала на часть пользователей.
• Проверка после релиза. Мониторинг смотрит ошибки и нагрузку и сообщает, если что-то пошло не так.

Сколько должен идти пайплайн

Ориентир — до 10–15 минут от коммита до готовой к выкладке версии. Если проверка идёт час, разработчики начинают копить изменения в большие пачки или обходить пайплайн, и смысл пропадает. Ускоряют обычно тремя способами: запускают тесты параллельно, кешируют зависимости между сборками и выносят долгие сквозные тесты в отдельный ночной прогон, оставив в основном пайплайне только главный сценарий.

Инструменты

Чаще всего встречаются GitLab CI, GitHub Actions и Jenkins. Для небольшого проекта хватит встроенного CI того сервиса, где лежит код. Выбор инструмента редко бывает узким местом. Узкое место — тесты, которых нет. Настройки пайплайна храните в репозитории рядом с кодом, а не в веб-интерфейсе: тогда изменения в процессе сборки проходят ревью так же, как изменения в коде, и их видно в истории.

Окружения: где живёт версия до релиза

Пайплайну нужно куда-то выкладывать. Минимальный набор — три окружения. Локальное у разработчика. Тестовый стенд, куда автоматически уезжает каждая ветка или каждое слияние: там менеджер и тестировщик смотрят изменения руками, а клиент может принять работу. И рабочий сервер. Чем ближе тестовый стенд к рабочему по настройкам и данным, тем меньше сюрпризов после релиза; обезличенная копия рабочей базы на стенде ловит ошибки, которые на трёх тестовых товарах не видны.

Автотесты: с чего начать в интернет-магазине

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

• Главный сценарий: товар, корзина, оформление заказа, заказ создан. Если он не проходит, остальное не имеет смысла.
• Оплата. Если деньги не доходят, это грустнее любой кривой вёрстки.
• Авторизация и фильтры каталога.

Тесты, которые никто не чинит

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

Что это меняет в скорости

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

Кто всё это настраивает

Отдельный DevOps-инженер — признак зрелости компании. Пока его нет, пайплайн и серверы настраивает кто придётся: бэкенд-разработчик, ИТ-директор или собственник. Я сам иногда открываю консоль. По моему опыту, роль стоит выделять, когда в команде семь-десять человек. Это не обязательно сотрудник в штате, DevOps можно взять на аутсорсе.

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

Что ставить рядом с CI/CD

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

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