Déploiement Continu (Continuous Deployment)

Qu’est-ce que le déploiement continu ?

Faire preuve d’agilité implique la capacité de réagir rapidement et efficacement, notamment dans le domaine du développement logiciel.

Le déploiement continu et la livraison continue sont deux termes souvent associés, parfois utilisés de manière interchangeable, ce qui entraîne une certaine confusion. Ils concernent tous deux la manière dont les fonctionnalités sont déployées en production.

Il existe cependant une différence majeure entre les deux. Avec la livraison continue, quelqu’un doit approuver la mise en production de la fonctionnalité, tandis qu’avec le déploiement continu, ce processus se fait automatiquement une fois les tests automatisés réussis.

Le déploiement continu repose essentiellement sur un pipeline entièrement automatisé. Cette pratique élimine complètement les étapes manuelles et automatise l’ensemble du processus. Ainsi, le déploiement continu garantit que le code est constamment poussé en production.

Un suivi en temps réel reste toutefois nécessaire pour surveiller et résoudre les problèmes qui pourraient survenir pendant les tests automatisés, ainsi que pour s’assurer que les builds ont passé ces tests.

Processus CI/CD et déploiement continu

Le déploiement continu fait partie d’un processus continu. La première étape commence avec l’intégration continue, où les développeurs fusionnent fréquemment leurs modifications dans le trunk ou la ligne principale. Cela aide les équipes à éviter ce que l’on appelle le « merge hell », qui survient lorsque les développeurs tentent de fusionner plusieurs branches distinctes dans le trunk commun à une fréquence moins régulière.

Vient ensuite la livraison continue, lorsque le code est déployé dans un environnement de test ou de production. Ici, les modifications des développeurs sont téléchargées dans un référentiel, puis déployées dans un environnement de production. Avec la livraison continue, il est possible de choisir un rythme de publication quotidien, hebdomadaire ou mensuel, mais il est généralement recommandé de publier aussi souvent que possible par petits lots pour résoudre facilement et rapidement les problèmes qui surviennent.

Le déploiement continu va un pas plus loin en combinant l’intégration continue et la livraison continue pour rendre les logiciels automatiquement disponibles aux utilisateurs sans intervention humaine. Le déploiement continu nécessite donc l’automatisation complète de tous les déploiements et fait référence au processus de publication automatique des modifications des développeurs depuis le référentiel vers la production, sans besoin d’approbation des développeurs pour chaque publication. En conséquence, ce processus repose fortement sur des tests automatisés bien conçus.

Toutes ces pratiques se réunissent pour faciliter et accélérer les publications, rendant le déploiement moins risqué.

Avantages du déploiement continu

Dans ce contexte, le déploiement continu accélère les mises sur le marché et accélère également le processus de retour d’information entre les développeurs et les clients. Le travail des développeurs est mis en ligne presque immédiatement après qu’il est terminé. De cette manière, les développeurs peuvent répondre en temps réel aux retours d’information, corriger rapidement les bogues signalés ou tester une nouvelle idée en déployant et en validant rapidement de nouvelles fonctionnalités.

Le déploiement continu élimine également la pression liée au « jour de la publication », permettant aux développeurs de se concentrer exclusivement sur la création de logiciels, qui sont automatiquement mis en ligne en quelques minutes.

Cela augmente également la productivité et permet aux développeurs de répondre aux demandes du marché en constante évolution.

Cependant, le déploiement continu nécessite une surveillance et une maintenance accrues pour garantir son bon fonctionnement ainsi qu’une grande capacité à répondre rapidement aux changements.

Feature flags et déploiement continu

Les équipes pratiquant le déploiement continu doivent être extrêmement rigoureuses dans leurs pratiques de tests automatisés, car toutes les publications se font automatiquement sans approbation préalable. Par conséquent, tout bogue qui échappe à ces tests se retrouvera entre les mains de vos utilisateurs finaux.

Cette problématique peut être résolue grâce aux feature flags. Ceux-ci ajoutent une couche de sécurité au processus de déploiement continu. Un « kill switch » peut être placé sur chaque fonctionnalité, permettant de désactiver une fonctionnalité en cas de détection d’un bogue sans avoir à effectuer de retour arrière. De cette façon, les parties problématiques d’une fonctionnalité ne sont pas exposées aux utilisateurs, tandis que le reste des modifications peut être publié sans nécessiter de retour en arrière.

Résumé rapide

• Intégration continue (CI) : intégrer des modifications au trunk partagé plusieurs fois par jour.

• Livraison continue (CD) : intégrer en continu, puis déployer toutes les modifications de code dans l’environnement de production ; le déploiement est manuel.

• Déploiement continu (CD) : étape supplémentaire après la livraison continue ; déploiement automatisé en production sans besoin d’approbation des développeurs.

Le CI/CD peut désigner l’interconnexion des processus d’intégration continue et de livraison continue, ou même inclure les trois pratiques d’intégration continue, livraison continue et déploiement continu.

En fin de compte, ce qu’il faut retenir, c’est que le CI/CD, visualisé comme un pipeline, automatise le processus de livraison logicielle en construisant du code, en exécutant des tests et en déployant ce code dans un environnement de production en direct.