CI/CD : Qu’est-ce que la livraison continue ?

Dans le premier article, nous avons parlé de CI ou Intégration Continue. Cet article examine la seconde m   oitié de l’acronyme CI/CD, la Livraison Continue. La livraison continue prend le build sorti du processus CI et le place dans un environnement d’acceptation (aussi appelé recette) pour une évaluation plus approfondie avant de promouvoir le code en production (la version publiée).

Pour rappel, la CI comprend la spécification, le codage, les tests et l’assemblage (build) de logiciels dans un processus qui se répète rapidement. Des systèmes automatiques compilent et testent une application pendant que les développeurs de logiciels soumettent le code dans un système de contrôle de version. Le code généré à chaque itération alimente le processus CD. Le processus CD complète la chaîne comprenant le développement, la livraison et la maintenance des logiciels.

Qu’est-ce que la livraison continue ?

Le produit de la CI est une nouvelle version stabilisée d’une application avec de nouvelles fonctionnalités et des bugs corrigés. Après la phase de test dans le processus CI, la partie CD prend le relais. Dans ce processus de CD, le logiciel passe de l’environnement de développement à un ou plusieurs environnements de test pour une évaluation plus approfondie. Les équipes de développement et d’exploitation (DevOps) ainsi que d’autres parties prenantes décident quand et si une version sera déployée en production. Une fois lancé, le déploiement est géré par un processus automatisé.

Comme le processus CI, le processus CD se compose également de quatre phases : publication (release), déploiement, exploitation et surveillance. Cependant, le cycle peut se répéter plusieurs fois en se déployant dans des environnements différents pour effectuer des tests différents, avant d’arriver à la version définitive en production.

Même si certains processus peuvent se déployer directement en production, la plupart déploient des logiciels sur une copie de l’environnement de production, souvent appelé acceptation ou staging. La surveillance et les tests et automatisés se poursuivent dans l’environnement d’acceptation pendant que les différentes parties prenantes évaluent les nouvelles fonctionnalités. Le diagramme ci-dessous montre la partie CD du processus CI/CD sur la droite.

• Une version ‘release’ produite par le développement sert d’entrée au processus du CD.
• Les opérateurs déploient l’application dans l’environnement de production ou d’acceptation.
• Les parties prenantes font fonctionner l’application.
• Des systèmes automatisés surveillent la disponibilité, les performances et les fonctions.
• Les retours des utilisateurs et les résultats des tests sont incorporés à la phase de spécification du CI.

La différence entre l’acceptation et la production

La version en production est la version active en ligne d’une API, d’une application web ou d’un site web. Tout bug dans le logiciel ou faiblesse de l’infrastructure affecte directement l’utilisateur final du produit. Bien que certains processus livrent le logiciel directement à la production, d’autres passent par un examen plus approfondi avant la publication générale.

L’environnement d’acceptation permet aux parties prenantes de visualiser, d’utiliser et d’évaluer la dernière version avant que l’application ne passe en production. Plusieurs tâches différentes peuvent avoir lieu lors de l’acceptation avant que l’équipe d’exploitation ne publie une version en production.

• Tests d’utilisation. L’équipe de l’expérience utilisateur travaille avec de vrais utilisateurs pour s’assurer que l’application est facile à utiliser et que les utilisateurs peuvent effectuer les tâches.
• Test de charge. Que se passe-t-il lorsque plusieurs utilisateurs (des milliers peut-être) utilisent l’application en même temps ? Le logiciel et le matériel peuvent-ils résister au stress ?
• Tests d’endurance. Dans quelle mesure un système résiste-t-il au stress pendant de longues périodes ?
• Évaluation par les parties prenantes. Les parties prenantes (stakeholders) donnent leur avis sur la question de savoir si la version est acceptable et prête pour le déploiement en production. Dans les parties prenantes on peut trouver la direction, des services tels que l’assurance qualité et l’expérience utilisateur, ou des utilisateurs qui ont accepté de fournir des commentaires.

Pourquoi utiliser la livraison continue ?

L’intégration continue et la livraison continue aident les équipes de développement et d’exploitation à fournir plus rapidement de nouveaux logiciels et fonctionnalités à l’utilisateur avec moins d’erreurs. On peut citer quelques autres avantages de la livraison continue :

• Moins de risques. De changements mineurs signifient qu’il y a moins de choses qui peuvent mal tourner, et lorsque ça arrive, le processus permet de corriger ou d’annuler rapidement et facilement les modifications.
• Boucle de rétroaction plus rapide. Des voies de communication directes, pour les opérateurs et les parties prenantes, permettent à l’équipe de développement d’intégrer rapidement les retours.
• Réaction rapide au marché. Réagissez à l’évolution de la demande des consommateurs, comme pour un produit ou un changement d’appareil utilisé pour accéder au produit.
• Moins de goulots d’étranglement. Avec des mises à jour plus petites et plus fréquentes, vous éliminez les goulots d’étranglement produits par la livraison de modifications majeures. Par exemple, il faut beaucoup moins de temps à l’assurance qualité pour traiter une version avec 12 modifications qu’il n’en faut pour des centaines ou milliers de modifications générées par des cycles de développement plus longs.

Quelle est la différence entre la livraison continue et le déploiement continu ?

La livraison continue et le déploiement continu suivent les phases CI du processus de développement ; cependant, le déploiement continu est complètement automatisé. Avec un déploiement continu, le déploiement en production est automatique si la version peut passer les tests automatisés.

Pour la livraison continue par contre, ce sont les équipes de développement et d’exploitation qui décident quand le logiciel doit être publié. Lorsque c’est décidé, ça déclenche le processus automatisé qui déploie l’application en production.

L’importance de l’automation

Tout comme la CI, la CD s’appuie fortement sur des processus automatisés. Les processus automatisés importent des logiciels, mettent à jour l’infrastructure, mettent à jour les données, effectuent des tests tels que des tests préliminaires, des tests de charge et des tests d’endurance. Avec une livraison continue, le déploiement en production se fait en seulement quelques clics. En production, les processus automatisés surveillent et collectent en continu les données de disponibilité, de performance et de fonctionnement.

Votre environnement d’acceptation et Uptrends

Votre environnement d’acceptation doit refléter votre environnement de production, et votre surveillance Uptrends en fait partie. Toute votre surveillance peut faire partie intégrante de votre CD automatisé. Si votre environnement d’acceptation est directement accessible depuis le web (avec ou sans authentification), le vaste réseau d’Uptrends de plus de 200 emplacements des points de contrôle permet de tester vos API ou sites web pour la disponibilité, les performances et les fonctionnalités. Sinon, vous pouvez également envisager les Points de Contrôle Privés qui résident sur votre intranet afin que vous puissiez utiliser la suite complète de produits de surveillance Uptrends derrière votre pare-feu. Plus d’informations dans le prochain article.

Épisode suivant : Uptrends et vos processus CI/CD (prochainement)