Beaucoup d’entreprises se sont empressées de mettre en œuvre des pipelines d'intégration continue et de livraison continue (CI/CD) pour rationaliser leurs flux de développement de logiciels. Mais moins nombreuses sont celles qui ont franchi l'étape de l'automatisation du déploiement continu, une pratique qui consiste à utiliser les pipelines CI/CD pour pousser les changements en production de manière continue. Et c’est tout à fait compréhensible. L'idée de mettre du code en production tous les jours ou toutes les heures peut donner des sueurs froides. Il y a plusieurs années, j'avais écrit un article sur les inconvénients du déploiement continu. Un autre article, intitulé « Á quel moment les équipes devops responsables devraient accroître la fréquence de leurs déploiements » (« When should responsible devops teams increase deployment frequency »), remet en question l'hypothèse selon laquelle des déploiements plus fréquents sont préférables.

Cependant, beaucoup de choses ont changé ces dernières années et de plus en plus d'équipes devops ont les compétences, les pratiques et les outils nécessaires pour automatiser des déploiements fiables et de haute qualité. Cet article explique les différences entre la livraison continue et le déploiement continu, et propose cinq étapes aux équipes devops pour se préparer à automatiser le déploiement continu dans leurs pipelines CI/CD.

Mieux cerner livraison et déploiement continu 

La définition de Kulbir Raina, leader des practices agile et devops chez Capgemini, permet de bien différencier la livraison continue du déploiement continu. Selon lui, « la livraison continue est le flux automatisé de bout en bout des versions logicielles jusqu'à la production, tandis que le déploiement continu est le processus automatisé qui pousse le progiciel de ce flux vers la production après l'intégration continue via un processus pré-testé. » L'automatisation des déploiements en production comporte plus de risques, car les résultats ont un impact sur l'entreprise, les clients et les utilisateurs finaux. Si une équipe devops décide d'automatiser les déploiements, le processus de déploiement doit inclure des tests continus et une gestion robuste des erreurs. Dans le cas contraire, un déploiement pourrait créer des problèmes de performance, des systèmes peu fiables, des trous de sécurité et des failles qui se retrouvent en production. Mike Saccotelli, directeur de l'ingénierie logicielle chez SPR, ajoute : « La différence entre une entreprise qui exploite un modèle de livraison continue et un modèle de déploiement continu se juge dans le niveau de maturité et de sophistication de ses processus de construction et de déploiement. » 

Les équipes devops peuvent s’appuyer sur la liste de contrôle suivante pour préparer la mise à niveau des pipelines CI/CD pour le déploiement continu. 

1. Évaluer les avantages pour l'entreprise 

En tant que principe, le déploiement continu peut convenir à de nombreuses applications, même dans les secteurs les plus réglementés. Selon Tim Lucas, cofondateur et co-CEO de Buildkite, « le déploiement continu peut être adopté par projet, et les meilleures entreprises se fixent pour objectif de faire passer le plus grand nombre possible de projets à ce modèle. Y compris dans la finance et les industries réglementées, la majorité des projets peuvent adopter ce modèle. On voit même des entreprises de véhicules autonomes pratiquer le déploiement continu. » Si les équipes devops peuvent mettre en œuvre le déploiement continu dans de multiples projets, la question est de savoir dans quels cas ce déploiement offre une base de rentabilité solide et des avantages techniques significatifs. Les projets déployant fréquemment des fonctionnalités et des correctifs, où une architecture modernisée simplifie les automatismes, sont les plus prometteurs pour passer au déploiement continu. 

2. Préparer l'équipe de développement 

M. Lucas évoque aussi certaines conditions préalables au processus de développement logiciel avant de passer à un modèle de déploiement continu. Selon lui, « le déploiement continu apporte la véritable agilité, c’est le moyen le plus rapide de passer de la modification du code à la production. Il exige toujours de maintenir la branche principale dans un état « livrable », d'automatiser les tests et d'utiliser des outils de haute qualité dans lesquels on peut avoir confiance. » Parmi les responsabilités et les disciplines de développement auxquels devraient adhérer les développeurs qui cherchent à automatiser le déploiement continu, on peut citer : Des tests continus avec une couverture de code suffisante pour s'assurer que les changements n’introduisent pas de nouveaux défauts ; des outils d'analyse de code statique et dynamique pour tester la sécurité, les performances et d'autres problèmes de qualité du code ; un engagement envers les pratiques d’évaluations de la sécurité au début du cycle de vie du développement logiciel (shift-left), notamment les meilleures pratiques en matière de sécurité des API ; des normes d'observabilité autour des applications et des microservices ; le marquage des fonctionnalités, de sorte que les nouvelles fonctionnalités puissent être activées ou désactivées, ou contrôlées pour un sous-ensemble d'utilisateurs. M. Saccotelli ajoute que « le déploiement continu suppose que l'équipe de développement a une meilleure compréhension du code de qualité pour que ce processus puisse réussir. Si le code est médiocre ou non testé, le système sera peu fiable et introduira rapidement des bogues et des vulnérabilités dans la production. »

