Modèle de déploiement de livraison continue

Vous avez découvert les nombreux inconvénients du « déploiement de type épopée » 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 découvrez l’alternative à cette méthode monolithique ainsi que la façon dont elle peut favoriser votre objectif d’amélioration de la fiabilité.

Qu’est-ce que la livraison continue ?

La livraison continue est une méthode qui vous permet de rendre les changements logiciels accessibles de manière plus rapide, moins stressante, moins risquée et plus reproductible. Au lieu de faire de chaque déploiement ou de chaque mise à jour de logiciels une épopée, la livraison continue s’efforce de transformer l’événement en une expérience rapide, routinière 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 fréquence peut être comme bon vous semble : mensuelle, hebdomadaire, quotidienne, voire horaire. Le point clé est le suivant : vous déployez des changements plus petits et plus ciblés, plus souvent.

• Initié par un dépôt de code : au lieu d’être planifiés longtemps à l’avance, les déploiements ont lieu lorsque le code est déposé. Ce code peut correspondre à un logiciel, une infrastructure ou même des éléments tels que les configurations logicielles.

• 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

Une fois que vous savez comment fonctionne la livraison continue, tenez compte des objectifs que vous pouvez atteindre en utilisant des pratiques DevOps telles que celle-ci pour le 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

Il s’agit d’une relation gagnant-gagnant. Vous augmentez la satisfaction liée au travail effectué en réduisant le stress des déploiements de logiciels et d’infrastructures. En parallèle, vous augmentez la satisfaction des utilisateurs finaux en rendant vos systèmes plus fiables. Compte tenu de cet impact positif sur l’expérience utilisateur du client, il s’agit d’une relation gagnant-gagnant.

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, supposez que vous avez identifié un défaut dans le code qui impacte le chiffre d’affaires. Vous savez exactement quel est le problème et comment écrire le code du correctif. Combien de temps vous faut-il pour mettre ce code en production ? Combien de chaînes devez-vous tirer (pull) ? Comment effectuez-vous les tests ? Grâce aux pratiques DevOps, vous pouvez écrire du code de commit, aller déjeuner et recevoir une notification indiquant que le problème a été résolu avant d’être de retour à votre bureau.

Objectif 3 : Réduire le délai entre une idée et la livraison d’un logiciel utilisable

Cela est très similaire à l’objectif précédent, mais au lieu d’implémenter des changements, il s’agit ici de pure innovation. Combien de temps vous faut-il pour implémenter une innovation ? Avec ce modèle de déploiement, vous pouvez intégrer un nouveau concept dans un système de production, et avoir la certitude que l’innovation ajoutée ne va pas bloquer le système actuel ou empêcher son bon fonctionnement. Avec cette garantie, vous pouvez rapidement livrer la nouvelle fonctionnalité.

Résultats du déploiement

Les objectifs décrits dans cette unité ne sont pas seulement des aspirations théoriques, ils sont réalisables. Voici quelques statistiques tirées du Rapport Accelerate sur l’état du DevOps en 2019 par DevOps Research and Assessment (DORA) et Google Cloud DevOps & SRE. Dans ce rapport, il est indiqué que les sociétés DevOps à haute performance ont montré que :

• Effectuent des déploiements 208 fois plus souvent.
• Vont 106 ois plus vite pour passer du commit au déploiement.
• Ont un taux d’échec des changements sept fois moins élevé.
• Ont un délai de reprise d’activité après incident 2 604 fois plus rapide.

Tout ceci se traduit par une augmentation du revenu et un délai de commercialisation plus rapide.

Ces chiffres valident l’idée selon laquelle les pratiques de déploiement sont importantes.