Что такое CI/CD простыми словами: пайплайн, стенды и релизы

Вячеслав Степанов — проджект-менеджер, ментор · 14 октября 2026

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

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое CI/CD

CI/CD — набор практик и инструментов, которые автоматизируют путь кода от разработчика до пользователей. Между «разработчик дописал код» и «пользователь увидел новую кнопку» стоит конвейер: робот проверяет изменение, собирает продукт и раскладывает его по серверам.

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

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

CI: проверка каждого изменения

Continuous Integration — непрерывная интеграция. Термин впервые использовал инженер Грэди Буч в 1991 году, а широко известным он стал благодаря экстремальному программированию и статье Мартина Фаулера «Continuous Integration» (2000). Идея простая: вливать изменения в общий код часто и каждый раз автоматически проверять, что ничего не сломалось.

В CI обычно входят две проверки. Проверка стиля кода (линтер) смотрит, всё ли оформлено по правилам команды. Юнит-тесты проверяют отдельные функции: подали значения на вход — сверили результат. Если хоть одна проверка упала, изменение помечается красным крестом и дальше не идёт, пока разработчик его не исправит.

Пайплайн по шагам

Пайплайн (pipeline, конвейер) — настроенная цепочка шагов, которую робот проходит с каждым изменением. Два шага требуют пояснения. На сборке продукт обычно упаковывают в Docker-образ — «контейнер», который одинаково запускается на любом сервере. Смоук (дымовой тест) — быстрая проверка, что продукт вообще поднялся и главные экраны открываются; название пришло из электроники: включили плату — дыма нет, можно проверять дальше.

Пайплайны настраивают в специальных инструментах: GitLab CI, GitHub Actions, Jenkins, TeamCity. Проджекту не нужно их настраивать — достаточно уметь открыть пайплайн своей задачи и увидеть, на каком шаге она стоит.

Стенды: где живёт продукт

Ветка в Git — это только код. Чтобы он заработал как продукт, его запускают на сервере — стенде. Пайплайн сам выкладывает свежую сборку на тестовый стенд, где тестировщик проходит сценарии и регресс — проверку, что старое не сломалось рядом с новым. На прод код попадает только после этого.

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

Delivery и Deployment: две «CD»

Буквы CD расшифровывают двумя способами, и это частый вопрос на собеседовании. Подход Continuous Delivery подробно описали Джез Хамбл и Дэвид Фарли в одноимённой книге 2010 года: продукт в любой момент готов к выкатке, а решение о ней принимают люди.

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

Откат: если релиз сломался

Откат (rollback) — возврат продукта к предыдущей рабочей версии. Это самое быстрое лечение неудачного релиза: сначала вернуть пользователям работающий продукт, потом спокойно разбираться в причине. Хороший CI/CD делает откат таким же простым, как выкатку, — одной кнопкой.

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

Зачем CI/CD проджект-менеджеру

• Понимать, где задача на самом деле. «Готово» у разработчика ещё не значит «у пользователей». Пайплайн показывает: на проверке, на тесте или уже на проде.
• Видеть блокеры. Красный пайплайн, который никто не чинит, останавливает всех, кто вливает код после. Это повод поднять вопрос на дейлике.
• Планировать релизы. Проджект знает, кто нажимает кнопку выкатки, сколько длится пайплайн и в какое время команда выкатывается, — и обещает сроки с учётом этого.
• Готовиться к сбоям. План отката, ответственный за кнопку, время тишины после релиза — всё это проджект проговаривает до выкатки, а не во время инцидента.
• Говорить на языке метрик. В исследованиях DORA, описанных в книге «Accelerate» (2018), зрелость команды измеряют четырьмя показателями: как часто она выкатывается, сколько времени изменение идёт до прода, какая доля релизов приводит к сбоям и как быстро сервис восстанавливают. Все четыре напрямую зависят от CI/CD.

Типичные ошибки

• Считать «влито» равным «у пользователей». Код может стоять в очереди на тест или ждать кнопки. Лекарство — смотреть, на каком стенде задача.
• Игнорировать красный пайплайн. «Потом починим» — и через день не может влиться вся команда. Лекарство — красный пайплайн чинят первым делом, это общий блокер.
• Выкатываться без плана отката. Релиз упал, а как вернуться — никто не знает. Лекарство — до выкатки спросить, как и за сколько откатимся.
• Путать Delivery и Deployment. На собеседовании это сразу видно. Лекарство — помнить про последний шаг: кнопка или автоматика.
• Думать, что CI/CD отменяет тестировщика. Автотесты ловят известные поломки, а ручная проверка сценариев остаётся. Лекарство — закладывать время на тест в план спринта.

Частые вопросы