TeamCity

Comprendre le déploiement continu

Le déploiement continu (CD) étend le processus d'intégration continue et de livraison continue (CI/CD) en déployant automatiquement chaque modification de code validée en production.

Sommaire :

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

Le déploiement continu pousse la pratique DevOps consistant à automatiser les étapes de build, de test et de déploiement à son extrême logique. Lorsqu'une modification de code passe avec succès chaque étape du pipeline, elle est automatiquement déployée en production sans aucune intervention manuelle. L'adoption du déploiement continu signifie que vous pouvez offrir de nouvelles fonctionnalités à vos utilisateurs aussi rapidement que possible, sans compromis sur la qualité.

Le déploiement continu est soutenu par un processus d'intégration continue et de livraison continue mature et correctement testé :

  • Les membres de l'équipe valident régulièrement des modifications de code par petits lots dans des commits.
  • Chaque commit déclenche un processus de test et de build automatisé.
  • Le build est ensuite promu à travers divers environnements de préproduction pour d'autres tests automatisés.
  • Si aucun problème n'est découvert, la nouvelle version du logiciel est livrée aux utilisateurs.

Une fois que vous avez mis en place un processus de CI/CD robuste et fiable, vous pouvez automatiser l'étape finale et commencer à déployer des modifications automatiquement aux utilisateurs. Avec le déploiement continu, la publication devient un non-événement qui se produit plusieurs fois par jour.

Cela dit, le déploiement continu ne doit pas être considéré comme l'objectif final de toutes les équipes DevOps. Si vous créez des applications, des API ou des logiciels à installer, vos utilisateurs peuvent ne pas vouloir recevoir des mises à jour plusieurs fois par jour. La livraison continue peut être plus adaptée dans ce cas.

Même si vous ne voulez pas d'un pipeline de déploiement entièrement automatisé, vous voudrez peut-être sélectionner certaines pratiques pour les appliquer à vos propres processus de CI/CD. Explorons exactement ce que le déploiement continu implique et ce qu'il faut prendre en compte avant de faire le saut vers le tout continu.

Déploiement continu et livraison continue

Il est facile de confondre les deux, mais le déploiement continu et la livraison continue constituent deux parties distinctes du côté CD du pipeline CI/CD. Avec la livraison continue, la publication finale en production doit être déclenchée manuellement, tandis qu'avec le déploiement continu, les publications sont automatiques tant que toutes les étapes précédentes ont été validées.

Comparaison entre déploiement continu et livraison continue

Déploiement continu Livraison continue
Modèle de publication Déclenché automatiquement chaque fois qu'une modification du code passe avec succès chaque étape du pipeline. Initiée manuellement pour les modifications qui ont réussi à passer chaque étape du pipeline.
Fréquence de publication Jusqu'à plusieurs fois par heure (selon la taille de l'équipe et la vitesse du pipeline). Généralement hebdomadaires ou mensuelles, mais elles peuvent être aussi fréquentes ou peu fréquentes que vous le souhaitez.
Bien adapté aux Sites web et applications web. Applications mobiles, logiciels pour ordinateurs et API. Elles peuvent également être utilisées comme un tremplin vers le déploiement continu.
Processus de test Doit être entièrement automatisé et très robuste. Les murs qualité aident à donner confiance aux développeurs et aux parties prenantes que les tests identifieront tous les bogues. Des tests automatisés doivent être utilisés autant que possible. Un processus de publication moins fréquent vous laisse des possibilités d'acceptation manuelle et de tests exploratoires.
Autres points à prendre en compte Les déploiements canari et les builds bleus/verts peuvent minimiser l'impact d'un bug publié en production. La surveillance est essentielle pour identifier les problèmes en production le plus tôt possible. Même si les publications sont déclenchées manuellement, le processus lui-même doit être automatique. Des options permettant d'annuler un déploiement ou de déployer rapidement des correctifs doivent encore être prises en compte.

En savoir plus sur les différences avec notre guide Intégration vs. livraison vs. déploiement continus.

Faire du déploiement continu une réalité

