PHP Academy · Leçon

CI/CD avec GitHub Actions

Testez et déployez automatiquement PHP à chaque envoi.

CI/CD avec GitHub Actions est une leçon PHP Academy gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage PHP Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours PHP Academy comprend 4 leçons au total.

Intégration continue et déploiement continu pour PHP

Chaque envoi doit être testé, soumis à une vérification de style, analysé statiquement et — lorsqu’il est validé sur la branche principale — construit en image puis déployé. GitHub Actions exécute cette chaîne sur des exécuteurs gérés, déclenchée par les événements du dépôt.

Nous allons créer un flux de travail qui exécute PHPUnit avec un véritable service MySQL, met Composer en cache, exécute PHPStan, construit une image Docker et la déploie.

Structure d’un flux de travail

Un flux de travail se trouve dans .github/workflows/*.yml. Il comporte des déclencheurs on:, une ou plusieurs tâches jobs:, et chaque tâche comporte des étapes steps:. Les tâches s’exécutent sur des exécuteurs isolés en parallèle, sauf si elles sont liées par needs:.

name: CI
on:
  push:
    branches: [main]
  pull_request:

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

Action setup-php

shivammathur/setup-php est la méthode standard pour installer une version précise de PHP avec les extensions et les outils choisis (Composer, PHPStan, etc.) sur l’exécuteur — bien plus rapidement que de construire une image uniquement pour effectuer les tests.

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
          extensions: pdo_mysql, intl, redis, zip
          coverage: pcov
          tools: composer:v2, phpstan

Mettre Composer en cache

Retélécharger les dépendances à chaque exécution fait perdre des minutes. Mettez en cache le répertoire de Composer en le désignant par le hachage de composer.lock, afin que le cache ne soit invalidé que lorsque les dépendances changent.

      - name: Get Composer cache dir
        id: composer-cache
        run: echo "dir=$(composer config cache-files-dir)" >> $GITHUB_OUTPUT

      - uses: actions/cache@v4
        with:
          path: ${{ steps.composer-cache.outputs.dir }}
          key: composer-${{ hashFiles('**/composer.lock') }}
          restore-keys: composer-

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

Conteneurs de service

Les tâches peuvent lancer des conteneurs de service — un véritable MySQL ou Redis auquel l’exécuteur peut accéder via 127.0.0.1. Ajoutez une vérification de santé via options afin que les étapes ne s’exécutent pas avant que la base de données soit prête.

  test:
    runs-on: ubuntu-latest
    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_DATABASE: app_test
          MYSQL_ROOT_PASSWORD: root
        ports: ['3306:3306']
        options: >-
          --health-cmd="mysqladmin ping -proot"
          --health-interval=5s --health-retries=10

Exécuter les tests et mesurer la couverture

Une fois les dépendances installées et MySQL démarré, exécutez PHPUnit. Indiquez le DSN de test sur 127.0.0.1:3306. Générez la couverture et, si nécessaire, faites échouer la construction si elle est inférieure à un seuil.

      - name: Run PHPUnit
        env:
          DATABASE_URL: "mysql://root:root@127.0.0.1:3306/app_test"
        run: vendor/bin/phpunit --coverage-clover=coverage.xml

      - name: Static analysis
        run: phpstan analyse src --level=8 --no-progress

Constructions en matrice

Les bibliothèques doivent réussir leurs tests sur plusieurs versions de PHP. Une strategy.matrix répartit la tâche en exécutions parallèles, une par combinaison, avec ${{ matrix.php }} interpolé dans les étapes.

  test:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        php: ['8.2', '8.3', '8.4']
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}

Calculer l’étiquette de l’image

Les déploiements ont besoin d’une étiquette d’image unique et traçable. Le SHA de la validation est le choix habituel. Cet extrait montre la logique de dérivation de l’étiquette que vous exprimeriez dans le flux de travail — transformer une référence et un SHA en étiquette de registre.

<?php
// Mirrors what the workflow computes for the image tag
$ref = 'refs/heads/main';
$sha = '9f41efadc0de1234567890abcdef0000deadbeef';

$branch = str_replace('refs/heads/', '', $ref);
$shortSha = substr($sha, 0, 7);
$tag = sprintf('registry.example.com/app:%s-%s', $branch, $shortSha);

echo $tag . PHP_EOL;          // registry.example.com/app:main-9f41efa
echo 'is_main: ' . ($branch === 'main' ? 'yes' : 'no') . PHP_EOL;
?>

Construire et publier l’image

Sur la branche principale, construisez l’image Docker avec docker/build-push-action, en utilisant BuildKit et le cache de GitHub Actions. Connectez-vous d’abord au registre avec un jeton secret ; n’inscrivez jamais les identifiants en dur.

  build:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          target: runtime
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Informations sensibles et OIDC

Stockez les identifiants dans les informations sensibles du dépôt ou de l’environnement, référencées comme ${{ secrets.NAME }} — elles sont masquées dans les journaux. Pour les déploiements sur le cloud, préférez OIDC : l’exécuteur reçoit un jeton à courte durée de validité depuis AWS/GCP via permissions: id-token: write, de sorte qu’aucune clé à longue durée de validité ne soit conservée dans le dépôt.

  deploy:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      id-token: write     # enables OIDC
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/deploy
          aws-region: eu-central-1

Étape de déploiement et environnements

Soumettez les déploiements en production à l’approbation d’un environment GitHub, éventuellement avec des réviseurs obligatoires. L’étape de déploiement déclenche ensuite votre mise à jour progressive — en mettant à jour un déploiement Kubernetes, un service ECS ou en se connectant en SSH pour récupérer la nouvelle image.

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: production       # can require manual approval
      url: https://app.example.com
    steps:
      - name: Roll out
        run: |
          kubectl set image deployment/app \
            app=ghcr.io/${{ github.repository }}:${{ github.sha }}
          kubectl rollout status deployment/app --timeout=120s

Vérification rapide

Quel est le principal avantage de sécurité d’OIDC par rapport aux clés cloud stockées dans Actions ?

Récapitulatif

Vous avez créé une chaîne d’intégration continue et de déploiement continu PHP dans GitHub Actions : déclenchements sur envoi ou PR, setup-php avec extensions, Composer mis en cache selon le fichier de verrouillage, conteneur de service MySQL avec vérification de santé, PHPUnit + PHPStan, matrice de versions, puis construction-publication réservée à la branche principale avec cache GHA et déploiement authentifié par OIDC et soumis à un environnement.

Principes : utilisez les hachages du fichier de verrouillage pour le cache, conditionnez l’accès aux services prêts à leurs vérifications de santé, étiquetez les images avec le SHA et préférez OIDC aux clés stockées.

Questions Fréquemment Posées

La leçon « CI/CD avec GitHub Actions » est-elle gratuite ?

Oui — le texte complet de « CI/CD avec GitHub Actions » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours PHP Academy, passe à CoddyKit PRO. Le cours PHP Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « CI/CD avec GitHub Actions » ?

Testez et déployez automatiquement PHP à chaque envoi. Tu pratiques PHP Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer PHP Academy ?

Aucune expérience préalable n'est requise. PHP Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « CI/CD avec GitHub Actions » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon PHP Academy ?

Oui. Chaque leçon PHP Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

Conteneuriser une application PHP
Compilations multi-étapes et optimisation
Docker Compose pour les environnements locaux
CI/CD avec GitHub Actions

← Retour à PHP Academy