CI/CD pour projets PHP : GitHub Actions niveau avancé

Introduction : du CI/CD de base au niveau production

Un pipeline CI/CD de base qui se contente d'exécuter des tests, c'est bien. Mais pour un projet PHP sérieux, cela ne suffit pas. Dans le développement réel, la mise en cache des dépendances pour accélérer les builds, les tâches parallèles, les builds matricielles pour différentes versions de PHP, l'analyse statique et, bien sûr, le déploiement automatique sont nécessaires. Dans cet article, nous allons détailler les techniques avancées de configuration de GitHub Actions pour les projets PHP à l'aide d'exemples pratiques.

Nous supposons que vous êtes déjà familier avec les bases de la syntaxe YAML et la structure fondamentale de .github/workflows. Passons maintenant à l'optimisation et à l'extension des possibilités.

1. Accélération des builds : mise en cache de Composer et stratégie optimale

Chaque exécution de workflow télécharge les dépendances à nouveau. Cela prend 1 à 3 minutes, qui peuvent être réduites à 5 à 10 secondes grâce à la mise en cache.

Mise en cache intelligente du dossier vendor

Utilisons actions/cache avec une clé basée sur le hash de composer.lock. Si le fichier de verrouillage n'a pas changé, les dépendances seront restaurées depuis le cache.

name: PHP CIon: [push, pull_request]

jobs:  test:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4

      - name: Setup PHP        uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          tools: composer:v2

      - name: Cache Composer dependencies        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-${{ hashFiles('**/composer.lock') }}          restore-keys: |            ${{ runner.os }}-php-

      - name: Install dependencies        run: composer install --no-progress --prefer-dist

Notez restore-keys : si la clé exacte n'est pas trouvée, le dernier cache pour ce système d'exploitation sera utilisé. Cela sert de filet de sécurité lors du changement de branches.

Build matricielle pour différentes versions de PHP

Pour garantir la compatibilité, testez sur plusieurs versions de PHP en parallèle :

jobs:  test:    strategy:      matrix:        php-version: ['8.1', '8.2', '8.3']        dependency-stability: [prefer-lowest, prefer-stable]

    steps:      - uses: actions/checkout@v4      - name: Setup PHP ${{ matrix.php-version }}        uses: shivammathur/setup-php@v2        with:          php-version: ${{ matrix.php-version }}

      - name: Cache        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php${{ matrix.php-version }}-${{ hashFiles('**/composer.lock') }}

      - name: Install dependencies        run: |          composer update --${{ matrix.dependency-stability }} --prefer-dist --no-interaction

      - name: Run tests        run: vendor/bin/phpunit

Cette approche révèle les problèmes de compatibilité avant même la fusion dans la branche principale. Vous obtiendrez 6 jobs parallèles (3 versions × 2 stratégies de stabilité).

2. Étapes avancées : analyse statique et qualité du code

Les tests unitaires ne sont pas le seul outil de contrôle qualité. Ajoutons PHPStan (niveau d'analyse maximal) et PHP Code Sniffer.

Linting et analyse statique

Créez un job séparé pour l'analyse, qui s'exécute en parallèle des tests :

jobs:  static-analysis:    runs-on: ubuntu-latest    steps:      - uses: actions/checkout@v4      - uses: shivammathur/setup-php@v2        with:          php-version: '8.2'          coverage: none

      - name: Cache        uses: actions/cache@v3        with:          path: vendor          key: ${{ runner.os }}-php-static-${{ hashFiles('**/composer.lock') }}

      - run: composer install --no-interaction --prefer-dist

      - name: PHPStan        run: vendor/bin/phpstan analyse --level=max src/

      - name: PHPCS        run: vendor/bin/phpcs --standard=PSR12 src/