Что такое CI/CD простыми словами и зачем он вашему проекту

CI/CD — это автоматический конвейер, который проводит каждое изменение кода по одному и тому же маршруту: собрать проект, проверить тестами и линтерами, выложить на тестовый сервер, а затем на боевой. Если простыми словами, CI/CD это когда сайт обновляет не человек руками по FTP или SSH, а скрипт, который каждый раз делает одно и то же и не забывает шаги.

Что такое CI/CD простыми словами: расшифровка

Аббревиатура состоит из двух частей, и у второй два значения — отсюда половина путаницы.

• CI — Continuous Integration, непрерывная интеграция. Разработчики часто вливают изменения в общую ветку, и каждое вливание автоматически проверяется: сборка, тесты, статический анализ. Ошибка находится через минуты после коммита, а не через неделю на проде.
• CD — Continuous Delivery, непрерывная доставка. Каждая проверенная версия автоматически упаковывается и готова к выкладке; на боевой сервер она уходит по кнопке.
• CD — Continuous Deployment, непрерывное развёртывание. То же самое, но без кнопки: прошла все проверки — сама уехала в production.

Continuous Delivery и Continuous Deployment: в чём отличие

Разница — в последнем шаге. Большинству сайтов разумно начинать с Delivery: рутину делает автоматика, решение «выкатываем» — за человеком.

Как работает CI/CD-пайплайн: этапы от коммита до прода

Пайплайн (конвейер) — описанная в конфигурационном файле последовательность этапов. Типовой маршрут для веб-проекта:

1. Коммит и push. Изменения в ветке или merge request (pull request) запускают пайплайн.
2. Сборка. Ставятся зависимости (composer, npm), собирается фронтенд, при необходимости — Docker-образ.
3. Тесты и линтеры. Юнит- и интеграционные тесты, проверка стиля кода, статический анализ (PHPStan, ESLint, TypeScript), поиск уязвимых зависимостей. Это «гейт»: красный результат блокирует слияние и выкладку.
4. Артефакт. Результат сборки сохраняется как неизменяемый пакет — архив или Docker-образ с версией. Выкладывается именно он, а не «пересобранное на сервере».
5. Деплой на stage. Тестовая копия сайта с тем же окружением, что и боевая: здесь изменения смотрят глазами.
6. Деплой на production. По кнопке (Delivery) или автоматически (Deployment), часто с миграциями базы данных.
7. Откат. Если после релиза что-то пошло не так, возвращается предыдущий артефакт — за минуту.

Задания выполняют раннеры (runner, agent) — машины или контейнеры, облачные от платформы или собственные на вашем сервере.

Что CI/CD даёт бизнесу, а не только программистам

• Нет релизов «выкатили в пятницу вечером и упали». Сломанный код останавливается на тестах, а если проблема проскочила — откат занимает минуты.
• Правки доезжают быстрее. Поправить баг в корзине или выкатить акцию — это десятки минут от готового кода до прода, а не «полдня на релиз».
• Меньше ручных ошибок. Забыли залить один файл, перезаписали конфиг боевой базы тестовым, не очистили кеш — классика ручного деплоя, которая исчезает, когда шаги выполняет скрипт.
• Процесс не зависит от одного человека. Инструкция по выкладке записана в репозитории, а не в голове фрилансера.

Инструменты CI/CD: GitLab CI, GitHub Actions, Jenkins и российские платформы

Выбор инструмента определяется тем, где хранится код: пайплайн живёт рядом с репозиторием.

Если проект уже живёт в GitLab или GitHub и это не противоречит требованиям безопасности — переезжать ради CI/CD не нужно. Где важна независимость от зарубежных сервисов или реестр отечественного ПО, логичны self-hosted GitLab, GitFlic или SourceCraft. Собственный раннер на своём сервере — стандартная часть настройки CI/CD под проект: пайплайн не зависит от лимитов облачной платформы, а доступ к боевым серверам не выходит за периметр.

Пример .gitlab-ci.yml для Node.js-сайта

