Я обычно настраиваю Git CI/CD для сайта так, чтобы деплой был не «кнопкой в панике», а повторяемым и предсказуемым процессом. В 2026 году это уже не роскошь, а нормальная гигиена для проектов на PHP 8.1–8.4, WordPress, Bitrix и Laravel: меньше ручных ошибок, быстрее выкладки, проще откат, ниже риск положить прод в пятницу вечером.
Почему Git CI/CD для сайта в 2026 году — это не роскошь
Если у вас сайт живёт в состоянии «залили по FTP, посмотрели, что сломалось, потом починили», честно говоря, это плохая идея. На моей практике такие схемы почти всегда приводят к одному и тому же: файлы теряются, кто-то забывает про кеш, база уезжает отдельно от кода, а потом начинается поиск виноватого. Git CI/CD решает именно эту боль: код хранится в репозитории, сборка и тесты идут автоматически, а прод получает только проверенную версию.
Я обычно объясняю клиентам просто: CI/CD — это конвейер. CI проверяет код, запускает тесты, линтеры, статанализ, сборку ассетов. CD отвечает за доставку на сервер. Для сайта это особенно полезно, потому что изменений много: шаблоны, стили, JS, миграции, конфиги Nginx, php.ini, CRON-задачи, иногда даже интеграции с CRM. И всё это должно ехать в прод без хаоса.
Если вам нужна не просто теория, а нормальная доработка сайта под задачу, я бы вообще начинал с аудита процессов. Иногда выгоднее сначала навести порядок в структуре проекта и деплоя, а уже потом вкатывать CI/CD. Для этого уместно смотреть и доработка сайта, и проверка сайта, потому что часто выясняется: проблема не в Git, а в бардаке в кодовой базе и окружениях.
И ещё момент. На проектах с посещаемостью от 5–10 тысяч визитов в сутки любая ошибка деплоя уже стоит денег. Один раз у меня был клиент на Bitrix 24 / PHP 8.2 / MySQL 8.0, где релиз через FTP ломал 404-страницы и sitemap.xml. По итогу Google Search Console показывал просадку по индексации, а команда теряла день на поиск причины. После нормальной CI/CD-схемы проблема ушла. Да, не магия. Просто дисциплина.
С какими инструментами работает Git CI/CD для сайта
Если говорить по опыту, самый частый стек в 2026 году выглядит так: GitHub Actions, GitLab CI/CD, Bitbucket Pipelines или self-hosted runner на VPS/выделенном сервере. Для сайта я чаще всего вижу GitHub Actions и GitLab CI, потому что они удобно дружат с PHP-проектами, Composer, npm, PHPUnit, PHPStan, Larastan и деплоем по SSH.
Для WordPress обычно хватает более простого пайплайна: проверка PHP Syntax, запуск PHPCS, сборка темы, копирование файлов на staging, потом на production. Для Laravel логика уже серьезнее: миграции, очереди, кэш конфигов, кэш роутов, symlink release-папки. Для Bitrix всё зависит от архитектуры, но общая схема та же: сначала тесты и сборка, потом развёртывание без лишней ручной магии.
Если проект живёт на нормальном хостинге или VPS, я обычно советую сразу проверить окружение: SSH-доступ, ключи, права, возможность запускать Composer 2.7+, Node.js 20/22, доступ к PHP 8.1/8.2/8.3/8.4. Если этого нет, CI/CD превращается в мучение. В таких случаях сначала нужна нормальная инфраструктура и, возможно, калькулятор стоимости сайта — чтобы оценить, во что выльется перенос на более адекватную схему.
Я обычно начинаю с выбора модели деплоя. Их три:
- deploy on push — деплой на сервер при каждом пуше в нужную ветку;
- deploy on tag — выкладка только по тегу релиза;
- deploy on manual approval — сначала автоматические проверки, потом ручное подтверждение.
Для коммерческих сайтов я чаще выбираю второй или третий вариант. Автовыкладка на каждый пуш — это нормально для небольших проектов, но на интернет-магазинах, корпоративных порталах и CRM-интеграциях я бы так не рисковал.
Пошаговая схема настройки CI/CD для сайта
Ниже дам рабочую последовательность, которой я сам пользуюсь на практике. Она подходит и для Laravel, и для WordPress, и для Bitrix с поправками на структуру проекта. Если делать всё без спешки, потом можно спокойно жить, а не тушить пожары после каждого коммита.
1. Привести репозиторий в порядок
Первый шаг — нормальная структура репозитория. В нём должны быть только нужные файлы: код, конфиги, шаблоны, composer.json, package.json, миграции, скрипты сборки. Никогда не тащите в Git временные файлы, кеши, vendor/ и node_modules/ без особой причины. Это мусор, и он только раздувает историю.
Я обычно добавляю .gitignore сразу под проект. Для PHP-сайта он выглядит примерно так:
/vendor/
node_modules/
.env
.env.local
/storage/logs/
/storage/framework/cache/
/public/build/
/bitrix/cache/
/bitrix/managed_cache/
/upload/
*.logНо тут есть нюанс. Для Bitrix папку upload часто держат отдельно и не коммитят, а для WordPress — вообще почти всегда исключают. Для Laravel наоборот, можно оставить пустые каталоги через .gitkeep, чтобы структура не ломалась.
2. Разделить окружения: dev, staging, production
Без staging я CI/CD не запускаю. Это не обсуждается. Staging-сайт нужен не для красоты, а чтобы поймать ошибки до продакшена. У одного клиента на Laravel 10 / PHP 8.3 / MySQL 8.0 миграция проходила локально, но падала на сервере из-за отличий в SQL_MODE. Если бы релиз шёл сразу в прод, мы бы словили простой. А так нашли проблему на staging и спокойно поправили.
Хорошая схема такая: push в feature-ветку — автотесты; merge в develop — деплой на staging; tag v1.2.3 — релиз на production. Для сайта с командой из 2–5 человек этого обычно хватает с головой. Если проект крупнее, добавляют review apps, pre-prod и smoke-тесты после деплоя.
Кстати, про staging у меня есть отдельный материал: как настроить staging-сайт для безопасной проверки обновлений. И ещё полезно почитать safe update для сайта, если вы боитесь обновлений и откатов. А бояться тут, честно говоря, есть чего, если всё сделано вручную.
3. Настроить SSH-доступ и ключи
Для деплоя по SSH я всегда рекомендую ключи, а не пароли. Иначе это лишний риск. Нормальная схема — отдельный пользователь на сервере, ограниченные права, ключи только для CI runner. Если хотите, чтобы доступ был ещё безопаснее, посмотрите настройка SSH-ключей для сервера.
Пример простого деплой-скрипта через SSH:
#!/usr/bin/env bash
set -euo pipefail
APP_DIR="/var/www/site"
RELEASE_DIR="$APP_DIR/releases/$(date +%Y%m%d%H%M%S)"
CURRENT_LINK="$APP_DIR/current"
mkdir -p "$RELEASE_DIR"
rsync -az --delete \
--exclude='.env' \
--exclude='node_modules' \
--exclude='vendor' \
./ "$RELEASE_DIR/"
cd "$RELEASE_DIR"
composer install --no-dev --optimize-autoloader
npm ci
npm run build
ln -sfn "$RELEASE_DIR" "$CURRENT_LINK"
php artisan migrate --force
php artisan config:cache
php artisan route:cacheДа, для WordPress или Bitrix этот скрипт будет другим, но логика та же: копируем только нужное, ставим зависимости, собираем, переключаем симлинк, прогоняем post-deploy команды.
4. Добавить автоматические проверки
CI без проверок — это просто автоматический перенос ошибок на сервер. Я обычно включаю минимум: syntax check для PHP, PHPUnit или хотя бы smoke-тесты, PHPStan/Larastan, PHPCS, тест сборки фронтенда. Для проекта на PHP 8.2 и 8.3 это особенно полезно, потому что несовместимости всплывают быстро.
Если у вас Laravel, однозначно стоит добавить PHPStan и Larastan. Если WordPress — PHPCS с WordPress Coding Standards. Если Bitrix — хотя бы базовый static analysis и проверку шаблонов. На моей практике именно тесты экономят больше всего времени, потому что ловят банальные косяки до заливки на сервер.
Пример GitHub Actions для PHP-сайта
Ниже дам упрощённый, но рабочий пример GitHub Actions. Он подходит как отправная точка для сайта на PHP 8.2/8.3 с Composer и сборкой фронта. В реальном проекте я обычно добавляю ещё кэш зависимостей, отдельный job для тестов и деплой только после успешного build.
name: Deploy website
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.3'
extensions: mbstring, intl, pdo_mysql, zip
tools: composer:v2
- name: Install dependencies
run: composer install --no-interaction --prefer-dist --no-progress
- name: PHP syntax check
run: find . -name "*.php" -not -path "./vendor/*" -exec php -l {} \;
- name: Run tests
run: vendor/bin/phpunit
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Deploy via SSH
uses: appleboy/ssh-action@v1.0.3
with:
host: ${{ secrets.SSH_HOST }}
username: ${{ secrets.SSH_USER }}
key: ${{ secrets.SSH_KEY }}
script: |
cd /var/www/site/current
git pull origin main
composer install --no-dev --optimize-autoloader
npm ci
npm run build
php artisan migrate --force
php artisan config:cacheЕсли у вас WordPress, я бы не делал git pull прямо в текущей директории без release-папок. Можно, конечно, и так, но это уже компромисс. Для небольшого сайта с блогом это сойдёт. Для интернет-магазина — нет, забудьте про это.
В Bitrix я обычно делаю иначе: кодовая база в Git, шаблоны и локальные компоненты в репозитории, а пользовательский контент отдельно. Деплой идёт либо через rsync, либо через release-директории. И да, после релиза обязательно проверяется кеш и права на файлы. Иначе потом ловите странные ошибки в админке и 500 на фронте. Если сайт уже ведёт себя нестабильно, сначала смотрю ошибка 500 на сайте: причины и решения и как исправить 502 Bad Gateway, а потом уже копаю CI.
Деплой на Nginx и .htaccess: как не сломать сайт
На деле половина проблем CI/CD связана не с Git, а с веб-сервером. Я видел десятки случаев, когда код выкатили нормально, а сайт падал из-за неверного конфига Nginx, плохих прав на папки или несинхронизированного .htaccess. И это не мелочь. Если сервер настроен криво, никакой CI вам не поможет.
Для Nginx у меня обычно есть отдельный шаблон, где продуманы кэш, статика, PHP-FPM и fallback-обработка. Пример блока для Laravel или другого PHP-сайта:
server {
listen 443 ssl http2;
server_name example.com www.example.com;
root /var/www/site/current/public;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_read_timeout 60s;
}
location ~* \.(jpg|jpeg|png|gif|webp|avif|css|js|svg|ico)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000, immutable";
access_log off;
}
}Если у вас Apache и .htaccess, логика похожая, но надо быть аккуратнее с редиректами и rewrite-правилами. После релиза обязательно проверяйте, не сломались ли канонические URL, HTTPS-редиректы и правила для ЧПУ. Тут очень уместна статья как настроить 301 редиректы через .htaccess и Nginx. А если сайт уже переживал смену структуры, посмотрите ещё как настроить 301 и 302 редиректы без петель и 404.
Я обычно после каждого релиза проверяю минимум пять вещей:
- главная открывается без 500 и 502;
- форма отправки работает;
- логин в админку доступен;
- robots.txt и sitemap.xml отдаются корректно;
- страницы 404 и 301-редиректы не сломались.
И ещё. Если у вас в проекте есть CDN, то CI/CD должен уметь делать purge кэша после деплоя. Иначе пользователи будут видеть старые CSS и JS ещё 10–30 минут, а иногда и дольше. Об этом я отдельно писал в статье настройка очистки кэша и CDN purge.
Безопасность: секреты, откат и ручной контроль
CI/CD — это не только скорость. Это ещё и безопасность. Если вы храните пароли, ключи API, токены CRM и SMTP прямо в репозитории, это уже проблема. Секреты должны жить в GitHub Secrets, GitLab CI Variables, Vault или хотя бы в защищённом env-файле на сервере. И никаких исключений.
Был случай: у одного клиента токен Telegram-бота для уведомлений лежал в публичной переменной и улетел в лог. Потом пошли спам-сообщения в канал поддержки. Пришлось срочно менять токены, проверять доступы, чистить историю и пересобирать пайплайн. После этого мы сделали нормальное хранение секретов и включили ротацию. Если у вас сайт интегрирован с уведомлениями, посмотрите Telegram-бота для заявок и ошибок и защита API-ключей на сайте.
Откат — это вообще ключевая часть CI/CD. Я обычно делаю так: текущая версия — симлинк current, прошлые релизы лежат в releases/, база имеет миграции с обратной совместимостью, а деплой-скрипт умеет быстро переключать ссылку назад. Если релиз сломался, мы не ковыряемся на проде, а просто откатываемся. Это сильно снижает стресс, особенно на проектах с высокой нагрузкой.
И да, перед релизом полезно прогонять автоматические проверки безопасности: Snyk, Dependabot, Composer audit, npm audit, статический анализ. Для WordPress и Bitrix я бы ещё проверял версии PHP и совместимость модулей. На PHP 8.1 что-то ещё живёт, но в 2026 году я бы смотрел минимум на 8.2 или 8.3, а для новых проектов — уже на 8.4, если кодовая база готова.
Типичные ошибки при настройке и как их исправить
Чаще всего проблемы повторяются одни и те же. Первое — деплой идёт из main без тестов. Второе — на сервере нет нужных расширений PHP. Третье — composer install запускается без --no-dev на проде, и туда уезжают лишние пакеты. Четвёртое — забывают очистить кеш. Пятое — не проверяют права на файлы и папки.
Я бы ещё отдельно выделил ошибку с базой данных. На Laravel и Bitrix нередко делают релиз, потом миграции, а потом уже смотрят, что страницы упали из-за несовместимости схемы. Правильнее наоборот: сначала подготовить схему, проверить совместимость кода, только потом переключать трафик. Если у вас WordPress, не забывайте про плагины и их данные — там тоже можно легко потерять часть настроек.
В моей практике очень часто спасает «сухой прогон» деплоя на staging с логированием всех шагов. Если скрипт на этом этапе падает, это хорошо. Значит, в прод это не поедет. И вот тут автоматическое тестирование сайта реально окупается. Уместно почитать автоматическое тестирование сайта и настройка логов сайта, потому что без нормальных логов CI/CD превращается в гадание на кофейной гуще.
CI/CD для WordPress, Bitrix и Laravel: что отличается
Если брать WordPress, то там основной риск — плагины, тема и обновления ядра. Я бы не ставил автоматический деплой без staging и проверки критичных страниц. Очень полезно почитать как ускорить WordPress и как настроить автообновление CMS, потому что на WordPress релизы часто конфликтуют с обновлениями плагинов.
Для Bitrix всё обычно упирается в кеш, структуру шаблонов и зависимость от сервера. Тут особенно важны права, версии PHP и аккуратная работа с managed cache. Я бы отдельно проверял совместимость с модулем главного модуля, инфоблоков и кастомных компонентов. И если сайт уже «наследил» техническим долгом, сначала я смотрю технический долг сайта, а потом выстраиваю CI/CD.
Laravel обычно самый благодарный вариант для CI/CD. Там удобно выстраивать release-подход, миграции, очереди, конфиги, кэш, тесты и деплой через SSH или GitHub Actions. Но и тут есть нюансы: нужно следить за .env, за очередями, за cron/scheduler, за правами storage и bootstrap/cache. На проекте с Laravel 11 и MySQL 8.0 я обычно делаю деплой на симлинках и после релиза запускаю cache:clear, config:cache, route:cache, view:cache.
Если вам нужен не просто код, а нормальная настройка силами специалиста, я бы не тянул. Особенно когда проект уже зарабатывает деньги. В таких случаях лучше сразу заказать поддержку Bitrix или поддержку WordPress, потому что CI/CD — это не разовая настройка, а часть постоянной поддержки сайта.
Что в 2026 меняется и к чему готовиться
В 2026 году CI/CD для сайта всё сильнее связан с безопасностью, наблюдаемостью и автоматизацией. Уже мало просто «залить код». Нужны уведомления о сбоях, мониторинг 502/500, контроль 404, проверка mixed content, контроль CSP, отслеживание метрик скорости. Я бы даже сказал, что CI/CD теперь — это часть общей эксплуатации сайта.
На больших проектах я всё чаще добавляю автоматическую проверку производительности после релиза. Например, прогон Lighthouse, замер Core Web Vitals, проверка времени ответа сервера, smoke-test страниц корзины или заявки. Если после релиза LCP уехал с 1.8s до 3.9s, это уже не «ну, потом разберёмся», а повод откатить релиз или копать фронт.
Сюда же относятся 404-мониторинг, уведомления в Telegram, контроль uptime и защита от внезапных ошибок. У меня был случай, когда после внедрения CI/CD мы поймали не кодовую ошибку, а отсутствие одного файла шрифта. Вручную это бы заметили не сразу, а автоматическая проверка после деплоя подняла тревогу через 40 секунд. И это, грубо говоря, спасло вечер.
Если хотите выстроить процесс без нервов, я бы начинал с аудита текущего состояния сайта, потом настраивал staging, затем тесты и только после этого подключал автодеплой. И да, если проект уже «горит», сначала стоит сделать SEO-аудит сайта в связке с техническим аудитом, а потом уже наводить порядок в релизах. Иногда проблема вовсе не в Git, а в том, что сайт давно живёт без регламента и контроля изменений.
Если коротко, то хорошая настройка Git CI/CD экономит время, деньги и нервы. Но работает она только тогда, когда вы не ленитесь делать staging, бэкапы, тесты и нормальный откат. На плохой базе никакой пайплайн не спасёт. А на хорошей — он реально превращает хаотичные выкладки в спокойный рабочий процесс.
Хотите настроить Git CI/CD для сайта без ошибок?
Поможем выстроить надежный пайплайн для сборки, тестов и деплоя вашего сайта в 2026 году.