CI/CD — это конвейер, который забирает каждое изменение кода, автоматически проверяет его и довозит до серверов. CI (continuous integration, непрерывная интеграция) отвечает за проверку: сборка и тесты на каждый push. CD — за доставку проверенного в продакшен. Смысл пары — автоматизировать повторяемые шаги от написанного кода до релиза. При continuous delivery решение о выпуске остаётся ручным; при continuous deployment автоматизирован и выпуск.
На деплой идёт проверенный артефакт
CI: интеграция, а не деплой
Слово «интеграция» здесь историческое: до CI разработчики неделями писали код в своих ветках, а потом мучительно сливали его воедино. Непрерывная интеграция перевернула это: изменения вливаются в общую ветку часто и мелко, и каждое вливание автоматически проверяется — проект собирается, тесты гоняются. Ключевое свойство CI — одинаковость: проверка не зависит от того, кто пушит и с какой машины. «У меня локально работало» перестаёт быть аргументом, потому что вердикт выносит общий конвейер.
Отсюда же главное правило: красный CI чинится немедленно. Пайплайн, который «всегда красный, не обращай внимания», хуже отсутствующего — он приучает игнорировать сигнал.
CD: delivery или deployment
У аббревиатуры CD две расшифровки, и разница между ними — один ручной шаг. Continuous delivery — каждое зелёное изменение автоматически доведено до состояния «готово к релизу», но кнопку «в прод» нажимает человек. Continuous deployment — кнопки нет: прошёл тесты — уехал к пользователям. Второй вариант требует большего доверия к тестам и мониторингу, поэтому команды обычно начинают с delivery и убирают кнопку, когда конвейер заслужил доверие.
Между CI и CD живёт артефакт — результат сборки: Docker-образ, архив, бинарник. Принцип один: деплоится ровно тот артефакт, который прошёл тесты, а не пересобранный заново. Поэтому в продакшене образы принято закреплять точной версией или digest’ом, а не тегом latest, который завтра может указывать на другую сборку.
Как выглядит пайплайн: минимальный пример
Пайплайны описываются файлом в репозитории. Минимальный честный CI на GitHub Actions — один файл .github/workflows/ci.yml:
name: CI
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 22
- run: npm ci
- run: npm testЧитается сверху вниз: на каждый push поднимается чистая машина с Ubuntu, забирает код, ставит Node.js 22, устанавливает зависимости и гоняет тесты. Упал любой шаг — пайплайн красный, и GitHub заблокирует слияние PR для пользователей без права обхода, если именно проверка test добавлена в обязательные проверки защищённой ветки. Одной защиты ветки без required status checks недостаточно. Заметь, что CI-агент — это обычный Linux: шаги пайплайна — те же команды шелла, и отлаживаются они теми же конвейерами и перенаправлениями.
Зачем это всё: мелкие партии бьют большие релизы
Экономика CI/CD держится на размере изменения. Большой релиз раз в месяц — это сотня изменений, которые ломаются вместе: одна ошибка тащит диагностику по всей сотне, и каждый красный прогон стоит цикла «понять — починить — подождать». Мелкие изменения через конвейер падают по одному: видно, что именно сломалось, откат — это одна маленькая версия, а не «весь релиз назад». Плюс скорость: фикс бага доезжает до пользователей за минуты после мержа, а не ждёт следующего релизного окна.
Ошибки, на которых спотыкаются
CI без тестов. Пайплайн, который только собирает проект, даёт зелёную галку, не проверяя поведение. Это обман приборов: конвейер есть, защиты нет.
Деплой руками «в обход, один разочек». Ручная правка на сервере живёт до следующего автодеплоя, который её молча затрёт. Всё, что должно жить в проде, едет через конвейер.
Секреты в файле пайплайна. Токены и пароли не пишут в yml — их кладут в хранилище секретов CI-системы, а в файле остаётся только ссылка. Репозиторий читают все, у кого есть доступ к коду, и его история вечна.
latest в продакшене. Тег перезаписываемый: сегодня это одна сборка, завтра другая. Прод деплоят точной версией, чтобы откат и воспроизведение были однозначными.
Частые вопросы
Чем CI отличается от CD
CI проверяет каждое изменение: сборка и тесты на каждый push. CD доставляет проверенное: автоматический путь артефакта до staging и продакшена. CI без CD бывает и полезен сам по себе; CD без CI — конвейер, который быстро возит неproверенное.
Что такое пайплайн
Описанная в файле цепочка шагов, которую CI-система выполняет на событие в репозитории: push, pull request, тег. Шаги — обычные команды; упал один — цепочка останавливается.
Что такое артефакт сборки
Готовый результат CI: Docker-образ, архив со сборкой, бинарник. Его сохраняют и деплоят как есть — пересборка перед деплоем создала бы версию, которую никто не тестировал.
Что выбрать: GitHub Actions или GitLab CI
Ту систему, где лежит код: обе покрывают стандартные сценарии, а синтаксис переносится за вечер. Разница станет важна позже — на self-hosted-агентах, стоимости минут и интеграциях.
Где потренироваться
Вопросы про CI/CD, Docker-образы и стратегии деплоя есть в скилл-тесте по DevOps и среди вопросов на собеседовании. Общая картина, куда CI/CD встроен, — в статьях про DevOps и про SRE.