Chapitre 14.7 — CI avec GitHub Actions

Partie 14 : Tests & qualité — Chapitre 7/7 Version de référence : GitHub Actions / Symfony 7.4.

⏱️ TL;DR

• Une pipeline CI (intégration continue) exécute automatiquement, à chaque push/PR, l’ensemble des vérifications : tests, PHPStan, CS Fixer (dry-run), composer audit, schema:validate.
• Si une étape échoue, la CI bloque le merge — rien de cassé n’entre dans main.
• On utilise shivammathur/setup-php pour PHP, un service PostgreSQL pour les tests, et le cache Composer.
• C’est la porte de qualité : elle transforme les bonnes intentions (tester, analyser) en garanties appliquées.
• Pour un dev Next.js : c’est votre workflow GitHub Actions habituel — même fichier YAML, mais avec les outils PHP.

🎯 Objectifs

• Écrire un workflow GitHub Actions pour un projet Symfony.
• Enchaîner tests, analyse statique, style et audit.
• Fournir une base de données de test.
• Faire de la CI une porte de qualité bloquante.

1. Pourquoi une CI

Écrire des tests et configurer PHPStan/CS Fixer ne sert à rien s’ils ne sont pas exécutés. La CI les lance automatiquement à chaque contribution, avant le merge. Résultat : une PR ne peut être fusionnée que si tout passe — le code de main reste toujours vert.

2. Le workflow

# .github/workflows/ci.yml
name: CI
 
on:
  push: { branches: [main] }
  pull_request: ~
 
jobs:
  quality:
    runs-on: ubuntu-latest
 
    services:
      database:
        image: postgres:16-alpine
        env:
          POSTGRES_DB: app_test
          POSTGRES_USER: app
          POSTGRES_PASSWORD: '!ChangeMe!'
        ports: ['5432:5432']
        options: >-
          --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.4'
          extensions: ctype, iconv, intl, pdo_pgsql
          coverage: none
 
      - name: Install dependencies
        run: composer install --no-interaction --no-progress --prefer-dist
 
      - name: Analyse statique (PHPStan)
        run: vendor/bin/phpstan analyse --no-progress
 
      - name: Style (PHP CS Fixer)
        run: vendor/bin/php-cs-fixer fix --dry-run --diff
 
      - name: Vérifier le schéma Doctrine
        run: php bin/console doctrine:schema:validate --skip-sync
 
      - name: Migrations + tests
        env:
          DATABASE_URL: "postgresql://app:!ChangeMe!@127.0.0.1:5432/app_test?serverVersion=16"
        run: |
          php bin/console doctrine:migrations:migrate --no-interaction --env=test
          php bin/phpunit
 
      - name: Audit de sécurité des dépendances
        run: composer audit

3. Décryptage des étapes

Le service PostgreSQL fournit une base éphémère pour les tests fonctionnels/API (14.2-14.3). Chaque étape qui échoue fait échouer le job → la PR est bloquée.

4. Aller plus loin

• Matrice : tester sur plusieurs versions de PHP (8.3, 8.4) pour la compatibilité.
• Cache Composer : actions/cache pour accélérer les installs.
• Couverture de code : générer un rapport (Codecov) — utile, mais viser un taux n’est pas une fin en soi (mieux vaut de bons tests que 100 % de couverture creuse).
• Déploiement : un job supplémentaire qui déploie si la CI passe sur main (CD — Partie 15).

⚠️ Piège : une CI lente (plusieurs minutes) décourage et se fait contourner. Optimisez : cache des dépendances, jobs parallèles (PHPStan et tests en même temps), --prefer-dist. Et protégez la branche main (dans les réglages GitHub) pour exiger que la CI passe avant tout merge — sinon la porte de qualité est optionnelle, donc inutile.

💡 Pour un dev Next.js : c’est exactement votre ci.yml GitHub Actions, avec des étapes PHP au lieu de npm test/tsc/eslint. La philosophie est identique : bloquer le merge tant que tests + analyse + lint + audit ne passent pas. Sur un projet combiné (API Symfony + front Next.js), vous auriez deux jobs (ou deux workflows) : un pour le back (ce chapitre), un pour le front (vos habitudes). La qualité de bout en bout est ainsi garantie des deux côtés.

✏️ Exercices

Exercice 1. Quelles étapes minimales une CI Symfony sérieuse doit-elle enchaîner ?

Exercice 2. Pourquoi lancer composer audit en CI ?

Exercice 3. La CI passe, mais des développeurs mergent quand même des PR rouges. Que manque-t-il ?

🧠 Quiz de révision

Fin de la Partie 14. BookLab est testé (unitaire, fonctionnel, API), analysé (PHPStan), formaté (CS Fixer), modernisable (Rector) et gardé par une CI bloquante. On refactore et on déploie sans peur.

Prochaine étape : Partie 15 — Expert : perf, prod, architecture, industrialisation — passer BookLab en production, à l’échelle.