Modèle de déploiement de livraison continue

Vous avez découvert les nombreux inconvénients du « déploiement épique » en tant que modèle de livraison de logiciels, mais savoir ce qui ne fonctionne pas bien n’est que la moitié de la bataille. Dans cette unité, vous allez découvrir l’alternative à cette méthode monolithique et comment elle peut améliorer votre objectif de fiabilité améliorée.

Il vaut également la distinction entre deux termes connexes qui sont parfois utilisés de façon interchangeable :

• Livraison continue : chaque modification qui réussit des tests automatisés est prête à être déployée en production, mais la mise en production réelle est contrôlée par une approbation manuelle.
• Déploiement continu : chaque modification qui réussit des tests automatisés est automatiquement publiée en production, sans porte manuelle.

Les deux dépendent des mêmes bases (intégration fréquente, tests automatisés, pipelines reproductibles). Ce module se concentre sur ces bases partagées.

Qu’est-ce que la livraison continue ?

La livraison continue est une méthode par laquelle chaque modification apportée à votre codebase est maintenue disponible plus rapidement, moins stressante, moins risquée et de manière plus reproductible. Au lieu de faire de chaque déploiement logiciel ou de mettre à jour un événement épique, la livraison continue le transforme en une expérience rapide, routine et prévisible qui se produit à la demande.

• Fréquence de déploiement : avec un modèle de livraison continue, les déploiements se produisent fréquemment. La cadence peut être mensuelle, hebdomadaire, quotidienne ou même toutes les heures. Le point clé est le suivant : vous déployez des changements plus petits et plus ciblés, plus souvent.

• Déclenché par la validation du code : au lieu d’attendre une fenêtre de mise en production planifiée à l’avance, le pipeline de remise démarre lorsque le code est validé. Ce code peut correspondre à un logiciel, une infrastructure ou même des éléments tels que les configurations logicielles. Chaque modification est ensuite générée, testée et prête à être mise en production. Selon les contrôles de votre organisation, la promotion vers la production peut toujours se produire ultérieurement, après une approbation.

• Tests automatisés : vous pouvez utiliser des tests automatisés intégrés non seulement pour tester le code, mais également pour fournir un retour d’expérience rapide concernant les résultats de ces tests. Ce retour d’expérience rapide vous permet d’itérer et de récupérer rapidement suite aux tests non réussis.

  Une fois votre code testé, vous pouvez tester le déploiement, de bout en bout, dans une série d’environnements intermédiaires tels que les test, l’AQ (assurance qualité), etc. Le lancement de vos déploiements via ces environnements devient une partie intégrante de l’expérience de déploiement.

• Enregistrements historiques : vous souhaitez un historique des activités de déploiement, mais vous souhaitez également pouvoir rapprocher votre environnement de production à tout moment. Vous souhaitez identifier le déploiement qui a créé votre environnement de production actuel. Grâce à ces connaissances, vous pouvez tracer les configurations, les résultats des tests et le code lui-même jusqu’à la demande de tirage (pull request) individuelle qui a déclenché le déploiement.

Objectifs de déploiement

Maintenant que vous savez comment fonctionne la livraison continue, tenez compte des objectifs de livraison continue et d’autres pratiques DevOps vous aident à atteindre lors du déploiement de solutions logicielles.

Objectif 1 : Réduire le stress impliqué par le déploiement de services tout en renforçant la fiabilité de ces services

Réduire le stress des déploiements de logiciels et d’infrastructure améliore l’expérience quotidienne des ingénieurs qui les exécutent. L’augmentation de la fiabilité résultante bénéficie également aux utilisateurs finaux, qui voient moins de pannes et d’interruptions.

Objectif 2 : Réduire le délai entre le moment où vous savez qu’un changement est nécessaire et le moment où ce changement est déployé en production

Par exemple, supposons que vous avez identifié un défaut de code impactant le chiffre d’affaires et que vous savez exactement comment le corriger. Avec les pratiques DevOps matures, le chemin de la validation à la production est court et prévisible. La modification est générée, testée automatiquement dans les environnements appropriés et préparée pour la mise en production en quelques minutes. Une fois l’approbation requise donnée, elle peut être déployée en production au lieu d’être retardée jusqu'à une prochaine fenêtre de publication.

Objectif 3 : Réduire le temps entre avoir une idée et fournir des logiciels utilisables

Cet objectif est similaire à celui précédent, mais il se concentre sur l’innovation plutôt que sur les correctifs. Combien de temps faut-il pour agir sur une nouvelle idée ? Avec ce modèle de déploiement, vous pouvez intégrer un nouveau concept dans un système de production avec confiance que l’ajout ne s’interrompt pas ou n’entrave pas le système actuel. Cette confiance vous permet de fournir rapidement de nouvelles fonctionnalités.

Résultats du déploiement

Les objectifs abordés dans cette unité ne sont pas seulement des aspirations théoriques, ils sont mesurables. Depuis 2014, l’équipe DevOps Research and Assessment (DORA) a publié l’état annuel de la recherche DevOps sur les performances de livraison de logiciels. Ces dernières années, ce travail a été publié en tant que Accelerate State of DevOps Report. Le modèle DORA actuel suit cinq métriques de livraison :

• Fréquence de déploiement
• Modifier le délai d’exécution
• Taux d’échec des modifications
• Temps de récupération après échec du déploiement
• Taux de remaniement du déploiement

Année après année, la recherche montre que les équipes plus performantes livrent des modifications plus fréquemment, passent de la validation du code à la production plus rapidement, se remettent plus rapidement des déploiements échoués, et passent moins de temps à résoudre les problèmes liés au déploiement. Pour connaître les dernières définitions de recherche et de métriques, consultez les métriques de livraison de logiciels de DORA.

Ces résultats valident l’idée que les pratiques de déploiement sont importantes.