Минимальный пайплайн для сайта со статической сборкой (Vite, Astro): тесты, сборка, выкладка на stage автоматически из develop, на production — по кнопке из основной ветки. Каждая версия кладётся в свою папку, «текущая» переключается симлинком — это и есть простейший откат. Автоматическую выкладку стоит записать и в регламент поддержки сайта: кто выкатывает изменения, в какие часы и как откатывает неудачный релиз.

stages: - test - build - deploy default: image: node:22 variables: npm_config_cache: "$CI_PROJECT_DIR/.npm" cache: key: files: - package-lock.json paths: - .npm/ lint_and_test: stage: test script: - npm ci - npm run lint - npm test build: stage: build script: - npm ci - npm run build artifacts: paths: - dist/ expire_in: 1 week .deploy: stage: deploy image: alpine:3.20 before_script: - apk add --no-cache openssh-client rsync - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - - mkdir -p ~/.ssh && echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts script: - RELEASE="$DEPLOY_PATH/releases/$CI_COMMIT_SHORT_SHA" - ssh "$DEPLOY_USER@$DEPLOY_HOST" "mkdir -p $RELEASE" - rsync -az --delete dist/ "$DEPLOY_USER@$DEPLOY_HOST:$RELEASE/" - ssh "$DEPLOY_USER@$DEPLOY_HOST" "ln -sfn $RELEASE $DEPLOY_PATH/current" deploy_staging: extends: .deploy environment: staging rules: - if: $CI_COMMIT_BRANCH == "develop" deploy_production: extends: .deploy environment: production rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: manual

Что здесь важно:

• Переменные SSH_PRIVATE_KEY, SSH_KNOWN_HOSTS, DEPLOY_HOST, DEPLOY_USER, DEPLOY_PATH задаются в настройках проекта (Settings → CI/CD → Variables) с областью действия по окружению — так staging и production получают разные серверы и ключи, а в коде нет ни одного пароля.
• npm ci ставит зависимости строго по lock-файлу — сборка воспроизводима.
• Откат: старые релизы остаются в releases/, поэтому достаточно вернуть симлинк current на предыдущую папку — по SSH или повторным запуском прошлого деплоя в разделе Environments GitLab (пока не истекли артефакты сборки, см. expire_in). Для Node-приложения с сервером после переключения добавляют перезапуск процесса (например, pm2 reload).

Для PHP-проекта на GitHub минимальный CI-этап выглядит так — проверка на каждый push в main и каждый pull request:

name: CI on: push: branches: [main] pull_request: jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: shivammathur/setup-php@v2 with: php-version: '8.3' - run: composer install --no-interaction --prefer-dist - run: vendor/bin/phpunit

CI/CD для Битрикс и WordPress: что не кладут в git

У CMS часть «кода» живёт в базе данных и загруженных файлах, а не в репозитории, — это надо учитывать.

1С-Битрикс

• В git — папка /local/ (свои компоненты, шаблоны, модули) и собственный код. Ядро /bitrix/ обычно не версионируют: оно обновляется штатной системой обновлений и весит гигабайты.
• /upload/ и база данных — вне git и вне пайплайна: пайплайн не должен их перезаписывать.
• Изменения структуры (инфоблоки, свойства, почтовые шаблоны, агенты) оформляются миграциями, например модулем sprint.migration, и накатываются пайплайном на этапе деплоя.
• .settings.php и dbconn.php с доступами к базе — на сервере, не в репозитории.

WordPress

• В git — своя тема и свои плагины; сторонние плагины и ядро удобно подключать через Composer (подход Bedrock), чтобы версии были зафиксированы.
• wp-content/uploads и база — вне git. wp-config.php с паролями — на сервере или собирается из переменных окружения.
• Боль WordPress — настройки в таблице опций: то, что поменяли в админке на stage, само на прод не поедет. Критичные настройки фиксируют в коде или переносят скриптами WP-CLI.

Секреты в CI/CD: где хранить пароли и ключи

