CI/CD pour projets PHP : GitHub Actions – guide complet

CI/CD pour les projets PHP : GitHub Actions

Le développement web moderne est impensable sans automatisation. Lancer manuellement les tests, vérifier le style du code et déployer sur le serveur prend du temps et est source d'erreurs. La solution est le CI/CD (Continuous Integration / Continuous Deployment). Dans cet article, nous allons voir comment configurer un pipeline complet pour les projets PHP à l'aide de GitHub Actions. Vous apprendrez à tester automatiquement le code, à vérifier sa qualité et à le déployer sur un serveur de production à chaque push dans le dépôt.

Qu'est-ce que le CI/CD et pourquoi en a-t-on besoin en PHP ?

Continuous Integration (CI) est une pratique où chaque commit est automatiquement vérifié : les tests unitaires, les linters et les vérifications de sécurité sont exécutés. Continuous Deployment (CD) est l'étape suivante, où le code ayant passé avec succès le CI est automatiquement déployé sur un serveur (staging ou production).

C'est particulièrement pertinent pour PHP : le langage est dynamique, les erreurs de typage et de syntaxe ne sont souvent détectées qu'à l'exécution. GitHub Actions permet de configurer un pipeline qui :

• Exécute les tests PHPUnit avec différentes versions de PHP (7.4, 8.0, 8.1, 8.2).
• Vérifie le code avec PHP_CodeSniffer ou PHPStan.
• Effectue le déploiement sur le serveur via SSH ou Docker.

Création d'un workflow dans GitHub Actions

Pour commencer, créez un répertoire .github/workflows à la racine de votre projet PHP. À l'intérieur, créez un fichier, par exemple ci.yml. Ce sera votre pipeline.

Examinons un exemple de base pour le CI. Il sera déclenché à chaque push sur la branche main ou lors de la création d'une Pull Request.

name: PHP CI

on:  push:    branches: [ "main" ]  pull_request:    branches: [ "main" ]

jobs:  build:    runs-on: ubuntu-latest

    strategy:      matrix:        php-versions: ['7.4', '8.0', '8.1', '8.2']

    steps:    - uses: actions/checkout@v3

    - name: Setup PHP      uses: shivammathur/setup-php@v2      with:        php-version: ${{ matrix.php-versions }}        tools: composer, phpunit

    - name: Validate composer.json and composer.lock      run: composer validate --strict

    - name: Cache Composer packages      id: composer-cache      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 --prefer-dist --no-progress

    - name: Run PHPUnit tests      run: phpunit --configuration phpunit.xml

Analyse des points clés :

• Matrix strategy — permet d'exécuter les tests sur plusieurs versions de PHP simultanément. Cela garantit la compatibilité du code.
• shivammathur/setup-php — un action populaire pour configurer l'environnement PHP. Il installe la version souhaitée, Composer et PHPUnit.
• Mise en cache du vendor — accélère les exécutions suivantes en ne retéléchargeant pas les dépendances.
• composer validate — vérifie la validité du fichier composer.json.

Ajout de l'analyse statique et du linting

Les tests, c'est bien, mais on ne peut pas se passer du contrôle de la qualité du code. Ajoutons au même workflow (ou créons un job séparé) une vérification avec PHPStan et PHP_CodeSniffer.

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

    - name: Run PHP_CodeSniffer      run: vendor/bin/phpcs --standard=PSR2 src tests

Ces étapes peuvent être ajoutées après l'installation des dépendances. PHPStan avec le niveau max trouvera les erreurs de type potentielles, et PHP_CodeSniffer avec la norme PSR-2 (ou PSR-12) garantira un style de code uniforme. Si l'une de ces étapes échoue,