3. Préparer l'équipe d'exploitation

Donc, le pipeline CI/CD fonctionne et déploie le nouveau code en production. Mais ce n’est pas pour autant que les équipes devops sont tranquilles, que leur travail est terminé et que tout le monde peut passer à la version suivante. Malgré tout le travail accompli par les développeurs pour s'assurer de la solidité des builds, pour automatiser les tests de code et contrôler quel code est activé en production, le risque qu'un déploiement puisse causer des problèmes de production n’est jamais nul. La surveillance des services, des applications et des systèmes de l'entreprise relève de la responsabilité des opérations dans le cadre du Devops, et leurs compétences pour prendre en charge les déploiements continus commencent bien avant l'activation de l'automatisation des déploiements.  

Les meilleures pratiques sont les suivantes : Utiliser l'infrastructure en tant que code et les conteneurs pour garantir des configurations d'infrastructure cohérentes entre les environnements de développement, de test, de production et autres ; utiliser des outils de surveillance au niveau des applications et des systèmes qui chargent et analysent également les données d'observabilité créées par les applications et les microservices ; choisir une plateforme AIOps qui intègre la surveillance, les alertes et les données d'observabilité sur l'ensemble de la pile, des applications aux microservices et aux datastores, et qui corrèle les événements en incidents gérables ; mettre en place des versions canari pour contrôler le Cutover et le trafic vers les nouveaux déploiements et réduire les risques de stratégies de Cutover plus difficiles ; disposer d'un ensemble robuste d'outils de sécurité, notamment des passerelles API, des pare-feu d'applications Web, la sécurité des conteneurs, la surveillance des menaces et des données sensibles, qui atténuent les risques dans les environnements applicatifs hautement dynamiques. 

4. Intégrer l'ITSM et les workflows entre les équipes et les outils

Et ce n’est pas fini, même avec toutes les compétences de développement et d'exploitation instituées. Supposons que l'équipe Devops commette du code, que le déploiement continu fasse passer le changement en production et que les outils de contrôle des performances des applications soient en cours d'exécution. En combien de temps les membres de l'équipe devops concernés seront-ils alertés afin qu'ils puissent trier les incidents, rechercher la cause profonde et résoudre rapidement les problèmes ? Tim Lucas partage l'avis selon lequel « les tests défectueux constituent le risque n°1 » lors du passage au déploiement continu. Il cite comme autres risques les outils CI/CD peu fiables, les mauvaises pratiques de surveillance de la production et d'astreinte, ainsi que l'absence d'un véritable partenariat entre l'ingénierie et l'informatique. En l'absence de flux de travail et d'intégration entre les outils de surveillance, d'AIOps, de gestion des services IT (IT Service Management, ITSM), les outils agiles et de communication, le temps de réponse et de résolution des problèmes d'une équipe devops peut être inférieur à la vitesse de déploiement. Cet écart peut créer des périodes de stress et porter atteinte au partenariat entre les équipes de développement et les équipes opérationnelles. Une bonne pratique consiste à s'assurer que les outils IT et le flux de travail sont intégrés, afin que les équipes devops puissent suivre les problèmes créés par les déploiements continus. 

5. Définir des points de décision et des KPI basés sur les risques

Kristin Baskett, directrice du marketing produit chez Copado, mentionne un élément critique nécessaire aux déploiements continus. Selon elle, « si une automatisation imprudente peut entraver un système, une automatisation adaptée aide les entreprises à atteindre la flexibilité et la cohérence dont elles ont besoin pour tirer véritablement parti du Devops. Quand les développeurs peuvent intégrer le code automatiquement, la collaboration s'améliore. Et en investissant dans l'automatisation des tests et les portails de qualité, les entreprises peuvent innover plus rapidement, avec moins de risques. » En plus de l'automatisation des tests, Mme Baskett ajoute la mise en place de « barrières qualité » qui devraient être étendues à d'autres évaluations des risques. Quand une build déclenche un déploiement continu, les barrières de qualité mettent en œuvre des règles métiers pour déterminer quels déploiements peuvent aller en production et lesquels peuvent nécessiter un examen de conformité ou l'approbation de la direction ». Parmi les autres bonnes pratiques de gestion pouvant soutenir les déploiements continus on peut citer le développement d'indicateurs clés de performance (KPI), la formalisation des boucles de rétroaction et le développement de stratégies de communication. Les déploiements continus peuvent apporter de nombreux avantages métiers et technologiques, mais les équipes devops et les entreprises IT disciplinées doivent s'assurer que les meilleures pratiques et outils sont en place avant de se lancer dans l'automatisation pour augmenter les fréquences de déploiement.