CI/CD avec GitHub Actions pour un projet Laravel

Mettre en place une chaîne d’intégration et de déploiement continus (CI/CD) permet de détecter les régressions avant qu’elles n’atteignent la production et de fiabiliser chaque mise en ligne d’une application Laravel. GitHub Actions, directement intégré au dépôt de code, est une option simple à mettre en œuvre pour ce type de workflow.

Sommaire

1. Principe général d’un pipeline CI/CD
2. Structure d’un workflow GitHub Actions pour Laravel
3. Exécuter les tests automatisés
4. Contrôles de qualité complémentaires
5. Déploiement automatisé

Principe général d’un pipeline CI/CD

L’intégration continue (CI) consiste à vérifier automatiquement, à chaque modification du code, que celui-ci compile, passe les tests et respecte les règles de qualité définies. Le déploiement continu (CD) va plus loin en automatisant la mise en production (ou sur un environnement de recette) une fois ces vérifications passées. L’objectif est de réduire le temps entre l’écriture d’un changement et sa mise à disposition, tout en limitant le risque d’erreur humaine lors du déploiement.

Structure d’un workflow GitHub Actions pour Laravel

Un workflow GitHub Actions se définit dans un fichier YAML placé dans .github/workflows/. Pour un projet Laravel, les étapes classiques sont : récupération du code, installation de PHP avec les extensions requises, installation des dépendances Composer, copie du fichier d’environnement de test, génération de la clé d’application, exécution des migrations sur une base de test, puis lancement de la suite de tests.

Le déclenchement du workflow se configure généralement sur les événements push et pull_request vers les branches principales, afin que chaque proposition de modification soit vérifiée avant fusion.

Exécuter les tests automatisés

Laravel embarque PHPUnit (ou Pest selon la configuration du projet) pour les tests unitaires et fonctionnels. Dans le pipeline, ces tests s’exécutent généralement contre une base de données dédiée — SQLite en mémoire pour la rapidité, ou un service MySQL/PostgreSQL démarré comme conteneur au sein du workflow lorsque le projet dépend de spécificités du moteur de base de données utilisé en production.

Faire échouer le workflow dès qu’un test échoue est la garantie que du code cassé n’est jamais fusionné sans que l’équipe en soit consciente.

Contrôles de qualité complémentaires

Au-delà des tests fonctionnels, un pipeline peut inclure une analyse statique du code (par exemple avec PHPStan ou Larastan pour Laravel), une vérification du style de code (Laravel Pint), ainsi qu’un audit des dépendances pour repérer des vulnérabilités connues via composer audit. Ces contrôles, exécutés automatiquement, évitent de dépendre uniquement de la vigilance humaine en revue de code.

Déploiement automatisé

Une fois les vérifications passées sur la branche principale, l’étape de déploiement peut se connecter au serveur cible via SSH pour tirer la nouvelle version du code, exécuter composer install --no-dev, lancer les migrations et vider les caches de configuration et de routes. Cette étape peut être conditionnée à une validation manuelle (environnement de production) ou totalement automatique (environnement de recette), selon le niveau de confiance et la criticité de l’environnement visé.

Chez Any In IT, la mise en place d’un pipeline CI/CD fait partie des fondations que nous recommandons dès qu’un projet Laravel dépasse le stade du prototype, pour sécuriser les livraisons dans la durée.