CI/CD pour PHP à partir de zéro : guide étape par étape pour configurer un pipeline

Pourquoi avez-vous besoin de CI/CD si vous n'êtes pas un robot ?

Imaginez : vendredi soir, vous venez de terminer une fonctionnalité, vous téléchargez le code sur le serveur via FTP (oui, ça existe encore), et… le site plante avec un écran blanc de la mort. Ça vous dit quelque chose ? Et si vous aviez un pipeline CI/CD pour PHP, tout se serait fait automatiquement : les tests auraient échoué dès le push, le code ne serait pas parti en production, et vous auriez tranquillement bu un thé.

L'intégration continue et la livraison continue (ou déploiement continu) ne sont pas que des abréviations à la mode. Ce sont vos assistants personnels qui vérifient le code, exécutent les tests, font du linting, construisent les artefacts et déploient sur le serveur. Dans cet article, je vais vous montrer comment configurer un pipeline CI/CD pour PHP à partir de zéro en utilisant GitHub Actions. Pas d'abstractions – seulement du code réel et des exemples concrets.

Qu'est-ce qu'un pipeline CI/CD et pourquoi un développeur PHP en a besoin

Un pipeline CI/CD est une séquence d'étapes automatiques qui s'exécutent chaque fois que vous poussez du code dans un dépôt. Pour PHP, c'est particulièrement pertinent car :

\n
• PHP est un langage dynamique, et de nombreuses erreurs (fautes de frappe, types incorrects) n'apparaissent qu'à l'exécution.
\n
• Le déploiement est souvent fait « à la va-vite » – via SCP, rsync ou même FTP (un cri du cœur).
\n
• Les équipes grandissent et les vérifications manuelles deviennent un goulot d'étranglement.
\n

En configurant un CI/CD pour PHP, vous obtenez :

\n
• Des tests automatiques à chaque push.
\n
• Une vérification du style de code (PSR-12, votre standard interne).
\n
• Un déploiement automatique sur staging/production.
\n
• Des notifications Telegram/Slack sur le statut de la build.
\n

Choisir l'outil : pourquoi GitHub Actions ?

Il existe de nombreuses options : Jenkins, GitLab CI, Bitbucket Pipelines, CircleCI. Mais pour la configuration d'un pipeline CI/CD pour PHP à partir de zéro, je recommande GitHub Actions. Pourquoi ?

\n
• Gratuit pour les dépôts publics (et 2000 minutes par mois pour les privés – largement suffisant).
\n
• Tout au même endroit – code, issues, actions.
\n
• Un vaste écosystème d'actions prêtes à l'emploi – pas besoin de réinventer la roue.
\n

Mais si vous utilisez GitLab – les principes sont les mêmes, seul le syntaxe YAML diffère. C'est parti.

Étape 1 : Structure du dépôt et fichiers de base

Pour la démonstration, prenons un projet PHP typique avec Laravel (mais l'approche fonctionne pour n'importe quel framework). Votre structure devrait ressembler à ceci :

my-php-app/\n├── .github/\n│   └── workflows/\n│       └── ci-cd.yml\n├── src/\n├── tests/\n├── composer.json\n├── phpunit.xml\n└── .php_cs.dist (si vous utilisez PHP-CS-Fixer)

Créez le dossier .github/workflows/ et le fichier ci-cd.yml – c'est le cœur de votre pipeline.

Étape 2 : YAML de base – Intégration continue (CI)

Commençons simplement : exécution des tests et linting à chaque push sur main ou pull request. Voici un pipeline CI/CD pour PHP minimal :

name: PHP CI/CD Pipeline\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n      - uses: actions/checkout@v4\n\n      - name: Setup PHP\n        uses: shivammathur/setup-php@v2\n        with:\n          php-version: '8.2'\n          extensions: mbstring, pdo, sqlite, gd\n          coverage: xdebug\n\n      - name: Install dependencies\n        run: composer install --prefer-dist --no-progress\n\n      - name: Run PHP CS Fixer (Lint)\n        run: vendor/bin/php-cs-fixer fix --dry-run --diff\n\n      - name: Run PHPStan (Static Analysis)\n        run: vendor/bin/phpstan analyse src --level=5\n\n      - name: Run Tests\n        run: vendor/bin/phpunit --coverage-text

Que se passe-t-il ici ?

\n
• checkout – on récupère le code.
\n
• setup-php – on configure PHP.
\n