Настройка CI/CD для PHP-приложений (Composer)

Пайплайн CI ждёт 90 секунд только на composer install. Разработчик коммитит, идёт за кофе, возвращается — а сборка ещё не дошла до тестов. Мы, как DevOps-инженеры с 7+ летним опытом, такое видели десятки раз. Решение — кеширование vendor и правильные флаги Composer. С ними время пайплайна сокращается до 8 секунд на ту же операцию. Экономия времени в 10+ раз означает для команды из десяти человек на час быстрее фидбек каждый день. За месяц это выливается в существенное снижение затрат на облачные раннеры — до десятков тысяч долларов. В этой статье — как настроить CI/CD для PHP так, чтобы он летал, и какие подводные камни встречаются именно в PHP-проектах.

Почему большинство PHP-проектов теряет время в CI?

Самые частые проблемы — отсутствие кеша Composer, запуск тестов без статического анализа и игнорирование Docker-оптимизаций. Рассмотрим каждую с цифрами.

Composer без кеша — это 60–120 секунд на каждый коммит для типового Laravel-проекта. С кешем — 5–10 секунд. Экономия в 10+ раз за один шаг.

PHPStan без baseline — на legacy-проектах анализатор валится на 500+ ошибках, разработчики просто отключают его. Правильный baseline фиксирует текущие ошибки и запрещает только новые.

Docker-образы без multistage — весят 1–2 ГБ, забивают реестр и замедляют деплой. Multistage-сборка даёт образ 100–200 МБ, что ускоряет передачу и снижает затраты на хранение.

Как мы настраиваем CI/CD для PHP под ключ

Наш подход — выстроить пайплайн, который проходит за 2–3 минуты и выдаёт релиз с гарантией. Разберём каждый этап.

Composer: кеш и правильные флаги

Согласно документации Composer, флаг --prefer-dist ускоряет установку зависимостей за счёт загрузки архивов. В CI обязательно используйте:

---
- uses: actions/cache@v4
  with:
    path: ~/.composer/cache
    key: ${{ runner.os }}-composer-${{ hashFiles('composer.lock') }}
    restore-keys: |
      ${{ runner.os }}-composer-
- run: composer install --no-interaction --no-progress --prefer-dist --optimize-autoloader
---

--optimize-autoloader генерирует classmap вместо PSR-4 поиска — в продакшене загрузка классов быстрее. composer.lock должен быть в репозитории — без него установка будет резолвить версии заново.

Почему кеширование Composer критично?

Без кеша каждый коммит тратит минуту на скачивание зависимостей. С кешем — секунды. На проекте с 50 коммитами в день экономия — почти час процессорного времени, что прямо конвертируется в экономию бюджета. Кеш сохраняется по ключу на основе composer.lock — при изменении зависимостей он инвалидируется автоматически.

Какую базу данных использовать в тестах?

Если тесты используют PostgreSQL-специфичные возможности (jsonb, полнотекстовый поиск, arrays), нужен реальный сервис. Для остальных случаев достаточно SQLite in-memory — это быстрее и не требует дополнительных контейнеров. Настройка сервиса через services в CI занимает 5 строк.

Инструменты статического анализа для PHP

PHPStan — статический анализатор с уровнями 0–9. Для legacy-проекта наш рецепт:

./vendor/bin/phpstan analyse --level=5 --configuration=phpstan.neon --generate-baseline 

Baseline фиксирует текущие ошибки в phpstan-baseline.neon, дальше блокируются только новые. Постепенно поднимайте level до 6–9.

PHP_CodeSniffer или PHP CS Fixer — для поддержания PSR-12. Мы используем PHP CS Fixer в CI в режиме --dry-run, а локально — с автоисправлением.

Laravel-специфика в CI

Artisan в CI: php artisan config:clear && php artisan migrate --force --no-interaction && php artisan db:seed --class=TestSeeder --no-interaction. --force обязателен — без него Laravel спрашивает подтверждение.

Очереди и Redis. Если тесты запускают jobs через Queue::fake() — Redis не нужен. Если тестируется реальная обработка — добавить Redis-сервис в CI.

Docker для PHP: multistage-сборка под ключ

FROM php:8.3-fpm-alpine AS builder
RUN apk add --no-cache git unzip libzip-dev \
    && docker-php-ext-install pdo pdo_pgsql zip opcache
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /var/www
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts --prefer-dist --optimize-autoloader
COPY . .
RUN composer run-script post-autoload-dump
FROM php:8.3-fpm-alpine
COPY --from=builder /var/www /var/www

OPcache в продакшене обязателен. Конфиг opcache.ini:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
; в продакшене — не проверять изменения файлов

validate_timestamps=0 важно: с ним OPcache не проверяет файлы на диске на каждый запрос. При деплое перезапускаем FPM или вызываем opcache_reset().

Варианты деплоя: от VPS до Kubernetes

Kubernetes + Nginx sidecar — PHP-FPM pod и рядом Nginx, общий volume. ConfigMap для nginx.conf и php.ini.

VPS через Deployer — vendor/bin/dep deploy production — zero-downtime с атомарным symlink. Laravel Forge / Ploi — платформы для деплоя PHP — хороши, когда не нужен Kubernetes.

Что входит в настройку CI/CD под ключ

• Разработка и внедрение пайплайна CI/CD (GitHub Actions / GitLab CI / Jenkins).
• Кеширование Composer и node_modules (если есть фронтенд).
• Настройка PHPUnit, PHPStan, PHP CS Fixer.
• Multistage Docker-сборка с OPcache.
• Деплой на Kubernetes (через ArgoCD или Helm) или VPS (через Deployer).
• Интеграция с мониторингом (Grafana + Loki, или Datadog).
• Документация по пайплайну и runbook для инцидентов.
• Поддержка 2 недели после запуска.

Процесс работы над CI/CD

1. Аудит текущего пайплайна и инфраструктуры. Выявляем узкие места (кеш, версии инструментов, конфиги).
2. Проектирование пайплайна: выбор CI-системы (GitHub Actions, GitLab CI), определение стадий, написание Dockerfile.
3. Реализация — настройка кешей, статического анализа, тестов, сборки образов.
4. Тестирование — прогон пайплайна на тестовом окружении, исправление ошибок.
5. Передача — документация, обучение команды, гарантийная поддержка 30 дней.

Ориентировочные сроки

Закажите настройку CI/CD — и ваша команда перестанет ждать сборки. Свяжитесь с нами для консультации. Наш опыт: 7+ лет, 50+ внедрений CI/CD для PHP, гарантия результата.