Налаштування CI/CD для PHP-додатків (Composer)

Налаштування 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, гарантія результату.