Vérifier immédiatement chaque pièce livrée plutôt que d’attendre la fin du chantier pour découvrir un défaut : voilà l’esprit de l’intégration continue, qui déclenche des vérifications automatiques dès qu’un changement arrive sur le dépôt.
Ce que ça change pour un projet WordPress
À chaque push sur un dépôt Git, un pipeline d’intégration continue (GitHub Actions, GitLab CI, ou un outil comparable) peut exécuter les tests automatisés d’un plugin, vérifier la conformité du code aux standards WordPress avec PHP_CodeSniffer, ou s’assurer qu’un bloc Gutenberg se compile sans erreur avant même que quiconque ne le relise manuellement.
Exemple
name: CI
on: [push, pull_request]
jobs:
tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: composer install
- run: vendor/bin/phpunitCe workflow s’exécute automatiquement à chaque envoi de code, sur une machine vierge, pour garantir que les tests réussissent dans un environnement neutre et reproductible.
Bon à savoir
- Un « build » qui échoue en intégration continue bloque généralement la fusion d’une pull request tant que le problème n’est pas corrigé, un garde-fou précieux avant la mise en production.
- L’intégration continue perd beaucoup de son intérêt sans une suite de tests automatisés suffisamment couvrante : elle ne détecte que ce que les tests vérifient réellement.
- Certaines équipes intègrent aussi une analyse de sécurité automatisée des dépendances (Composer, npm) dans leur pipeline d’intégration continue.