Si vos processus d'intégration et de déploiement sont entièrement manuels (avec des gels de code, une stratégie de mobilisation générale pour les tests et un suspens insoutenable le jour de la publication), alors des déploiements toutes les quelques heures peuvent vous paraître un lointain fantasme.

Dans la réalité, toutefois, de nombreuses organisations se tournent vers cette approche plus régulière. Des grands noms comme Netflix, Etsy et Amazon aux entreprises plus petites et moins connues, nombreuses sont les sociétés qui adoptent un système de déploiement continu pour essayer de suivre le rythme du marché. Cette méthode a permis à de nombreux éditeurs de logiciels de faire passer leurs délais de publication de plusieurs semaines ou mois à quelques heures.

Face à la pression croissante de fournir des fonctionnalités et de réagir rapidement aux retours des utilisateurs, le déploiement continu offre une stratégie de publications régulières sans compromis sur la qualité.

Mise en œuvre d'un système de déploiement continu

Dans le prolongement de l'intégration et de la livraison continues, le déploiement continu dépend d'un processus de build, de test et de déploiement entièrement automatisé. Cette approche garantit que la vitesse ne nuit pas à la qualité. Une mise en œuvre efficace du déploiement continu nécessite toutefois plus que de simples bases solides.

Murs qualité

Avant de pouvoir publier des modifications sans aucune intervention manuelle, il vous faut instaurer une confiance totale en votre processus de CI/CD. En particulier, vous devez vous assurer que les vérifications de code effectuées par vos builds automatisés et vos tests automatisés sont efficaces. C'est à cette étape que les murs qualité du code entrent en jeu.

Les murs qualité spécifient les critères du code pour passer à l'étape suivante de votre pipeline. Pour certaines étapes, vous pouvez définir un seuil simple, par exemple en exigeant un taux de réussite de 100 % avec une couverture de code à 90 % pour les tests unitaires. Pour d'autres tests automatisés, vous pourriez autoriser un certain pourcentage d'avertissements, mais faire échouer l'étape si des erreurs sont produites. Vous voudrez peut-être parfois signaler des erreurs ou des avertissements pour une révision manuelle avant de déclencher l'échec de l'étape.

L'utilisation de murs qualité automatisés aux étapes clés de votre pipeline vous offre le contrôle et la visibilité du processus ainsi qu'une piste d'audit complète de la diligence raisonnable effectuée pour chaque version.

Considérez la stratégie de publication

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. Mettre les serveurs hors ligne pour chaque déploiement entraîne des interruptions fréquentes des services en ligne, donc une stratégie de mise à jour progressive est souvent préférée. Vous pouvez également étendre votre processus de test automatisé pour y intégrer le déploiement à l'aide de déploiements canari.

Déploiements canari

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 le comportement des utilisateurs et les statistiques 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.

Score de confiance canari

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 automatisé ne se poursuit que si le score dépasse le seuil spécifié. Si le score est trop faible, l'analyse des métriques fournit un point de départ pour approfondir l'enquête sur les problèmes potentiels.

Déploiement de build bleu/vert

Un processus de déploiement de build bleu/vert est une technique courante pour les organisations qui implémentent un système de déploiement continu. Les déploiements bleus/verts facilitent le retour à une version antérieure en cas de problème, car l'ancien code reste en ligne jusqu'à ce que vous ayez l'assurance que les modifications fonctionnent comme prévu. Si nécessaire, vous pouvez poursuivre un déploiement initial Canary avec un déploiement bleu/vert.

Surveillance des métriques de production

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 souhaitez répondre rapidement aux bugs qui ont échappé aux tests automatisés.

Commencez par identifier les métriques essentielles reflétant la santé de votre système. Cela peut inclure des métriques de santé du système, telles que l'espace disque et l'utilisation du processeur, ainsi que des statistiques d'utilisation, telles que le nombre de requêtes ou de transactions. La comparaison de ces mesures avec une base de référence saine peut fournir un signe d'alerte précoce si tout ne fonctionne pas comme prévu. Vous pouvez ensuite décider d'annuler le déploiement de la modification ou de lancer un correctif dans le pipeline.