Самая частая утечка паролей и токенов — не взлом, а файл .env, случайно закоммиченный в репозиторий, или пароль, напечатанный в логе пайплайна.

• Храните секреты в защищённых переменных платформы: masked и protected variables в GitLab, Secrets в GitHub Actions, либо во внешнем хранилище (HashiCorp Vault, Lockbox в Yandex Cloud).
• Разводите секреты по окружениям: ключ от production не должен быть доступен заданиям из feature-веток.
• Для деплоя — отдельный SSH-ключ и отдельный пользователь на сервере с правами только на папку сайта, не root.
• Если секрет хоть раз попал в git, удалить коммит мало — его нужно сменить.
• После ухода разработчика или подрядчика меняйте ключи деплоя и токены. Подробнее о том, что делать, если доступы остались у одного человека, — в статье «Сайт перестал работать, а программиста нет».

Сколько стоит внедрить CI/CD и от чего зависит цена

Стоимость определяется состоянием проекта: есть ли git, тесты, stage-сервер, насколько запутано окружение. Ориентиры на 2026 год:

Если пайплайн настраивается сразу в составе разработки сайта, базовый вариант обходится в 10 000 ₽. Итог зависит от стека, числа окружений и объёма подготовки. Точный состав и смету на настройку CI/CD имеет смысл считать после аудита репозитория. Если параллельно нужно подготовить сам сервер — пользователи, веб-сервер, Docker, мониторинг, — это отдельный блок работ по настройке сервера и DevOps; для небольшого сайта обычно хватает VPS, на виртуальном хостинге без SSH полноценный CI/CD не построить.

Типичные ошибки при внедрении CI/CD

• Автоматизировать хаос. Если на проде правят файлы руками «по горячему», пайплайн при следующей выкладке молча затрёт эти правки. Сначала — единый источник правды в git, потом автоматика.
• Сразу на прод без stage. Continuous Deployment без тестов и тестового окружения — это просто быстрый способ ронять сайт.
• Тесты, которые можно пропустить. Флажок allow_failure на тестах или «временно отключили линтер» превращают гейт в декорацию.
• Сборка на боевом сервере. git pull && npm install прямо на проде — это не CI/CD: версия зависимостей может отличаться от проверенной, а сайт недоступен, пока идёт сборка.
• Нет отрепетированного отката. Кнопка отката, которую ни разу не нажимали, в день аварии не сработает. Проверьте её на stage заранее.
• Чёрный ящик после подрядчика. Пайплайн без документации и доступа у заказчика — такой же риск, как его отсутствие.

Если код проекта настолько запутан, что его не удаётся покрыть даже базовыми тестами, начинать приходится с наведения порядка — об этом в статье про рефакторинг кода.

Чек-лист: готов ли проект к CI/CD

• Весь код, кроме ядра CMS, загрузок и секретов, лежит в git, а на сервере никто не правит файлы вручную
• Репозиторий и все доступы к нему оформлены на компанию, а не на личный аккаунт разработчика
• Есть сервер с SSH-доступом (VPS или облако), а не только FTP на виртуальном хостинге
• Есть отдельный stage-сервер или хотя бы отдельная копия сайта для проверки
• Проект собирается одной командой, зависимости зафиксированы lock-файлом
• Есть хотя бы минимальные тесты или линтер, которые можно поставить гейтом
• Пароли и ключи вынесены из кода в переменные окружения
• Изменения структуры базы оформляются миграциями, а не кликами в админке
• Понятно, кто нажимает кнопку релиза на production и как выполнить откат

CI/CD — способ сделать выкладку сайта скучной и предсказуемой. Начинать стоит с простого: git как единственный источник кода, проверки на каждый коммит, stage и деплой на прод по кнопке с понятным откатом. Continuous Deployment, Docker-реестры и инфраструктуру как код добавляют потом. Неудачный релиз нередко проявляется как ошибка 5xx, поэтому в пайплайн добавляют проверку, что после выкладки сайт отвечает без ошибок.