CI/CD: что это и как устроена автоматическая доставка изменений

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

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

Что означают CI и CD

Continuous Integration, или непрерывная интеграция, означает частое объединение небольших изменений с общей веткой и автоматическую проверку каждого изменения. Система может проверить форматирование, типы, тесты и возможность собрать проект. Если один этап не прошёл, изменение не должно двигаться дальше.

Сокращение CD используют для двух близких практик:

• continuous delivery — прошедшая проверку версия автоматически подготовлена к выпуску, но публикацию в production может подтверждать человек;
• continuous deployment — каждое изменение, прошедшее все условия, автоматически попадает в production.

Production — среда, которой пользуются реальные посетители или клиенты. Помимо неё часто есть staging: отдельная площадка для проверки собранной версии в условиях, похожих на рабочие.

Для небольшого сайта разумно начать с CI и ручного подтверждения выпуска. Автоматическую публикацию добавляют, когда проверки действительно ловят типичные ошибки, выпуск наблюдаем, а откат отрепетирован.

Как изменение проходит через pipeline

Последовательность автоматических этапов называют pipeline, то есть конвейером. Его запускает событие: новый commit, pull request, тег версии, расписание или ручная команда.

Типовой путь выглядит так:

Этап	Что он подтверждает
Установка зависимостей	проект можно подготовить в чистом окружении
Статические проверки	формат, типы и правила кода соблюдены
Тесты	проверенные сценарии дают ожидаемый результат
Сборка	исходники превращаются в публикуемые файлы или пакет
Публикация на staging	сборка запускается вне компьютера разработчика
Smoke-тест	основные адреса и действия отвечают после выпуска
Production	утверждённая сборка становится рабочей

Pipeline состоит из заданий. Задание выполняется на runner — машине или контейнере, предоставленном CI-сервисом либо вашей инфраструктурой. Задания могут идти последовательно или параллельно. Например, независимые тесты запускают одновременно, а публикация ждёт их успешного завершения.

Связь событий, заданий и шагов одинакова по смыслу в разных системах, но названия файлов и синтаксис отличаются. Нельзя копировать YAML между GitHub Actions, GitLab CI и другой платформой без адаптации.

Начните с команд, которые работают локально

CI не должен быть первым местом, где кто-либо пытается собрать проект. Сначала определите короткий набор команд, одинаково работающих на компьютере разработчика и чистом runner.

Для условного проекта на Node.js последовательность может выглядеть так:

npm ci
npm run lint
npm test
npm run build

Эти команды выполняются из корня проекта. npm ci устанавливает точные версии из lock-файла и завершится ошибкой, если он не соответствует манифесту. Остальные имена сценариев должны существовать в package.json: lint проверяет правила кода, test запускает тесты, build создаёт результат для публикации.

Успех — все четыре команды завершаются с кодом 0, а сборка появляется в документированном каталоге. Если команда не работает локально на чистой копии репозитория, перенос в CI лишь скроет причину за дополнительным интерфейсом.

Команды сами по себе ничего не публикуют. Именно конфигурация выбранной CI-системы определяет рабочий каталог, версию Node.js, кеш зависимостей и условия следующего этапа.

Что такое артефакт сборки

Артефакт — результат, который нужно сохранить после задания: архив сайта, пакет приложения, образ контейнера или отчёт тестов. Для выпуска важен принцип «собрать один раз, использовать много раз».

Если staging проверяет одну сборку, а перед production код собирают заново, результаты могут отличаться. Изменится зависимость, окружение или генерация файлов — и в работу попадёт не то, что было проверено. Поэтому pipeline сохраняет артефакт с идентификатором commit и передаёт именно его на следующие этапы.

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

Как не раскрыть доступ к серверу

Для публикации pipeline может понадобиться токен платформы, ключ хранилища или доступ по SSH. Секрет сохраняют в настройках CI-проекта и подставляют только в нужное задание.

Минимальные меры:

• отдельная учётная запись или токен для автоматизации;
• права только на нужный проект и действие;
• запрет запуска production-задания из недоверенной ветки;
• отдельные секреты для staging и production;
• маскирование значения в журналах;
• срок действия, ротация и возможность немедленного отзыва;
• защита self-hosted runner от чужих pull request.

Секрет нельзя печатать даже ради диагностики. Маскирование CI обычно находит точное значение, но может не скрыть преобразованную или разбитую строку. Практика хранения настроек отдельно от кода описана в материале о переменных окружения и секретах.

Какие условия поставить перед production

Зелёный тест означает только то, что проверен написанный сценарий. Перед выпуском полезно потребовать:

1. успешные обязательные задания;
2. проверку изменения другим участником для критичного проекта;
3. сборку из защищённой ветки или подписанного тега;
4. ручное подтверждение для опасных миграций;
5. отсутствие параллельного выпуска той же среды;
6. доступный предыдущий артефакт для возврата.

Два одновременно работающих задания могут закончиться в обратном порядке и вернуть старую версию поверх новой. CI-системы позволяют ограничить параллельность или сериализовать публикации. Конкретную настройку выбирают в документации платформы.

Изменения базы данных требуют отдельного плана. Миграция должна быть совместима с работающей и новой версией приложения либо выпуск нужно координировать. Откат файлов не отменяет уже удалённый столбец или преобразованные данные.

Что проверить сразу после выпуска

Pipeline не должен заканчивать наблюдение на сообщении «файлы скопированы». Smoke-тест — короткая проверка того, что система поднялась и выполняет основную функцию. Для сайта это может быть:

• ожидаемый HTTP-код главной и служебной страницы;
• загрузка CSS или JavaScript из текущей сборки;
• ответ безопасного диагностического endpoint;
• тестовый запрос к ключевой функции без реального платежа и рассылки;
• отсутствие резкого роста ошибок в журнале и мониторинге.

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

Откат — часть pipeline, а не импровизация

До первой автоматической публикации ответьте на три вопроса: где хранится предыдущая версия, какой командой она возвращается и что происходит с данными. Затем выполните учебный возврат на staging и измерьте время.

Для статического сайта или приложения без миграции часто достаточно переключить ссылку на предыдущий каталог релиза и перечитать конфигурацию. Эта схема разобрана в руководстве об атомарной публикации через Nginx. Для базы данных может понадобиться исправляющая миграция, а не механический rollback.

Если автоматический smoke-тест после выпуска провален, pipeline может вернуть предыдущую версию. Но решение должно учитывать характер ошибки: при внешнем сбое DNS или стороннего API повторная публикация ничего не исправит. Автоматизация выполняет заранее описанное решение, а не устанавливает причину.

С чего начать небольшому проекту

Не пытайтесь сразу построить десять сред и десятки заданий. Полезная первая версия CI/CD состоит из пяти элементов:

1. одна воспроизводимая команда установки;
2. быстрые проверки каждого pull request;
3. сохранение одного артефакта;
4. ручной выпуск из защищённой ветки;
5. автоматический smoke-тест и документированный откат.

Когда этот путь стабилен, добавляйте параллельные тесты, staging, автоматические релизы и матрицу окружений. Готовый практический пример для сайта есть в статье о CI-публикации, а локальная подготовка перед отправкой — в чек-листе Git-проверок.

Источники

• GitHub Docs: основные понятия GitHub Actions
• GitLab Docs: CI/CD pipelines
• GitLab Docs: CI/CD variables
• OpenSSF: рекомендации для CI/CD