Construisez un premier pipeline CI/CD avec des étapes lisibles, une version identifiable et des preuves de validation avant le déploiement de l’application.
Le développeur sait installer l’application depuis son ordinateur, mais un collègue ne retrouve pas les mêmes résultats. Une version locale de l’outil, un fichier absent du dépôt ou une commande non documentée peut expliquer l’écart. Le premier pipeline sert à rendre ce parcours explicite et reproductible par l’équipe.
Commencez par une application et un environnement de recette. L’objectif initial est de savoir quel code a été vérifié, ce qui a été produit et où il a été installé. Vous pourrez étendre l’automatisation une fois ces informations disponibles à chaque livraison.
Reconstituer la livraison manuelle
Demandez à la personne qui déploie de décrire une installation complète depuis une copie propre du dépôt. Relevez les versions des outils, les fichiers attendus et les accès nécessaires. Une étape qui dépend d’un élément situé uniquement sur son poste doit être rendue accessible par le mécanisme prévu pour l’équipe.
Classez ensuite les commandes selon leur rôle : préparer les dépendances, vérifier le code, construire l’application et installer le résultat. Certaines commandes mélangent plusieurs opérations ; faites apparaître leurs effets avant de les intégrer au pipeline.
GitHub Actions décrit les workflows comme des ensembles de travaux et d’étapes, déclenchés par des événements ou manuellement. Les travaux peuvent dépendre les uns des autres. Quelle que soit votre plateforme, utilisez ces dépendances pour empêcher une installation lorsque la validation requise n’a pas réussi.
Définir ce qui bloque une livraison
Listez les erreurs que l’équipe doit détecter avant d’installer une version. Une compilation impossible bloque évidemment la suite. Pour les tests, commencez par les parcours dont l’échec aurait une conséquence métier identifiable : calcul d’un montant, droit d’accès ou création d’un objet essentiel.
Évitez de considérer tout avertissement historique comme une nouvelle urgence. Attribuez un traitement au problème et rendez la règle compréhensible. Le pipeline doit signaler un échec avec un message qui permet à la personne responsable de trouver le contrôle concerné.
Si un test échoue de manière intermittente, conservez la trace des occurrences et ouvrez une investigation. Relancer jusqu’à obtenir un résultat favorable sans comprendre l’instabilité affaiblit la validation. Documentez toute dérogation avec son périmètre et sa durée.
Identifier précisément le résultat construit
Associez le résultat au commit du dépôt et à l’exécution qui l’a produit. L’équipe doit pouvoir retrouver la version installée sans examiner le poste du développeur. Pour un paquet ou une image, conservez une référence stable et un emplacement où le résultat peut être récupéré par les étapes suivantes.
Définissez la durée de conservation selon les besoins de support et de reprise. Le dernier résultat réussi ne suffit pas toujours : une investigation peut concerner une version précédente encore utilisée par certains clients. Examinez les droits d’accès aux artefacts au même titre que les droits sur le dépôt.
Vérifiez aussi ce qui se passe lorsque deux demandes de livraison arrivent presque simultanément. Le processus doit empêcher qu’une version plus ancienne termine son installation après une version plus récente sans que l’équipe s’en aperçoive. Choisissez une règle de file d’attente, d’annulation ou de validation adaptée au service.
Installer d’abord en recette
Préparez un environnement dont les accès et les sorties externes sont contrôlés. Le guide de préproduction pour une PME détaille les données de test et les dépendances à isoler. Le pipeline doit sélectionner cet environnement explicitement.
Après l’installation, vérifiez un parcours limité mais utile. Une réponse HTTP confirme qu’un point d’accès répond ; elle ne vérifie pas forcément la connexion, les droits et la persistance d’une action. Définissez le contrôle qui correspond au service livré.
Conservez les étapes de recette métier qui nécessitent un jugement humain. Le pipeline peut rendre leurs résultats accessibles et attendre la décision prévue. L’automatisation ne dispense pas le responsable de vérifier une nouvelle règle métier ou une modification de présentation importante.
Préparer le passage en production
Définissez qui peut autoriser ce passage et sur quelle preuve. Le dossier de livraison peut rester bref : version candidate, résultats techniques, recette effectuée et éventuels points ouverts. Les validations doivent porter sur la version réellement proposée.
Examinez les différences de configuration entre recette et production. Une variable manquante, un droit insuffisant ou une migration oubliée peut faire échouer la livraison malgré des tests réussis. Prévoyez les contrôles correspondants avant d’ouvrir l’application aux utilisateurs.
Limitez les accès remis à l’étape d’installation. Notre article sur les secrets CI/CD décrit leur inventaire et leur renouvellement. Les étapes qui vérifient le code ne doivent pas recevoir automatiquement des accès dont seule la mise en production a besoin.
Éprouver le pipeline avec un échec contrôlé
Faites échouer volontairement un contrôle dans une branche de test et vérifiez que le déploiement n’a pas lieu. Examinez le message reçu par l’équipe et le lien vers le résultat. Rejouez ensuite une livraison réussie depuis une copie propre du code.
Testez également l’échec d’une installation en recette. La personne qui intervient doit retrouver ce qui a déjà été exécuté et le point où la procédure s’est arrêtée. Une commande relancée doit avoir un comportement connu ; certaines opérations demandent un traitement particulier après une exécution partielle.
Pour la première livraison de production, conservez le compte rendu et les améliorations identifiées. Affectez chaque correction à un responsable. Le prochain déploiement permettra de vérifier que ces ajustements réduisent réellement les interventions manuelles et les zones d’incertitude.