Technologies DevOps : livraison continue

La livraison continue est la capacité à apporter des modifications de tous types à la demande de manière rapide, sécurisée et durable. Les équipes qui appliquent la livraison continue sont en mesure de délivrer des logiciels et d'apporter des modifications à la production de manière peu risquée, y compris pendant les heures ouvrables, sans aucune incidence sur les utilisateurs.

Vous pouvez appliquer les principes et les pratiques de la livraison continue à n'importe quel contexte logiciel, y compris lors des opérations suivantes :

  • Mettre à jour des services dans un système distribué complexe
  • Mettre à niveau un logiciel mainframe
  • Effectuer des modifications de configuration d'une infrastructure
  • Effectuer des modifications de schéma d'une base de données
  • Mettre à jour automatiquement le micrologiciel
  • Diffuser de nouvelles versions d'une application mobile

Si votre équipe utilise la livraison continue, vous pouvez répondre "oui" aux questions suivantes :

  • Notre logiciel peut-il être déployé tout au long de son cycle de vie ?
  • Préférons-nous garantir le déploiement du logiciel plutôt que d'élaborer de nouvelles fonctionnalités ?
  • Les retours rapides sur la qualité et le déploiement du système sur lequel nous travaillons sont-ils accessibles à tous les membres de l'équipe ?
  • Lorsque nous recevons des commentaires indiquant que le système ne peut pas être déployé (par exemple, en raison d'une défaillance au niveau du build ou des tests), considérons-nous la correction de ces problèmes comme notre priorité ?
  • Pouvons-nous déployer notre système vers l'environnement de production ou les utilisateurs finaux, à tout moment, à la demande ?

La livraison continue et le déploiement continu sont souvent confondus, mais il s'agit de pratiques distinctes. Dans le cas du déploiement continu, les équipes essaient de déployer le plus rapidement chaque modification de code en production. Le déploiement continu est parfaitement adapté pour les services Web, mais ne peut pas être appliqué à des logiciels tels que les micrologiciels ou les applications mobiles. La livraison continue s'applique à tous les types de logiciels, y compris les micrologiciels et les systèmes mainframe. Elle fonctionne également dans les environnements hautement réglementés. Vous pouvez (et devez) commencer par la livraison continue, même si vous n'avez pas l'intention d'utiliser le déploiement continu.

La livraison continue et le déploiement continu sont considérés à tort comme étant à risque et non adaptés aux domaines réglementés ou essentiels à la sécurité. En réalité, l'objectif de la livraison continue consiste à réduire les risques logiciels. Les recherches de DORA ont démontré que les équipes performantes obtiennent généralement des niveaux de fiabilité et de disponibilité plus élevés. Les pratiques techniques permettant la livraison continue (tests continus, virage à gauche pour la sécurité, exhaustivité en termes de tests et d'observabilité) sont encore plus importantes dans les domaines hautement réglementés et essentiels à la sécurité. La livraison continue a été correctement appliquée dans des domaines très réglementés, tels que les services financiers et les administrations publiques.

Bien que la livraison continue soit possible pour toutes sortes de logiciels, elle demande beaucoup d'efforts. Néanmoins, elle présente des avantages considérables. Une étude menée par DevOps Research and Assessment (DORA) démontre qu'une livraison continue performante offre les avantages suivants :

  • Amélioration des performances de livraison de logiciels, mesurées à l'aide des quatre métriques clés, et augmentation du niveau de disponibilité.
  • Augmentation du niveau de qualité, mesuré par le pourcentage de temps passé par les équipes sur le retraitement ou sur des tâches non planifiées, comme indiqué dans le rapport sur l'état du DevOps en 2016 (p. 25-26) et le rapport sur l'état du DevOps en 2018 (p. 27-29).
  • Réduction des risques de surmenage (épuisement physique, mental ou émotionnel dû à la surcharge de travail ou au stress), augmentation de la satisfaction au travail et optimisation de la culture organisationnelle.
  • Réduction des contraintes liées au déploiement, une mesure qui permet d'évaluer si les déploiements engendrent des perturbations ou s'ils se déroulent plutôt de manière simple et fluide. Cela permet également de déterminer le niveau de peur et d'anxiété que les ingénieurs et le personnel technique peuvent ressentir lorsqu'ils transfèrent du code en production.
  • Impact sur la culture, ce qui entraîne des niveaux de sécurité psychologique plus élevés et une culture organisationnelle plus axée sur la mission.

