CI/CD

Без автоматизации выкладка выглядит так: разработчик собирает файлы у себя, заливает их на сервер, вручную чистит кеш и надеется, что ничего не забыл. CI/CD превращает эту последовательность в сценарий, который запускается сам после каждого пуша в репозиторий. Ошибки ловятся до того, как их увидят посетители, а выкладка перестаёт быть событием.

Аббревиатура объединяет три идеи. Непрерывная интеграция (CI) — сборка и тесты на каждое изменение. Непрерывная доставка (Continuous Delivery) — сборка всегда готова к выпуску, но кнопку «в продакшен» нажимает человек. Непрерывное развёртывание (Continuous Deployment) — прошедшие проверку изменения уходят на сервер сами.

Пример конфигурации GitLab CI

Файл .gitlab-ci.yml в корне репозитория описывает этапы. Здесь тесты запускаются на каждый коммит, а выкладка — только из ветки main:

stages: [test, deploy]

test:
  stage: test
  image: composer:2
  script:
    - composer install
    - vendor/bin/phpunit

deploy:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Если тесты упали, этап deploy не начнётся. В GitHub Actions та же логика описывается в файлах из папки .github/workflows.

Что обычно входит в конвейер

• Проверка синтаксиса и стиля кода, статический анализ.
• Модульные и интеграционные тесты.
• Сборка фронтенда: стили, скрипты, оптимизация.
• Выкладка на тестовый сервер, затем на боевой.
• Действия после выкладки: миграции базы, сброс кеша, уведомление в мессенджер.

Особенности для сайтов на CMS

В проектах на WordPress и 1С-Битрикс часть состояния живёт в базе и в загруженных файлах, а не в коде. Поэтому конвейер выкладывает только код темы, модулей и плагинов, а папку uploads и настройки в базе не трогает. Обновления ядра и сторонних модулей тоже лучше проводить отдельно, через тестовую копию. Подробнее о самих этапах выкладки — в статье про развёртывание.