Intégration continue, livraison continue et déploiement continu
Découvrez les différences entre ces pratiques continues
Sten Pittet
Auteur collaborateur
CI et CD sont deux acronymes fréquemment utilisés dans les pratiques modernes de développement et DevOps. CI désigne l'intégration continue, une bonne pratique DevOps fondamentale dans laquelle les développeurs mergent fréquemment les changements de code dans un dépôt central où des builds et des tests automatisés s'exécutent. L'acronyme CD peut, en revanche, désigner la « livraison continue » ou le « déploiement continu ».
Quelles sont les différences entre intégration continue, livraison continue et déploiement continu (CI/CD) ?
Intégration continue
Les développeurs pratiquant l'intégration continue mergent leurs changements dans la branche principale le plus souvent possible. Les changements apportés par le développeur sont validés par la création d'un build et l'exécution de tests automatisés sur celui-ci. Vous évitez ainsi les défis liés à l'intégration susceptibles de se produire lorsque vous attendez le jour de la livraison pour merger vos changements dans la branche de version.
L'intégration continue met l'accent sur l'automatisation des tests pour s'assurer que l'app fonctionne chaque fois que de nouveaux commits sont intégrés à la branche principale.
Livraison continue
La livraison continue est une extension de l'intégration continue, car elle déploie automatiquement tous les changements de code dans un environnement de test et/ou de production après l'étape de build.
Cela signifie qu'en plus des tests automatisés, vous disposez d'un processus de livraison automatisé. De plus, vous pouvez déployer votre app à tout moment en cliquant sur un bouton.
En théorie, grâce à la livraison continue, vous pouvez décider de livrer chaque jour, chaque semaine, deux fois par mois, ou au rythme qui correspond aux exigences de votre entreprise. Cependant, si vous souhaitez vraiment bénéficier des avantages de la livraison continue, vous devriez déployer en production le plus tôt possible pour vous assurer de livrer de petits lots faciles à dépanner en cas de problème.
Découvrir la solution
Développez et exploitez des logiciels grâce à Open DevOps
Ressources connexes
Qu'est-ce que le pipeline DevOps ?
Déploiement continu
Le déploiement continu va plus loin que la livraison continue. Grâce à cette pratique, chaque changement qui franchit toutes les étapes de votre pipeline de production est livré aux clients. Il n'y a pas d'intervention humaine, et seul l'échec d'un test empêchera le déploiement en production d'un nouveau changement.
Le déploiement continu est un excellent moyen d'accélérer la boucle de feedback auprès de vos clients et de réduire la pression sur l'équipe, puisqu'il n'existe plus désormais de « jour de livraison ». Les développeurs peuvent se concentrer sur le développement de logiciels, et voir leur travail lancé en production quelques minutes à peine après donné la touche finale.
Comment ces pratiques sont-elles liées entre elles ?
En d'autres termes, l'intégration continue relève à la fois de la livraison continue et du déploiement continu. D'autre part, le déploiement continu est semblable à la livraison continue, à l'exception du fait que les versions sont créées automatiquement.
Quels sont les avantages de chaque pratique ?
What are the benefits of each practice?
Nous avons expliqué la différence entre l'intégration continue, la livraison continue et le déploiement continu, mais nous n'avons pas encore abordé les raisons pour lesquelles vous devriez les adopter. L'implémentation de chaque pratique a un coût évident, mais ce coût est largement compensé par les avantages qu'elle procure.
Intégration continue
Contraintes (coût)
- Votre équipe devra créer des tests automatisés pour chaque nouvelle fonctionnalité, amélioration ou correction de bug.
- Vous avez besoin d'un serveur d'intégration continue capable de surveiller le dépôt principal et d'exécuter les tests automatiquement pour tous les nouveaux commits pushés.
- Les développeurs doivent merger leurs changements le plus souvent possible, au moins une fois par jour.
Avantages
- Moins de bugs sont livrés en production, car les régressions sont capturées rapidement par les tests automatisés.
- Le développement de la version est simple, car tous les problèmes d'intégration ont été résolus dès le début.
- Réduction du nombre de changements de contexte : les développeurs sont alertés dès qu'ils rencontrent un problème sur le build et peuvent travailler à sa résolution avant de passer à une autre tâche.
- Les coûts des tests sont considérablement réduits : votre serveur de CI peut exécuter des centaines de tests en quelques secondes.
- Votre équipe de QA passe moins de temps à tester et peut se concentrer sur d'importantes améliorations de la culture de la qualité.
Livraison continue
Contraintes (coût)
- Vous avez besoin d'une base solide en intégration continue et votre suite de tests doit couvrir une partie suffisante de votre base de code.
- Les déploiements doivent être automatisés. Le déclencheur est toujours manuel, mais une fois un déploiement lancé, il ne devrait pas y avoir besoin d'intervention humaine.
- Votre équipe devra très probablement adopter des feature flags afin que des fonctionnalités incomplètes n'affectent pas les clients en production.
Avantages
- La complexité du déploiement de logiciels a été supprimée. Votre équipe ne doit plus passer des jours à préparer une livraison.
- Vous pouvez livrer plus fréquemment, ce qui accélère la boucle de feedback avec vos clients.
- Il y a beaucoup moins de pression sur les décisions relatives aux changements mineurs, ce qui favorise une itération plus rapide.
Déploiement continu
Contraintes (coût)
- Votre culture en matière de tests doit être à son plus haut niveau. La qualité de votre suite de tests déterminera la qualité de vos versions.
- Votre processus de documentation devra suivre le rythme des déploiements.
- Les feature flags deviennent une partie intégrante du processus de livraison de changements importants afin de vous assurer la coordination avec d'autres services (support, marketing, relations publiques…).
Avantages
- Vous pouvez développer plus rapidement, car vous n'avez pas besoin d'interrompre le développement pour les livraisons. Les pipelines de déploiements sont déclenchés automatiquement pour chaque changement.
- Les versions sont moins risquées et plus faciles à corriger en cas de problème lorsque vous déployez de petits lots de changements.
- Les clients constatent un flux constant d'améliorations et voient la qualité augmenter au quotidien, plutôt que sur une base mensuelle, trimestrielle ou annuelle.
L'un des coûts traditionnels associés à l'intégration continue est celui de l'installation et de la maintenance d'un serveur de CI. Vous pouvez toutefois réduire considérablement le coût d'adoption de ces pratiques en utilisant un service cloud tel que Bitbucket Pipelines qui ajoute l'automatisation à chaque dépôt Bitbucket. En ajoutant simplement un fichier de configuration à la racine de votre dépôt, vous serez en mesure de créer un pipeline de déploiement continu qui sera exécuté pour chaque nouveau changement pushé vers la branche principale.
De l'intégration continue au déploiement continu
Si vous démarrez sur un nouveau projet sans aucun utilisateur, il peut être facile pour vous de déployer chaque commit en production. Vous pourriez même commencer par automatiser vos déploiements et livrer votre version alpha dans un environnement de production sans clients. Ensuite, vous pourriez intensifier votre culture en matière de tests et veiller à augmenter la couverture de code au fur et à mesure que vous développez votre app. Lorsque vous serez prêt à intégrer les utilisateurs, vous aurez un excellent processus de déploiement continu où tous les nouveaux changements seront testés avant d'être automatiquement livrés en production.
Mais si vous disposez déjà d'une app existante avec des clients, il est préférable d'y aller en douceur et de commencer par l'intégration continue et la livraison continue. Commencez par implémenter des tests d'unités de base dont l'exécution est automatique ; il n'est pas encore nécessaire de vous concentrer sur l'exécution de tests complexes de bout en bout. Essayez plutôt d'automatiser vos déploiements dès que possible et d'atteindre un stade où les déploiements vers vos environnements de staging sont effectués automatiquement. En effet, si vous avez des déploiements automatiques, vous pouvez concentrer votre énergie sur l'amélioration de vos tests au lieu d'interrompre périodiquement votre travail pour coordonner une livraison.
Lorsque vous commencerez à livrer des logiciels de façon quotidienne, vous pourrez vous intéresser au déploiement continu. Assurez-vous cependant que le reste de votre organisation est également prêt. Vos équipes de documentation, de support ou encore marketing devront s'adapter au nouveau rythme de livraison, et il est important qu'elles ne passent pas à côté de changements importants susceptibles d'affecter des clients.
Nos guides
Read our guides
Voici quelques guides détaillés qui vous aideront à mieux appréhender ces pratiques.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Communauté DevOps
Lire le blog