Le schéma suivant montre l'impact d'un ensemble de pratiques techniques sur la livraison continue, qui génère à son tour les résultats répertoriés ci-dessus :

Montre comment les pratiques techniques génèrent des résultats dans d'autres fonctionnalités

La livraison continue ne représente qu'un aspect permettant d'obtenir les résultats précédemment évoqués, bien qu'il soit essentiel. D'autres fonctionnalités culturelles et organisationnelles présentées dans le programme de recherche de DORA contribuent également à l'obtention de ces résultats. Vous pouvez assurer la livraison continue à l'aide des pratiques techniques décrites dans ce document.

Mettre en œuvre la livraison continue

Selon une étude menée par le programme de recherche de DORA, les fonctionnalités techniques suivantes permettent d'assurer la livraison continue. Le leadership transformationnel au sein de l'organisation permet également la mise en œuvre de la plupart de ces fonctionnalités techniques.

Pour aider votre équipe à obtenir un débit plus élevé et des lancements moins risqués, mettez en œuvre les pratiques de livraison continue suivantes :

  • L'automatisation des tests : l'utilisation d'ensembles de tests automatisés complets principalement créés et gérés par les développeurs. Les ensembles de tests efficaces sont fiables, c'est-à-dire que les tests identifient des défaillances réelles et ne transmettent que du code diffusable.
  • L'automatisation des déploiements : le degré selon lequel les déploiements sont entièrement automatisés et ne nécessitent aucune intervention manuelle.
  • Le développement à branche unique : caractérisé par moins de trois branches actives dans un dépôt de code (les branches et les fourches ayant des durées de vie très courtes, telles qu'inférieures à un jour) avant d'être fusionné avec le dépôt de code principal. Les équipes dédiées aux applications ont rarement ou jamais de périodes de verrouillage du code lorsqu'aucun utilisateur ne peut enregistrer le code, ni effectuer de demandes d'extraction en raison de conflits de fusion, au gel du code ou aux phases de stabilisation.
  • Le virage à gauche pour la sécurité : l'intégration de la sécurité dès les phases de conception et de test du processus de développement logiciel. Ce processus comprend la réalisation d'examens de sécurité des applications, l'intégration de l'équipe chargée de la sécurité des informations dans le processus de conception et de démonstration des applications, l'utilisation de bibliothèques et de packages de sécurité pré-approuvés, et le lancement de tests des fonctionnalités de sécurité dans le cadre de l'ensemble de tests automatisés.
  • Une architecture faiblement couplée : une architecture qui permet aux équipes de tester et de déployer leurs applications à la demande, sans nécessiter d'orchestration avec d'autres services. Avec une architecture faiblement couplée, vos équipes peuvent travailler indépendamment sans avoir à se soucier de la compatibilité et des services des autres équipes, ce qui leur permet de travailler rapidement et d'apporter de la valeur au sein de l'organisation.
  • Le fait de donner le choix des outils aux équipes : les équipes qui peuvent choisir leurs outils sont les plus performantes sur le plan de la livraison continue. Personne ne sait mieux que les spécialistes ce dont ils ont besoin pour être efficaces.
  • L'intégration continue (CI) : une pratique de développement qui implique l'enregistrement régulier du code. Chaque enregistrement déclenche un ensemble de tests rapides pour détecter les régressions, que les développeurs corrigent immédiatement. Le processus CI crée des builds et des packages canoniques qui finissent par être déployés et diffusés.
  • Les tests continus : les tests sont effectués tout au long du cycle de livraison des logiciels plutôt que sous la forme d'une phase distincte une fois le développement terminé. Avec les tests continus, les développeurs et les testeurs travaillent côte à côte. Les équipes performantes pratiquent le développement piloté par les tests, reçoivent les commentaires de tests en moins de 10 minutes, et examinent et améliorent en permanence leurs suites de tests (par exemple, pour mieux détecter les défauts et maintenir la complexité sous contrôle).
  • Le contrôle des versions : l'utilisation d'un système de contrôle des versions, tel que Git ou Subversion, pour tous les artefacts de production, y compris le code d'application, les configurations d'application, les configurations système et les scripts permettant d'automatiser le build et la configuration des environnements.
  • La gestion des données de test : les bonnes pratiques incluent la capacité à disposer de données adéquates pour exécuter votre suite de tests, la capacité à acquérir les données nécessaires à la demande, et le fait que les données ne limitent pas le nombre de tests que vous pouvez exécuter. Dans la mesure du possible, vos équipes doivent minimiser la quantité de données de test nécessaire pour exécuter des tests automatisés.
  • La surveillance et l'observabilité complètes : permet aux équipes de comprendre l'état de leurs systèmes. Les solutions efficaces permettent aux équipes de surveiller les métriques prédéfinies, y compris l'état du système tel qu'il est perçu par les utilisateurs. Elles permettent également aux ingénieurs de déboguer les systèmes de manière interactive et d'explorer des propriétés et des modèles dès leur première apparition.
  • Les notifications proactives : permettent de surveiller l'état du système de sorte que les équipes puissent détecter et limiter les problèmes de manière préemptive.
  • La gestion des modifications des bases de données : les modifications de bases de données ne ralentissent pas les équipes si elles suivent certaines pratiques clés, y compris le stockage de ces modifications sous forme de scripts dans le contrôle des versions (et la gestion de ces modifications de la même manière que celles apportées aux applications de production), l'accessibilité de ces modifications pour tous les utilisateurs impliqués dans le cycle de livraison des logiciels (y compris les ingénieurs) et la communication avec toutes les parties lorsque les modifications de l'application nécessitent des modifications de bases de données.
  • La gestion du code : les systèmes et les outils qui aident les développeurs à modifier le code géré par d'autres utilisateurs, à trouver des exemples dans le codebase, à réutiliser le code d'autres personnes et à ajouter, mettre à niveau et migrer vers des nouvelles versions de dépendances sans interrompre leur code.

Même si la livraison continue est souvent associée à l'intégration continue et comprise dans le raccourci CI/CD, les recherches démontrent que l'intégration continue ne constitue qu'un élément de la mise en œuvre de la livraison continue. Pour obtenir des versions fiables et sans risque, vous avez besoin d'une collaboration étroite entre toutes les personnes impliquées dans la livraison de logiciels, et pas seulement les développeurs de logiciels. De même, votre équipe doit adopter de nouvelles méthodes de travail et acquérir de nouvelles compétences.

Problèmes courants liés à la mise en œuvre de la livraison continue

Certaines entreprises pensent à tort qu'elles peuvent mettre en œuvre la livraison continue en réalisant plus souvent leur processus de déploiement existant. Cependant, la mise en œuvre des fonctionnalités techniques qui assurent la livraison continue nécessite généralement des processus et des modifications d'architecture conséquents. Augmenter la fréquence des déploiements sans améliorer les processus et l'architecture est susceptible d'entraîner des taux de défaillance plus élevés et de provoquer le surmenage de vos équipes.

De nombreuses descriptions de la livraison continue se concentrent sur les outils et les modèles, tels que le pipeline de déploiement qui transfère les modifications depuis le contrôle des versions vers l'environnement de production. Toutefois, vous n'atteindrez pas les résultats escomptés si vous vous contentez d'utiliser des outils modernes sans mettre en œuvre les pratiques techniques nécessaires et le changement de processus décrit dans ce document.

Le schéma suivant illustre la courbe en J qui serait typique des programmes de transformation, d'après les recherches de DORA. Pour quitter le bas de la courbe en J, votre équipe doit envisager la reconception et la simplification du processus, l'amélioration de l'architecture, le développement des capacités et des compétences, ainsi que l'intégration de l'automatisation et des outils.

Schéma de la courbe en J affichant les transformations types, issu du rapport sur l'état du DevOps en 2018

Sur le schéma, on peut distinguer les étapes suivantes :

  • Au début de la courbe, les équipes commencent la transformation et identifient les résultats rapides.
  • Dans le cadre d'une amélioration initiale, l'automatisation aide les équipes peu performantes à progresser.
  • En raison de la diminution de l'efficacité (le bas de la courbe en J), l'automatisation augmente les exigences des tests, qui sont traitées manuellement. Une grande partie de la dette technique empêche le progrès.
  • À mesure que les équipes commencent à sortir de la courbe, la dette technique et la complexité accrue entraînent une augmentation des contrôles manuels et des couches de processus en cas de modifications, ce qui ralentit le travail.
  • En haut de la courbe, le travail d'amélioration continu mène à l'excellence et à des niveaux de performances élevés. Les équipes performantes et ultraperformantes se servent de leur expertise et apprennent de leurs environnements pour augmenter la productivité.

Un moyen efficace de limiter l'impact de la courbe en J consiste à effectuer une cartographie de flux de valeur pour détecter et anticiper l'effet des goulots d'étranglement. Lors de la réalisation d'une cartographie de flux de valeur, vous examinez une seule modification pendant son transfert du contrôle des versions vers l'environnement de production :

  1. Tenez compte des différents processus par lesquels passe chaque modification, tels que les tests automatisés et manuels, l'examen de sécurité, la gestion du changement et la diffusion en production.
  2. Mesurez le temps total que met la modification à être publiée à partir du contrôle des versions. Pour chaque processus, mesurez les éléments suivants :
    • Le temps écoulé réel et le temps à valeur ajoutée (le temps pendant lequel le travail est effectué) impliqués dans l'exécution du processus de bout en bout.
    • Il s'agit de la durée exprimée en pourcentage pendant laquelle le travail est renvoyé car il n'a pas été effectué correctement la première fois. Cette métrique est connue sous le nom de pourcentage complet et exact ou %C/A.

Le but de la cartographie de flux de valeur est de vous aider à identifier les éléments inefficaces au sein de votre processus. En équipe, créez un schéma représentant l'aspect du flux de valeur que vous souhaitez atteindre dans six mois, puis attribuez les capacités nécessaires à l'obtention de ce résultat. Identifiez et supprimez les obstacles avec un processus dont le temps écoulé est élevé par rapport au temps à valeur ajoutée ou qui présente un taux %C/A faible.

En règle générale, la mise en œuvre d'un pipeline de déploiement nécessite des processus et des modifications d'architecture conséquents. Comme le pipeline de déploiement passe de la phase d'enregistrement à la phase de diffusion, il connecte plusieurs équipes entre elles. Il est essentiel que les représentants de toutes les équipes effectuent un exercice de cartographie de flux de valeur, et qu'ils s'accordent sur une chaîne d'outils et des processus communs (par exemple, pour le déploiement des environnements de test et de production) afin d'atteindre l'état futur.

La mise en œuvre de la livraison continue consiste en un travail d'amélioration constant et quotidien, dans le but d'atteindre les résultats escomptés. Les outils et les modèles sont utiles, mais uniquement pour étayer ce travail d'amélioration, qui reste essentiel.

Mesurer la livraison continue

En fin de compte, l'objectif de la livraison continue consiste à s'assurer que les versions sont exécutées de manière peu risquée pendant les heures ouvrables. Idéalement, aucun employé ne doit travailler en dehors des heures ouvrables pour lancer des déploiements ou des versions. Il s'agit donc d'un élément important à mesurer.

Vos performances en termes de livraison continue sont reflétées dans les résultats que vous obtenez. Vous pouvez effectuer l'évaluation DevOps rapide de DORA pour mesurer vos performances par rapport aux métriques clés de la livraison continue :

  • Des délais de livraison courts pour les modifications standards et urgentes, avec l'objectif d'utiliser votre processus habituel pour les modifications urgentes
  • Des taux d'échec liés aux modifications faibles
  • Un délai de restauration rapide du service en cas de pannes ou de dégradations
  • Des fréquences de publication qui garantissent la disponibilité rapide des fonctionnalités à priorité élevée et des corrections de bugs.

Comme indiqué au début de ce document, la mise en œuvre de la livraison continue doit également contribuer à réduire les niveaux de retraitement, les contraintes liées au déploiement, et le temps passé par les équipes sur le retraitement ou sur des tâches non planifiées.

Étapes suivantes