Considérations relatives au déploiement continu

Avant de vous embarquer pour le déploiement continu, prenez un moment pour considérer certains des impératifs qui permettront de réussir votre adoption du CD.

Impliquez les parties prenantes

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 jeté les bases avec vos parties prenantes et n'avez pas communiqué avec elles pour comprendre ce qu'elles attendent du processus de publication, le passage à des publications automatisées peut leur donner l'impression que le développement est devenu hors de contrôle. Cela peut amener les parties prenantes à exiger des points de contrôle manuels et des étapes d'examen, ce qui ralentirait le processus et saperait les avantages de la CI/CD. Dans le pire des cas, l'ensemble du système de déploiement continu pourrait être relégué au rang des expériences ratées.

Encouragez la collaboration

La promotion d'une culture de collaboration est essentielle pour le bon fonctionnement du déploiement continu. 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.

Gardez tout le monde informé

Il est aussi important d'indiquer ce qui sera publié et à quel moment que de solliciter des retours. Gardez les parties prenantes informées automatiquement à l'aide d'un serveur de CI. Selon l'outil de déploiement de build continu que vous aurez choisi, vous devez pouvoir diffuser des informations à l'aide de tableaux de bord et de notifications.

Utilisez des indicateurs de fonctionnalité ou une branche dédiée

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 indicateurs de fonctionnalité offrent une possibilité de contrôler la visibilité du code en production. L'avantage est que le code est en direct, ce qui vous permet de surveiller votre logiciel pour détecter des défaillances inattendues.

Une autre approche consiste à utiliser une branche dédiée et un pipeline séparé qui n'envoie pas automatiquement les modifications en production, combinant ainsi la livraison continue et le déploiement continu pour répondre à vos besoins.

Meilleures pratiques de déploiement continu

Une fois mis au point, le déploiement continu peut aider les équipes à livrer des modifications aux utilisateurs plus fréquemment tout en minimisant les bugs. Pour cela, l'essentiel est de suivre les meilleures pratiques, notamment en utilisant des métriques pour optimiser votre pipeline et surveiller votre environnement de production afin de détecter le moindre signe de problème. Il est également important de prendre conscience du changement culturel nécessaire et de convaincre toute l'équipe de l'intérêt du processus de CI/CD.

Pour en savoir plus sur les moyens de simplifier votre processus de CI/CD et d'obtenir de meilleurs résultats, consultez notre guide des Meilleures pratiques du déploiement continu.

En résumé

  • Le déploiement continu est une pratique DevOps qui automatise chaque étape du processus de build, de test et de publication.
  • L'objectif du déploiement continu est de fournir des fonctionnalités aux utilisateurs plus rapidement et plus régulièrement, sans compromettre la qualité.
  • Le déploiement continu est particulièrement adapté aux sites web et aux applications web, car les utilisateurs n'ont pas besoin d'appliquer les mises à jour eux-mêmes.
  • Des mises à jour plus rapides et plus fréquentes permettent des retours rapides des utilisateurs et réduisent l'impact de tous les bugs qui parviennent à s'immiscer en production.
  • 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.

Comment TeamCity peut vous aider

TeamCity facilite le processus de configuration du déploiement continu grâce à des options de déclenchement hautement configurables et des outils d'exécution de build pour le déploiement. Les configurations de build de déploiement dédiées vous permettent de limiter les autorisations de déploiement en production, tandis que les déclencheurs de build vous permettent de définir avec souplesse les conditions de publication. Utilisez la prise en charge des dépôts de paquets et des registres de conteneurs intégrée à TeamCity pour gérer vos artefacts de build dans le cadre de votre processus de déploiement continu.

Tenez vos parties prenantes informées de l'avancement en leur donnant accès aux tableaux de bord intuitifs de TeamCity sur le web. Un puissant contrôle d'accès basé sur les rôles vous garantit de pouvoir sécuriser le chemin vers la production, tandis que les pistes d'audit intégrées fournissent des archives complètes de toutes les activités de vos pipelines.

Interface utilisateur de TeamCity