Comprendre la livraison continue

La livraison continue (CD) vient compléter l'intégration continue (CI) en automatisant les étapes du processus de mise en production des logiciels.

À chaque fois que vous fusionnez les modifications du code dans une branche donnée, votre processus d'intégration continue réalise une série de vérifications, telles que les tests unitaires, et crée un build. La livraison continue prolonge ce processus en déployant automatiquement chaque build dans une série d'environnements de test et de préproduction, et en exécutant d'autres tests automatisés.

Ces tests peuvent inclure les tests d'intégration, les tests d'interface utilisateur, les tests de performances (tels que les tests de charge, d'endurance et de contrainte), ainsi que les tests de bout en bout. Selon votre activité, il peut également être intéressant d'utiliser la livraison continue pour exécuter des tests de sécurité et d'accessibilité, ainsi que des tests manuels d'acceptation par l'utilisateur ou exploratoires. Les builds qui franchissent les différentes étapes sont considérés comme prêts pour la production.

Comme pour l'intégration continue, la clé du succès de la livraison continue est d'automatiser autant que possible le processus. Cela inclut des retours sur chaque étape et des alertes pour prévenir l'équipe si le build ne franchit pas une étape, afin de résoudre le problème rapidement.

La livraison continue et le déploiement continu impliquent tous deux le déploiement automatique des builds dans les environnements et l'exécution de tests automatiques. Ainsi, les deux termes sont parfois perçus comme interchangeables. Cependant, il existe une distinction notable entre les deux.

Avec le déploiement continu, un changement de code est automatiquement déployé en production s'il franchit toutes les étapes de test. Par contre, la livraison continue implique une étape manuelle pour la dernière phase, à savoir la mise en production de votre logiciel.

Si le déploiement continu peut sembler être le but ultime de toute équipe de développement logiciel, ce n'est pas sans raison que de nombreuses équipes optent pour la livraison continue.

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

La phase finale d'un processus de CI/CD implique la mise en production des modifications du code. Avec la livraison continue, le choix du moment de la mise en production reste une étape manuelle, même si le processus de publication est quant à lui automatique.

Certaines équipes approchent la livraison continue comme une étape du déploiement continu. Le déclenchement manuel du déploiement final et la mise en production constituent un filet de sécurité qui vous permet d'aborder avec confiance vos tests et vérifications automatisées. Dans ce cas, optez pour une livraison continue sur plusieurs mois avant de franchir le pas de la mise en production automatique des changements de code validés par les tests.

Toutefois, le déploiement des mises à jour de votre logiciel plusieurs fois par jour ou heure n'est pas toujours le meilleur choix. Pour les logiciels versionnés, tels que des applications mobiles, des API, des logiciels embarqués ou des produits de bureau, il est souvent préférable de regrouper les modifications dans des livraisons plus importantes. Les utilisateurs de produits installés ne s'attendent pas à mettre à jour leurs applications plusieurs fois par jour, tandis qu'une nouvelle version d'API peut fortement impacter vos clients. Le choix entre la livraison continue et le déploiement continu dépend des priorités de votre entreprise et de vos utilisateurs.

Si les étapes, les environnements et les tests de build dépendent de votre produit et de votre organisation, les principes généraux suivants vous aideront à mettre en place votre processus de livraison continue :

• Commencer par la CI : l'implémentation de l'intégration continue avant la livraison continue est préférable dans la majorité des cas. Dans la mesure où la CI affecte principalement l'équipe de développement, cela vous permet de vous familiariser avec le processus de création, de test et de déploiement avant de faire intervenir des tiers.
• Concevoir votre processus de CD pour obtenir des retours rapides : l'identification des problèmes en amont rend votre processus de développement plus efficace. Certaines phases peuvent s'exécuter en parallèle, telles que les tests d'interface utilisateur automatisés pour différentes plateformes. De même, les tests de performances plus longs ou gourmands en ressources peuvent être repoussés jusqu'à ce que le build franchisse les étapes précédentes.
• Impliquer les parties prenantes : DevOps, la philosophie qui sous-tend le CI/CD encourage les équipes de développement à s'affranchir des silos et à considérer l'ensemble du processus de développement logiciel. Lorsque vous préparez votre pipeline de CD, impliquez tous les intervenants du processus de version actuel, des opérations et de la sécurité au marketing et à l'assistance.
• Automatiser vos tests : les tests automatisés constituent un aspect essentiel de la livraison continue, car ils permettent d'avoir rapidement l'assurance que votre logiciel se comporte comme prévu. Si vous n'avez pas de tests automatisés, donnez la priorité aux zones qui ont le plus d'impact et mettez en place la couverture de test de façon incrémentale.
• Réutiliser le même artefact de build : afin de ne pas introduire d'incohérences, déployez le même artefact de build à partir de la phase de CI dans chaque environnement de préproduction et de production.
• Actualiser les environnements de test automatiquement : dans l'idéal, les environnements de test doivent être actualisés pour chaque nouveau build de votre processus de CI/CD. L'utilisation de conteneurs et une approche d'infrastructure en tant que code permettent de créer ou supprimer des environnements en fonction des besoins.
• Prendre en compte les besoins des parties prenantes : les environnements de préproduction utilisés par les équipes d'assistance, de vente ou marketing pour se familiariser avec les nouvelles fonctionnalités constituent une exception au point précédent. Ces équipes peuvent préférer la mise à jour des environnements à la demande pour ne pas perturber le travail en cours.
• Adopter DevSecOps : 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. Adoptez une approche DevSecOps et intégrez la sécurité dans votre pipeline dès le début.
• Prendre en compte les exigences de test manuel : selon votre activité, vous pouvez incorporer certains tests exploratoires manuels pour identifier plus facilement les modes d'échec imprévus. Au lieu d'imposer des tests manuels pour chaque changement de code, vous pouvez prévoir des étapes facultatives ou des pipelines distincts qui s'exécutent de façon hebdomadaire ou mensuelle.
• Automatiser la publication : la livraison continue implique une décision manuelle de mise en production, mais la publication, quant à elle, doit être automatisée. Vous devriez être capable de déployer n'importe quel build valide d'une simple commande.

La livraison continue permet aux équipes de publier leurs logiciels plus rapidement et plus fréquemment tout en réduisant le nombre de bugs qui arrivent en production. Pour y parvenir, il est essentiel de s'assurer que le code est constamment prêt pour la publication au moyen de tests continus de vos modifications et en traitant les problèmes dès qu'ils apparaissent.

Mais ce n'est pas tout, la livraison continue offre de nombreux autres avantages :

• Une publication plus rapide accélère la commercialisation et permet de fournir les nouvelles fonctionnalités, les correctifs et les améliorations plus rapidement.
• Le processus de test continu permet d'obtenir des retours rapides sur votre travail. Si une modification récente introduit une vulnérabilité, bloque votre application dans certains cas ou fait échouer un appel d'API, vous le saurez bien plus rapidement qu'avec le processus traditionnel de test de publication.
• La découverte en amont des problèmes crée les conditions d'un processus de développement plus efficace. Non seulement les modifications sont encore à l'esprit, mais il y a moins de risques que d'autres modifications du code viennent s'ajouter au code défectueux.
• L'automatisation des tâches répétitives de build, de test et de publication permet de s'assurer qu'elles sont réalisées de façon cohérente et réduit le risque d'erreurs tout en permettant aux membres de l'équipe de se concentrer sur les tâches à valeur ajoutée.
• L'investissement dans des tests automatisés vous permet de tester votre logiciel de façon plus poussée. Cela peut inclure des tests identiques sur plusieurs plateformes, la vérification des critères d'accessibilité ou l'établissement d'une base de référence pour les performances de votre produit ou service.
• L'actualisation automatique des environnements et le déploiement des builds vous permettent d'utiliser l'infrastructure plus efficacement, que ce soit sur les serveurs sur site ou dans une ferme de builds hébergée sur le cloud.
• Les déploiements automatiques sur des sites de préproduction permettent de s'assurer que les équipes produit, marketing et assistance disposent d'un aperçu des nouvelles fonctionnalités sans effort supplémentaire de la part des équipes de développement ou des opérations.
• La livraison continue rend votre processus de publication plus robuste et répétable tout en vous donnant le contrôle sur le moment exact de la publication. En mettant en place un processus de CD, vous pouvez fournir de petites améliorations de façon hebdomadaire, quotidienne, voire horaire.

L'implémentation d'un processus de livraison continue peut s'accompagner de plusieurs défis :

• Coopération entre les équipes : vous aurez probablement besoin de la coopération de plusieurs parties de votre organisation, notamment les équipes opérations, infrastructure et sécurité. Si l'élimination des silos peut sembler difficile à court terme, elle débouche sur une meilleure collaboration et davantage d'efficacité à long terme.
• Savoir prendre le temps : l'automatisation de vos processus de build, de test et de publication prend du temps. L'adoption d'une approche itérative et le développement de votre processus au fil du temps rend cela plus facilement gérable. La collecte de mesures, telles que les taux de défaut et les temps de création de build, puis leur comparaison à des procédures manuelles est un moyen efficace de démontrer le retour sur investissement aux différents intervenants.
• Défis de mise à l’échelle : à mesure que vous étendez votre processus de livraison continue, vous devrez probablement exécuter plusieurs builds et tests en parallèle. À ce stade, le nombre de serveurs disponibles peut devenir un facteur limitant. Une fois que vous aurez optimisé les performances de votre pipeline, il pourra être utile de passer à une infrastructure basée sur le cloud pour faire évoluer votre ferme de builds en fonction des besoins.

La mise en place d'un processus de livraison continue peut paraître complexe, mais lorsqu'elle est réalisée correctement, elle permet d'accélérer radicalement les publications des logiciels tout en minimisant les bugs.

L'approche DevOps est au cœur de l'implémentation efficace de la livraison continue. 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 d'une équipe à l'autre, le DevOps favorise la collaboration et un retour d'information rapide à partir de cycles courts et itératifs.

La révision de votre « définition d'un travail terminé » peut vous aider à adopter cette mentalité. Au lieu de considérer la tâche comme terminée lorsque vous faites passer le code à l'étape de test, votre nouvelle fonctionnalité ou changement de code ne peut être considérée comme finale qu'une fois qu'elle entre en production. 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.

Pour plus de conseils afin de se familiariser avec la livraison continue, lisez notre guide de bonnes pratiques de CI/CD.

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. Vous trouverez plus d'informations à ce sujet dans la section suivante de notre guide de CI/CD.

TeamCity est une plateforme de CI/CD qui prend en charge de nombreux outils de build, frameworks de test, conteneurs et fournisseurs d'infrastructure cloud. Que vous souhaitiez héberger vos machines de build sur site, dans le cloud ou utiliser une combinaison des deux, TeamCity coordonne les tâches de build pour une efficacité maximale.

La logique personnalisable de pipeline de TeamCity signifie que vous pouvez choisir quand exécuter les processus en parallèle, tels que des tests sur différentes plateformes, et quand imposer une validation pour passer à la phase suivante. Les notifications configurables vous fournissent les informations nécessaires quel que soit votre lieu de travail, afin de vous aider à éviter les interruptions inutiles. Enfin, les résultats détaillés permettent de s'assurer que la voie suivie pour la production reste claire.