Qu'est-ce que la livraison continue ?

Au cœur du DevOps se trouve un changement de mentalité. Plutôt que de considérer le processus de développement logiciel comme un processus à sens unique, où les exigences, le code et les rapports sont transmis de manière linéaire d'une équipe à l'autre, le DevOps favorise la collaboration et un retour d'information rapide à partir de cycles courts et itératifs.

Changer votre définition de ce qui est terminé peut vous aider à adopter cette mentalité : au lieu de considérer que votre partie est terminée lorsque vous passez votre code à l'équipe suivante de la chaîne, votre nouvelle fonctionnalité ou votre changement de code n'est terminé que lorsqu'il est publié. Si un problème est détecté à un stade quelconque du processus, la communication rapide de ce problème et la collaboration à sa résolution permettent de le résoudre plus rapidement que de longs rapports devant être approuvés par un comité de modification. C'est la définition même de la livraison continue.

En considérant l'ensemble du cycle de développement logiciel, plutôt qu'une partie seulement, vous comprenez mieux ce qui doit être fait pour livrer un logiciel aux utilisateurs et vous avez la possibilité d'ouvrir davantage de voies de communication avec les autres équipes impliquées.

La livraison continue consiste à identifier les problèmes qui ralentissent ce processus de livraison et à construire un pipeline automatisé pour rendre la publication plus rapide et plus fiable afin que vous soyez toujours prêt à publier. Avec votre pipeline en place, vous devriez être capable de déployer n'importe quel build valide d'une simple commande.

L'intégration continue constitue la base de ce processus, avec des modifications de code validées au moins quotidiennement, suivies d'un processus de build et de test automatisé pour fournir un retour d'information rapide aux développeurs. En cas d'échec d'un build ou d'un test, la résolution du problème est la priorité de tous.

En détectant rapidement les bugs, vous pouvez les corriger pendant que le code est encore frais dans votre esprit et éviter que d'autres fonctionnalités ne soient construites sur un mauvais code pour être ensuite supprimées. Avec la livraison continue, le build contenant les derniers changements du processus de CI est automatiquement promu à travers une série d'environnements de pré-production. Bien que le dernier push en production soit déclenché manuellement, il suit toujours un processus scripté, ce qui le rend facile à répéter afin que vous puissiez publier aussi souvent que nécessaire.

La construction de votre pipeline de CI/CD est une opportunité de collaborer avec les différents acteurs de votre processus de publication afin de pouvoir prendre en compte leurs besoins dans la conception du pipeline. Avec un peu de chance, vous vous êtes déjà échangé avec vos collègues de l'assurance qualité lors de la conception des tests automatisés.

L'ajout d'une étape de test exploratoire manuel dans un environnement de test approprié (aussi proche que possible de la production) permettra d'identifier des défaillances que vous n'aviez pas anticipées (et qui pourront ensuite être couvertes par des tests automatisés). C'est une étape importante pour la livraison continue.

L'équipe chargée de la sécurité informatique ou de la cybersécurité est souvent considérée comme un obstacle à des publications fréquentes en raison du temps nécessaire à la réalisation d'un audit de sécurité et des longs rapports qui en découlent. Adopter une approche DevSecOps vous aidera à intégrer les exigences de sécurité dans votre pipeline.

Les étapes de conception, les environnements et les tests exacts dont vous avez besoin dépendent de l'architecture de votre logiciel et de vos priorités organisationnelles. Si vous concevez un système basé sur des micro-services, vous pouvez exploiter l'architecture pour effectuer des tests sur des services individuels en parallèle avant de les combiner pour une intégration plus complexe et pour des tests de bout en bout.

Des tests exploratoires manuels pour chaque correctif de bug peuvent sembler excessifs, auquel cas il peut être plus efficace d'avoir des étapes optionnelles ou des pipelines alternatifs basés sur le type de modification pour la livraison continue.

Une fois que vous avez décidé des étapes de votre pipeline, y compris des tests à effectuer dans chacune d'entre elles, il est temps de scripter le processus pour s'assurer qu'il est fiable et reproductible. Pour éviter d'introduire des incohérences, le même artefact de build de l'étape CI doit être déployé dans chaque environnement de pré-production et en production.

Idéalement, les environnements de test devraient être rafraîchis pour chaque nouveau build, et l'utilisation de conteneurs avec une approche infrastructure-as-code signifie que vous pouvez scripter ces étapes, démonter et recréer de nouveaux environnements si nécessaire.

Si votre pipeline comprend des environnements de staging pour les équipes de support, de vente ou de marketing afin qu'elles se familiarisent avec les nouvelles fonctionnalités, vous préférerez peut-être contrôler manuellement le moment où ils sont mis à jour avec un nouveau build pour éviter de perturber le travail en cours. Comme pour la dernière publication, le déploiement peut encore être scripté pour que le processus reste rapide et cohérent.

La livraison continue promet des publications plus rapides sans compromettre la qualité, mais pour que cela devienne une réalité, il faut la coopération de multiples parties d'une organisation.

Le décloisonnement est à la fois un défi à court terme et un avantage à long terme, car cette collaboration vous aidera à travailler plus efficacement.

L'implémentation de la livraison continue demande un investissement en termes de temps et peut paraître intimidante. L'adoption d'une approche itérative et la mise en place de votre processus au fil du temps rend cette démarche plus facile à gérer et vous permet de démontrer ses bénéfices aux principaux responsables. Recueillir des données sur les temps de build et de test et les comparer aux procédures manuelles est un moyen simple de montrer le retour sur investissement, tout comme les taux de défaillance.

Il peut être utile de mesurer la valeur de la livraison continue lors de la planification de vos exigences en matière d'infrastructure. À mesure que vous développez votre processus de publication, vous voudrez probablement commencer à exécuter plusieurs builds et tests en parallèle, et les machines disponibles peuvent devenir un facteur limitant. Une fois que vous aurez optimisé les performances de votre pipeline, vous voudrez peut-être envisager de passer à une infrastructure hébergée dans le Cloud afin de pouvoir l'adapter à vos besoins.

La création d'un pipeline de CI/CD peut sembler une tâche intimidante, nécessitant initialement beaucoup de travail de la part de l'équipe, mais lorsqu'il est bien fait, le processus de CI/CD peut permettre à votre équipe de mettre en place un processus de livraison de logiciels en dix fois moins de temps. Toutefois, il est important de suivre certaines bonnes pratiques de CD pour que le processus se déroule correctement.

La livraison continue est le processus d'automatisation des différentes étapes nécessaires à la mise en production d'un logiciel. Il n'est cependant pas question d'automatiser entièrement la publication du logiciel. C'est là le domaine du déploiement continu. On peut considérer la livraison continue et le déploiement continu comme différentes parties du même processus de CI/CD.

En savoir plus sur les différences entre la livraison continue et le déploiement continu

La livraison continue facilite et accélère la publication des logiciels, ce qui vous permet de déployer en production beaucoup plus fréquemment. Au lieu d'une grosse version trimestrielle ou annuelle, de plus petites mises à jour sont fréquemment livrées. Cela signifie non seulement que les utilisateurs bénéficient de nouvelles fonctionnalités et de correctifs de bugs plus rapidement, mais aussi que vous pouvez voir comment votre logiciel est utilisé dans le monde réel et ajuster vos plans en conséquence.

Si certaines organisations préfèrent garder le contrôle sur la dernière étape du processus de publication, pour d'autres, la conclusion logique d'un pipeline de CI/CD est d'automatiser la publication finale, en utilisant une pratique connue sous le nom de déploiement continu.