Un pipeline d’intégration continue (CI) doit répondre à une question précise : ce changement peut-il être intégré à la base de code partagée sans introduire de défauts connus ni compromettre le respect des exigences convenues ? Pour y répondre, il convient de définir des vérifications répétables, d’ordonner leur exécution et de faire en sorte que chaque échec apporte des informations utiles.
La CI ne signifie pas que chaque changement est automatiquement déployé. C’est la pratique qui consiste à intégrer fréquemment les changements et à les valider de façon automatisée. La livraison continue prépare de façon continue une version déployable ; le déploiement continu ajoute la mise en production automatique lorsque les conditions définies sont réunies. Une application peut utiliser la CI sans automatiser la livraison, ou l’automatiser jusqu’à un environnement de test tout en conservant une approbation avant la production.
Définir le contrat du pipeline
Avant de choisir des outils, précisez ce que reçoit l’exécution, ce qu’elle doit produire et quelles conditions la font échouer. Une configuration utile documente au minimum :
- Entrées : le changement à valider, la configuration pertinente et les dépendances déclarées par le projet.
- Environnement : le système et les exigences d’exécution, la configuration de PHP et les services nécessaires aux tests. Il doit être suffisamment similaire d’une exécution à l’autre pour que les résultats soient comparables.
- Résultat : l’état final, les rapports de tests et d’analyse et, le cas échéant, un artefact identifiable qui pourra être validé par la suite.
- Conditions d’échec : les erreurs qui bloquent l’intégration, celles qui génèrent des avertissements et les personnes habilitées à accepter une exception temporaire.
L’installation doit s’appuyer sur la configuration des dépendances versionnée et respecter le fichier de verrouillage, au lieu de résoudre silencieusement de nouvelles versions à chaque exécution. Cela réduit les écarts entre les environnements des développeurs et la CI. Il faut également déclarer les exigences de plateforme et les extensions attendues par l’application, puis vérifier que l’environnement d’exécution les satisfait.
Évitez que le pipeline dépende de fichiers locaux, de services personnels ou d’étapes manuelles non documentées. Si une vérification nécessite une base de données, un cache ou un autre service, définissez son mode de démarrage, les données requises et la façon de les nettoyer. Le contrat n’a pas à reproduire entièrement la production, mais doit expliciter les différences susceptibles d’influer sur le résultat.
Ordonner les vérifications selon leur coût et leur capacité de détection
Une séquence pratique commence par les validations rapides et se termine par celles qui nécessitent davantage de temps ou d’infrastructure. La priorité n’est pas d’accumuler les tâches, mais de détecter les problèmes le plus tôt possible sans perdre une couverture significative.
- Installation reproductible : résolvez les dépendances à partir de la définition et du fichier de verrouillage du projet. En cas d’échec, les autres résultats ne sont pas fiables.
- Format et conventions : vérifiez les règles de formatage ou de style convenues. Ces vérifications sont rapides et évitent que des différences de présentation n’arrivent jusqu’à une revue plus coûteuse.
- Analyse statique : recherchez les incompatibilités et les erreurs détectables sans exécuter tous les parcours de l’application. Adaptez les règles au code et à la configuration réels du projet.
- Tests : exécutez d’abord les tests unitaires et ajoutez des tests d’intégration ou de bout en bout selon les risques couverts et les services nécessaires.
- Validation de l’artefact : vérifiez que le package ou l’image généré contient ce qui est nécessaire à son exécution et exclut les fichiers de développement, les données locales et les secrets.
Toutes les applications n’ont pas besoin des mêmes tests ni du même ordre. Si une analyse statique prend beaucoup plus de temps qu’un petit test unitaire, il peut être judicieux d’exécuter les deux vérifications en parallèle après l’installation des dépendances. Les tâches indépendantes peuvent également être exécutées en parallèle pour réduire l’attente, à condition de s’appuyer sur une base reproductible et d’associer leurs résultats au même changement.
En revanche, il est déconseillé de paralléliser à l’aveugle des étapes qui modifient le même répertoire ou dépendent de résultats précédents. Séparez la préparation commune des tâches suivantes, limitez la concurrence pour les services partagés et explicitez les dépendances entre les étapes. L’objectif est d’accélérer le retour d’information sans rendre le pipeline imprévisible.
Décider ce qui bloque et ce qui s’exécute ensuite
Comme règle de départ, bloquez l’intégration lorsqu’une vérification pertinente pour la sécurité du changement échoue : installation, analyse convenue, tests requis ou validation du package. Une tâche informative — par exemple, une vérification encore en cours d’évaluation — peut communiquer ses résultats sans bloquer pendant une période définie. Elle doit avoir une personne responsable, une date de révision et un critère de passage au statut obligatoire ; sinon, les avertissements deviennent permanents et perdent leur valeur.
Les vérifications rapides devraient fournir un retour précoce pour chaque changement. Les tests coûteux peuvent être exécutés en parallèle, à une étape ultérieure ou à une fréquence différente si le temps ou l’infrastructure le justifient. Toutefois, réserver toute validation importante à l’après-intégration laisse une période durant laquelle les changements n’ont pas été vérifiés. Définissez ce qui est exigé avant l’intégration et ce qui relève d’une validation supplémentaire, en tenant compte de l’impact d’un échec tardif.
Une exécution réussie ne signifie pas qu’un déploiement est approuvé. La CI vérifie le changement et peut générer un artefact ; le processus de livraison décide comment le promouvoir, vers quel environnement et sous quels contrôles. Expliciter cette frontière évite qu’une tâche de validation ne publie accidentellement en production. Si un déploiement automatique est prévu, définissez séparément ses conditions, ses approbations, sa stratégie de déploiement progressif et son mécanisme de retour arrière.
Protéger la configuration et les secrets
Les secrets ne doivent être intégrés ni au dépôt, ni aux fichiers de configuration d’exemple, ni aux rapports d’exécution. Utilisez le mécanisme de gestion des secrets de l’environnement de CI, limitez leur disponibilité aux tâches qui en ont besoin et évitez d’accorder des identifiants de production à des validations qui ne nécessitent que des services isolés.
Examinez également les journaux : une exception, l’échec d’un test ou une commande de diagnostic peut afficher des variables sensibles. Le masquage des valeurs est utile, mais ne remplace pas la prévention de leur écriture. Utilisez des données de test qui n’exposent aucune information réelle et définissez une procédure de révocation des identifiants s’ils apparaissent dans un journal ou un artefact.
Permettre de diagnostiquer les échecs
Un état rouge sans contexte oblige à refaire le travail et transforme la CI en boîte noire. Conservez les rapports de tests et d’analyse, la sortie nécessaire pour identifier l’étape en échec et les identifiants des versions des dépendances ou de l’artefact. Évitez toutefois d’enregistrer des données personnelles, des secrets ou des dumps complets de l’environnement.
Lorsqu’un test échoue de façon intermittente, ne le déclarez pas réussi après des tentatives illimitées. Consignez les tests instables, leur fréquence et les conditions dans lesquelles ils fluctuent ; recherchez des causes comme la concurrence, les dépendances externes, l’état partagé ou les délais d’expiration. Si un test instable est temporairement isolé, documentez le risque, désignez une personne responsable et fixez une date pour le rendre à nouveau bloquant.
Il convient également de distinguer un échec du code d’un problème d’infrastructure. Indiquez si des services n’ont pas pu démarrer, si des dépendances n’ont pas pu être obtenues ou si une tâche n’a pas pu être terminée faute de ressources. Une nouvelle tentative peut être raisonnable en cas d’interruption passagère, mais elle doit être limitée et visible ; masquer le premier échec complique la détection des problèmes récurrents.
Adapter la CI à une application legacy
Dans une application legacy, activer d’emblée des règles strictes peut bloquer des changements utiles et encourager des exceptions incontrôlées. Commencez par établir un état de référence : identifiez les tests qui réussissent aujourd’hui, les erreurs préexistantes signalées par l’analyse et la durée de chaque étape. Ne présentez pas comme une régression un problème déjà présent, mais ne laissez pas non plus l’état de référence devenir une excuse indéfinie.
- Rendez d’abord obligatoires les vérifications reproductibles qui sont déjà stables, comme l’installation et un ensemble fiable de tests.
- Consignez les problèmes existants et exigez que les nouveaux changements n’aggravent pas la situation, si l’outil et le projet permettent cette comparaison.
- Ajoutez des tests autour des zones présentant le plus grand risque de changement et élargissez progressivement leur couverture.
- Réduisez les exceptions dans le cadre de changements de petite taille et faciles à examiner ; désignez une personne responsable et fixez une date pour chaque exception temporaire.
- Mesurez la durée et les causes des échecs afin d’optimiser des étapes précises, au lieu de supprimer des validations sans savoir quels risques elles couvraient.
Une bonne intégration continue en PHP ne se définit pas par le nombre d’étapes, mais par des résultats reproductibles et compréhensibles. Si l’équipe peut expliquer ce que valide chaque étape, ce qui bloque l’intégration et comment enquêter sur un échec, le pipeline aide à décider, sur la base de faits, quand un changement est prêt à avancer.
