Qu'est-ce que le déploiement continu (CD) ?

Si vos processus d'intégration et de déploiement sont entièrement manuels, avec des blocages de code, une stratégie de test manuel et beaucoup d'inquiétude dans toute l'entreprise le jour de la publication, alors des déploiements toutes les heures et sans incident peuvent paraître inimaginables.

Mais la réalité est que toute une série d'organisations se tournent vers cette approche, des grands noms comme Netflix, Etsy et Amazon aux petites entreprises qui tentent de rester en phase avec le marché. L'adoption du système de déploiement continu leur a permis de réduire leur délai de publication de plusieurs semaines, voire de plusieurs mois, à quelques heures. Pour un nombre croissant de secteurs, il devient essentiel d'être en mesure de livrer rapidement des fonctionnalités et de répondre rapidement aux feedbacks.

Dans le prolongement de l'intégration et de la livraison continues, le déploiement continu dépend d'un processus de test et de déploiement de build entièrement automatisé pour garantir que la rapidité ne soit pas au détriment de la qualité. Mais l'implémentation effective d'un déploiement continu nécessite plus que cette base solide.

Lors de la planification de l'implémentation d'un système de déploiement continu, une question clé à prendre en compte est la manière dont vos modifications seront publiées. En plus de choisir une mise à jour à chaud plutôt que de mettre les serveurs hors ligne pour éviter de fréquentes interruptions des services en ligne, vous pouvez également faire du déploiement une extension de votre processus de test automatisé.

Le déploiement Canary limite le déploiement du code mis à jour à un petit pourcentage d'utilisateurs, qui deviennent sans le savoir des testeurs en production. En surveillant les comportements et les indicateurs d'utilisation, vous pouvez vérifier que la nouvelle version n'a pas introduit de nouvelles défaillances avant de la déployer plus largement.

Certaines entreprises ont poussé l'automatisation plus loin avec un indice de confiance Canary, qui compare automatiquement toute une série d'indicateurs à une base de référence. Le déploiement se poursuit automatiquement uniquement si le score dépasse le seuil spécifié, tandis que l'analyse des mesures fournit un point de départ pour une étude plus approfondie des problèmes potentiels.

Un processus de déploiement de build bleu/vert est une technique courante pour les organisations implémentant un système de déploiement continu, car il permet de revenir plus facilement sur une version en cas de problème en gardant l'ancien code en ligne jusqu'à ce que vous soyez certain que les modifications fonctionnent comme prévu. Si nécessaire, vous pouvez poursuivre un déploiement initial Canary avec un déploiement bleu/vert.

Que vous meniez un déploiement bleu/vert ou que vous procédiez à des remplacements directs, il est essentiel de surveiller la santé du système de production si vous voulez être en mesure de remédier rapidement à des bugs qui se seraient faufilés dans le processus de publication.

Garder un œil sur certaines mesures qui indiquent la santé de votre système, de l'espace disque et de l'utilisation du processeur au nombre de demandes ou de transactions, et les comparer à une base de référence peut permettre de détecter rapidement si les choses ne se comportent pas comme elles le devraient. Vous pouvez alors décider de retirer la modification ou d'aller de l'avant en apportant un correctif dans le pipeline.

Avant de sauter dans le train du déploiement continu, il est bon de prendre un moment pour examiner certains des problèmes qui surgissent généralement lors de son adoption.

Le cycle de vie du développement logiciel implique plus que de simples modifications du code. Les équipes de recherche relatives aux utilisateurs, de marketing produit, de conception des interactions, de documentation, de vente, de conseil juridique et d'assistance ont toutes un rôle à jouer.

Si vous n'avez pas préparé le terrain avec vos parties prenantes et si vous ne vous êtes pas engagé avec elles pour comprendre ce dont elles ont besoin au cours du processus de publication, le passage à un déploiement continu peut leur donner l'impression que le développement est hors de contrôle. Cela peut entraîner l'introduction de points de contrôle et d'étapes de révision manuels pour ralentir le processus, ou même le rejet de l'intégralité du système de déploiement continu.

Il est essentiel de créer une culture de collaboration. L'implication des autres équipes tout au long du processus de développement afin que leur contribution, que ce soit sur la conception, les questions de sécurité, la terminologie ou la conformité, puisse être intégrée dès le début, est un exemple de la manière dont de courtes boucles de feedback rendent le cycle de vie du développement logiciel plus efficace. Il est aussi important d'indiquer ce qui sera publié et à quel moment que de solliciter des retours. Garder les parties prenantes informées peut être automatisé à l'aide d'un serveur de CI, un outil de déploiement continu, pour diffuser les informations via des tableaux de bord et des notifications.

Parfois, la visibilité de ce qui se prépare n'est pas suffisante. Lorsque vous travaillez sur une fonctionnalité plus importante ou que vous devez contrôler la date de sortie d'une version, le simple fait de déployer chaque commit une fois qu'il a passé tous les tests n'est pas idéal.

Les feature flags sont une option pour contrôler la visibilité du code en production, avec l'avantage que le code est déployé, ce qui permet de détecter d'éventuelles défaillances inattendues. Une autre approche consiste à utiliser une branche dédiée déployée sur un pipeline distinct qui ne passe pas automatiquement en production, combinant ainsi à la fois la livraison continue et le déploiement continu pour répondre à vos besoins.

Lorsqu'il est géré correctement, le déploiement continu peut aider les équipes à automatiser le déploiement des logiciels pour les utilisateurs. L'application des bonnes pratiques de déploiement continu peut vous aider à optimiser le processus et obtenir de meilleurs résultats. Par exemple, il est important de surveiller et mesurer régulièrement votre pipeline pour identifier les signes de problèmes. Il est également important de sensibiliser l'ensemble de l'équipe pour créer un pipeline CI/CD efficace.

Il est facile de comprendre les deux, mais le déploiement et la livraison continue constituent deux parties distinctes du côté CD du pipeline CI/CD. While continuous delivery is focused on automating the steps required to deliver the software to users (for example, by automating builds, test automation, etc.), continuous deployment is a logical continuation of the process, automating the release of the software to end users provided that all necessary criteria are met.

Le déploiement continu utilise l'automatisation au maximum afin de fournir rapidement des fonctionnalités aux utilisateurs sans compromettre la qualité. Un retour d'information régulier et rapide est essentiel à cette pratique DevOps. Les tests automatisés, le contrôle en production, la collaboration avec d'autres fonctions et le comportement des utilisateurs sont autant d'éléments qui contribuent au processus de développement logiciel. En travaillant par petits morceaux et en publiant fréquemment, vous pouvez continuer à ajuster en fonction des retours d'information et améliorer continuellement ce que vous livrez.