Pipelines CI/CD : guide pratique pour les équipes de développement

Livrer un logiciel plus souvent n’est utile que si l’équipe garde la maîtrise des changements. Elle doit pouvoir savoir ce qui a été testé, qui peut lancer une mise en production et comment réagir en cas d’incident. Un pipeline CI/CD rend ces étapes plus régulières et plus visibles, sans remplacer le jugement des personnes qui conçoivent et exploitent le produit.

Pour une organisation qui fait appel à un prestataire ou à une équipe renforcée, le pipeline sert aussi de cadre de collaboration : il précise le parcours d’une modification et les responsabilités associées.

Comprendre les étapes du CI/CD

L’intégration continue consiste à intégrer fréquemment les modifications dans une base de code commune et à les vérifier par des builds et des tests automatisés. La livraison continue vise à maintenir le logiciel dans un état où il peut être livré ; la mise en production peut rester soumise à une décision humaine. Le déploiement continu va plus loin : les modifications qui réussissent les contrôles requis sont déployées automatiquement en production.

Il est donc possible d’automatiser la majeure partie du parcours tout en conservant une validation avant la production. Selon les recommandations de DORA sur la livraison continue, accélérer les déploiements sans améliorer les processus et l’architecture peut accroître les risques.

Concevoir un parcours de modification fiable

Chaque produit a ses contraintes. Pour démarrer, une équipe peut organiser le pipeline autour de quatre étapes :

1. Vérifier la modification : déclencher des contrôles lors d’une proposition de changement, avec analyse statique, vérifications de format et tests rapides. Les échecs doivent être visibles et pris en charge.
2. Produire un artefact identifié : créer un paquet ou une image de conteneur versionné, puis utiliser ce même artefact dans les environnements suivants afin de savoir précisément ce qui a été testé.
3. Préparer la livraison : exécuter les tests d’intégration et les autres contrôles adaptés aux risques. Mieux vaut des tests fiables et utiles qu’une longue liste de vérifications ignorées.
4. Déployer et observer : passer par un environnement de test ou de préproduction adapté, puis par la production selon les règles de validation convenues. Surveiller le service et disposer d’une procédure de reprise documentée.

L’intégration continue ne se résume pas à un outil. Les conseils de DORA sur la CI insistent aussi sur des intégrations fréquentes, un retour rapide et la résolution prioritaire des builds cassés.

Adapter le déploiement au niveau de risque

Une application interne peut commencer par des déploiements automatisés en préproduction, suivis d’une validation humaine pour la production. Une équipe disposant de tests solides, d’une bonne surveillance et de procédures de reprise éprouvées peut envisager le déploiement automatique. L’important est de justifier chaque contrôle plutôt que de multiplier les validations sans objectif clair.

Pour un changement incertain, il peut être pertinent de limiter d’abord l’exposition à un groupe d’utilisateurs ou de dissocier l’activation d’une fonctionnalité de son déploiement. Avant de commencer, définissez les signaux à surveiller, la personne autorisée à interrompre le déploiement et les conditions de reprise. Un pipeline réussi ne garantit pas, à lui seul, le bon fonctionnement en production.

Ne pas oublier la base de données

Revenir à une version précédente de l’application ne rétablit pas nécessairement le schéma ou les données. Versionnez et testez les scripts de migration, puis définissez une stratégie de reprise avant la livraison. Lorsque c’est possible, prévoyez une période pendant laquelle l’ancien et le nouveau logiciel restent compatibles avec le schéma. Les recommandations de DORA sur les changements de base de données présentent cette approche et ses compromis.

Protéger le pipeline lui-même

Un pipeline peut accéder au code, aux identifiants et aux environnements de déploiement. Limitez donc les droits de chaque tâche, séparez les contrôles exécutant du code non fiable des tâches autorisées à déployer, et évitez d’exposer les secrets dans le code ou les journaux. Utilisez des identifiants à durée limitée lorsque les outils le permettent et maîtrisez les droits de modification et d’approbation des workflows de production.

Les composants tiers du pipeline doivent également être examinés et versionnés. La documentation de sécurité de GitHub Actions présente notamment le principe du moindre privilège et les moyens de fixer les dépendances d’un workflow. Pour les livraisons qui demandent davantage de garanties, on peut conserver la provenance des artefacts et la vérifier par rapport aux sources et systèmes de build attendus. La documentation SLSA sur la vérification des artefacts rappelle que produire une provenance ne suffit pas : elle doit aussi être examinée.

Suivre les résultats, pas seulement la vitesse

Commencez par mesurer une application, puis examinez les tendances avec l’équipe. Parmi les indicateurs utiles figurent la fréquence des déploiements, le délai entre un commit et la production, la part des changements provoquant une défaillance, le temps de reprise après un déploiement défaillant et la part des déploiements consacrée à des corrections non planifiées. DORA retrace l’évolution de ces indicateurs.

Ajoutez des mesures propres au pipeline, comme la durée des builds, les contrôles échoués et les délais d’attente des validations. Ces chiffres s’interprètent ensemble : un pipeline plus rapide n’est pas nécessairement meilleur s’il s’accompagne de davantage d’incidents ou de tests peu fiables. Définissez les mesures avant de comparer des périodes ou des équipes, et évitez d’en faire des objectifs individuels.

Clarifier le rôle d’un partenaire de réalisation

Que le travail soit mené en interne, avec du renfort d’équipe ou avec un partenaire de développement, les points suivants méritent d’être convenus dès le départ :

• Responsabilités : qui maintient la configuration, traite les échecs, autorise les mises en production et intervient en cas d’incident ?
• Propriété et accès : à qui appartiennent les dépôts, comptes cloud, artefacts, identifiants et documents ? Comment les accès seront-ils retirés à la fin de la mission ?
• Contraintes de livraison : quels environnements, règles de traitement des données, validations et outils existants faut-il prendre en compte ?
• Coûts et continuité : comment suivre l’utilisation des ressources de build, le stockage, la maintenance et le support ? Quel transfert de connaissances est prévu ?
• Preuves de préparation : l’équipe peut-elle démontrer une mise en production et une reprise testées, ainsi que les mesures convenues ?

Ces questions aident également les partenaires stratégiques et les investisseurs à apprécier la pérennité d’un processus de livraison, au-delà d’une démonstration ponctuelle. Les services d’Altweeb en développement logiciel, conseil technologique et renfort d’équipe constituent des cadres pertinents pour discuter de ces choix ; le périmètre et les responsabilités restent à définir pour chaque mission.

Avancer par étapes

Choisissez un service, cartographiez son processus de livraison, automatisez les contrôles les plus utiles et exercez-vous à déployer puis à rétablir le service. Examinez ensuite les résultats avec les personnes qui développent, valident et exploitent le logiciel. Un pipeline durable se construit grâce à ces retours, et non par l’automatisation seule.

Pour approfondir ce sujet, découvrez aussi Développement logiciel et de produits numériques.