Déploiement continu (continuous deployment, CD)

Déploiement continu contre livraison continue

L'intégration, la livraison et le déploiement continus font ensemble partie de ce que l'on appelle le développement logiciel continu, et sont souvent associés aux méthodologies Agile et DevOps. La livraison continue et le déploiement continu sont directement dérivés de l'intégration continue, une méthode qui consiste à développer, compiler et tester rapidement le nouveau code en ayant recours à l'automatisation de façon à ne fusionner dans le logiciel que le code jugé correct.

Le déploiement continu se distingue de la livraison continue, bien que la confusion règne entre ces deux concepts, d'autant plus que ces deux termes partagent le même acronyme en anglais (CD).

On parle de livraison continue lorsque les développeurs livrent souvent et de manière régulière du nouveau code à tester aux équipes de l'assurance qualité (QA) et de l'exploitation. Cette démarche suppose généralement un environnement de test semblable à l'environnement de production et implique souvent un laps de temps entre la publication et le moment où une version est testée, où les modifications sont manuellement acceptées et où le nouveau code est mis en production.

À l'inverse, le déploiement continu ne nécessite aucune évaluation ni vérification manuelles des changements de code dans l'environnement de test, puisque les tests automatisés sont intégrés très tôt dans le processus de développement et se poursuivent tout au long des phases du lancement. Le déploiement continu présente un avantage certain : l'absence d'attente entre la réussite des tests d'un changement de code aux niveaux de l'application et de la plateforme et sa mise en production.

Ces deux étapes de développement s'appuient sur des outils en temps réel pour la mise en place de l'infrastructure et le suivi des applications, afin de détecter les problèmes qui n'ont pas été signalés dans les boucles de rétroaction des tests avant le déploiement. Les tests et le suivi revêtent une importance capitale en cas de déploiement continu dans la mesure où il n'y a aucune intervention humaine pour vérifier les performances.

La conformité réglementaire ou d'autres restrictions peuvent empêcher un service informatique d'adopter le déploiement continu. D'autres considérations, comme la maturité des processus DevOps ou les meilleures pratiques du service informatique, doivent également être prises en compte pour décider s'il faut ou non déployer du code selon le principe de livraison continue, de déploiement continu ou d'une combinaison des deux, en fonction des applications et des utilisateurs.

Outils de déploiement continu

Les pipelines de déploiement continu utilisent des outils similaires à ceux de la livraison continue, en mettant toutefois l'accent sur le test du code avant et après le déploiement en production.

Au cours du développement, le contrôle des versions, l'automatisation des builds et des outils spécialisés, tels que le logiciel de gestion de projet Apache Maven, garantissent une livraison fluide du code grâce à des pipelines d'intégration continue, comme Jenkins.

Les tests unitaires et fonctionnels soumettent le code à autant de scénarios d'exécution que possible pour prévoir son comportement en production. NUnit, TestNG et RSpec figurent parmi les environnements de test unitaire les plus connus.

En cas de déploiement continu, des outils d'automatisation et de gestion de configuration, comme Puppet et Ansible, assurent le déploiement du code et la configuration des espaces d'hébergement. Les tests d'intégration et d'acceptation peuvent être définis dans des outils tels que Cucumber et Calabash.

Les outils de suivi, comme ceux d'AppDynamics et Splunk, tracent et signalent toute variation de performance de l'application ou de l'infrastructure due au nouveau code, et peuvent déclencher une solution de gestion des réponses aux incidents, telle que PagerDuty. Dans le cadre du déploiement continu, la surveillance et la réponse aux incidents doivent s'approcher au maximum du temps réel pour écourter les délais de récupération en cas de problèmes avec le code.

Le jeu d'outils de déploiement doit aussi prévoir le retour en arrière de façon à anéantir au plus vite tout effet inattendu ou indésirable résultant du nouveau code mis en production. Les organisations peuvent compter sur le déploiement et le partitionnement (sharding) Canary, le déploiement bleu/vert, les indicateurs ou bascules de fonctionnalité et autres outils de contrôle de déploiement pour éviter que le déploiement continu ne vienne perturber les utilisateurs.

Certaines applications peuvent se déployer en conteneurs, cas de Docker, afin d'isoler les mises à jour de l'infrastructure sous-jacente.