Что такое CI/CD и зачем

Боль, из которой родился CI/CD

Представь команду без автоматизации. Пять разработчиков неделю пишут код по своим веткам. В пятницу всё сливают в одну, и начинается:

• код одного ломает код другого (конфликты, несовместимые изменения),
• "у меня на ноутбуке работает", а на сервере нет,
• тесты никто не гонял локально, потому что "долго",
• деплой — это когда сеньор по SSH руками копирует файлы и молится.

Каждый релиз становится стрессом и потерянным вечером. Чем дольше код живёт не слитым с общей веткой, тем больнее интеграция. CI/CD как раз про то, чтобы вливать изменения часто, а проверки и деплой переложить на автоматику.

Что значат буквы

CI — Continuous Integration (непрерывная интеграция). Каждый разработчик вливает свои изменения в общую ветку часто (несколько раз в день), и на каждое изменение автоматика прогоняет сборку и тесты. Сломал что-то, узнаешь через минуты, а не через неделю.

CD расшифровывается двумя способами, и важно их не путать:

• Continuous Delivery (непрерывная доставка) — после CI собирается готовый к выкатке артефакт, и задеплоить его в прод можно в любой момент одной кнопкой. Решение "выкатывать ли" остаётся за человеком.
• Continuous Deployment (непрерывное развёртывание). Тут кнопки нет: прошёл все проверки и уехал в прод сам, без человеческого ОК.

Разнице между Delivery и Deployment посвящён отдельный урок: это частый вопрос на собеседовании.

Что мы автоматизируем

Конвейер (pipeline) обычно прогоняет на каждое изменение примерно такую цепочку:

коммит -> сборка -> линтер -> тесты -> упаковка артефакта -> деплой

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

Что от этого меняется в работе

Поломку видно сразу: тесты упали на пуш, ты узнал через минуту, а не через неделю, когда уже непонятно, где сломалось. Релизы мельчают: выкатывать 10 строк безопаснее, чем накопленные за месяц 10 000. Деплой становится рутинной кнопкой, а не подвигом одного сеньора, который один и умеет. Машина не забывает шаги и не путает прод со staging.

Команды смотрят на четыре DORA-метрики (это базовый набор, его и называют на собесах):

• Deployment Frequency — как часто деплоят в прод.
• Lead Time for Changes — сколько проходит от коммита до прода.
• Change Failure Rate — какая доля релизов что-то ломает.
• Mean Time to Recovery (MTTR) — за сколько чинят после поломки.

Чем чаще и спокойнее, тем лучше.

На собесе спросят

Короткие ответы, которые надо уметь проговорить:

• «Чем CI отличается от CD?» CI собирает и тестирует каждый коммит. CD доставляет готовый артефакт в прод: либо человек жмёт кнопку (Delivery), либо он выкатывается сам (Deployment). Если кандидат говорит «CI выкатил в прод», он путает CI с CD. Это типовая ловушка.
• «Чем Continuous Delivery отличается от Continuous Deployment?» Delivery — артефакт готов, релиз нажимает человек. Deployment — всё то же, только без кнопки, выкатывается сам.
• «Что такое pipeline?» Описанная кодом (.gitlab-ci.yml, .github/workflows/*.yml) последовательность шагов: сборка, тесты, упаковка, деплой. Лежит в репозитории, выполняется одинаково.
• «Назови 4 DORA-метрики.» Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. Не «частота релизов и время починки», а именно по названиям.
• «Что такое stage, job, runner, artifact?» Stage — этап pipeline (build, test, deploy). Job — одна задача в stage. Runner — машина или контейнер, который реально выполняет jobs. Artifact — файл, который job произвёл (jar, образ, бинарь) и который передаётся в следующие jobs.

Что важно запомнить

CI — автоматическая сборка и тесты на каждое изменение. CD — два режима выката: Delivery (кнопку жмёт человек) и Deployment (уезжает само). Pipeline — YAML рядом с кодом, который описывает шаги.

В следующем уроке подробно разберём CI: что именно гоняется на каждый push и почему «зелёный main» — правило команды.