CI/CD для PHP-проектов: Bitrix и Laravel на GitHub Actions без боли
Если ты до сих пор:
- деплоишь по SSH руками,
- боишься трогать main перед выходными,
- или проверяешь код «на глаз»,
— значит, CI/CD у тебя либо нет, либо он декоративный.
Разберём всё спокойно:
что такое CI/CD, зачем он нужен именно в PHP-проектах, и как его нормально настроить для Bitrix и Laravel с помощью GitHub Actions.
Что такое CI/CD — коротко и по делу
CI — Continuous Integration
CI — это автоматическая проверка кода при каждом изменении:
- код забрали из репозитория
- поставили зависимости
- проверили синтаксис
- запустили тесты
- убедились, что проект не развалился
Если что-то пошло не так — CI сразу об этом сообщает.
💡 CI отвечает на вопрос:
«Этот код вообще можно запускать?»
CD — Continuous Delivery / Deployment
CD — это автоматическая доставка кода дальше:
- на staging
- на production
- или хотя бы в готовый билд
💡 CD отвечает на вопрос:
«Можно ли этот код безопасно выкатить?»
Почему CI/CD особенно важен для PHP, Bitrix и Laravel
PHP-проекты часто страдают от трёх вещей:
- Человеческий фактор
«Я забыл обновить vendor», «Я не закоммитил файл», «У меня локально работало».
- Сложные окружения
PHP-версия, расширения, права, кеши, cron, агенты.
- Прод = страшно
Особенно в Bitrix, где ошибка = белый экран.
CI/CD убирает эту лотерею.
Почему именно GitHub Actions
GitHub Actions хороши тем, что:
- уже встроены в репозиторий
- не требуют отдельного сервера
- конфиг лежит рядом с кодом
- YAML читается как сценарий
Для 90% PHP-проектов — идеальный вариант.
Структура CI/CD в GitHub Actions
Файлы лежат здесь:
.github/
└── workflows/
└── ci.yml
Один файл = один сценарий.
Базовый CI для PHP-проекта
Начнём с минимального, но правильного CI.
Пример: CI для PHP 8.2 + Composer
name: PHP CI
on:
push:
branches: [main]
pull\_request:
jobs:
php-ci:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: "8.2"
extensions: mbstring, intl, pdo, pdo\_mysql
coverage: none
- name: Install dependencies
run: composer install --no-interaction --prefer-dist
- name: PHP syntax check
run: find . -type f -name "\*.php" -exec php -l {} \;
Разбираем, что здесь происходит (по-человечески)
on
on:
push:
branches: [main]
pull\_request:
CI запускается:
- при пуше в main
- при каждом Pull Request
❗ Важно:
CI без проверки PR — это самообман.
Установка PHP
uses: shivammathur/setup-php@v2
Это официальный де-факто action для PHP.
Можно указать:
- версию PHP
- расширения
- ini-настройки
Composer
composer install --prefer-dist
Это обязательно:
- проверяется composer.lock
- гарантируется воспроизводимость
- исключается «у меня работает»
Добавляем PHP-CodeSniffer (очень рекомендуется)
- name: Run PHP\_CodeSniffer
run: vendor/bin/phpcs --standard=PSR12 src/
CI должен ругаться на стиль, а не ты в код-ревью.
CI для Laravel: правильно и без магии
Laravel — это PHP + своя экосистема.
Минимальный CI для Laravel
- name: Copy env
run: cp .env.example .env
- name: Generate app key
run: php artisan key:generate
- name: Run migrations
run: php artisan migrate --force
- name: Run tests
run: php artisan test
💡 Важно:
В CI используется отдельная БД (обычно SQLite).
SQLite для CI (очень удобно)
DB\_CONNECTION=sqlite
DB\_DATABASE=:memory:
Быстро, изолированно, без лишнего геморроя.
CI для Bitrix: реальность, а не сказки
Bitrix — особый зверь. Но CI возможен и нужен.
Что реально проверять в CI под Bitrix
- ✔ PHP-синтаксис
- ✔ Composer (если используется)
- ✔ Пользовательский код (/local)
- ✔ Статический анализ
- ✔ Отсутствие фаталов
Пример CI для Bitrix-проекта
name: Bitrix CI
on:
pull\_request:
push:
branches: [main]
jobs:
bitrix-ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: "8.1"
extensions: mbstring, gd, mysqli
- name: PHP syntax check (local)
run: find local -type f -name "\*.php" -exec php -l {} \;
❗ Золотое правило Bitrix:
CI проверяет код, а не ядро.
Переходим к CD: деплой на сервер
Теперь — автоматическая выкладка.
Общая идея
- CI прошёл
- Код смержен в main
- Запускается деплой
- Сервер обновляется
Secrets: как не спалить сервер
В GitHub:
Settings → Secrets and variables → Actions
Добавляем:
- SSH_HOST
- SSH_USER
- SSH_KEY
Пример деплоя по SSH
- name: Deploy to server
if: github.ref == 'refs/heads/main'
run: |
ssh -o StrictHostKeyChecking=no $SSH\_USER@$SSH\_HOST "
cd /var/www/project &&
git pull &&
composer install --no-dev &&
php artisan migrate --force
"
❗ Никогда не храни логины и ключи в YAML.
Типовая схема CI/CD для PHP-проекта
PR → CI → merge → CI → CD → prod
Просто. Надёжно. Повторяемо.
Частые ошибки новичков
- ❌ CI запускается только вручную
- ❌ Нет проверки PR
- ❌ Деплой без условий
- ❌ Пароли в коде
- ❌ Один job на всё
- ❌ Нет логов
Хорошая практика (запомни)
- ✔ CI всегда на PR
- ✔ CD только из main
- ✔ Secrets только через GitHub
- ✔ Логи читаемы
- ✔ Минимум магии
- ✔ Максимум предсказуемости
Итог
CI/CD — это не «для больших».
Это для тех, кто хочет меньше ломать и больше спать.
Для PHP, Bitrix и Laravel:
- CI — обязателен
- CD — желателен
- GitHub Actions — отличный выбор
Если ты деплоишь руками — ты админ.
Если у тебя CI — ты разработчик.
Если есть CI/CD — ты инженер 😏
Top comments (0)