Intégration vs. livraison vs. déploiement continus

Commençons par examiner les principales caractéristiques de la CI et du CD, ainsi que leurs différences.

L'intégration continue (CI)

L'intégration continue (CI) consiste à vérifier automatiquement les modifications de votre code pour obtenir un retour rapide sur votre travail. Avec la CI, chaque fois que vous validez une modification, votre serveur de CI exécute un build et lance des tests automatisés. Ces tests incluent généralement des tests unitaires, des tests d'intégration et d'autres contrôles tels que le linting ou l'analyse statique. Si une étape du processus de CI échoue, vous êtes automatiquement notifié afin de pouvoir résoudre le problème. Le processus recommence lorsque vous validez un correctif.

Livraison continue vs. déploiement continu

La différence entre la livraison continue et le déploiement continu réside dans la dernière étape de la mise en production.

Dans le cadre de la livraison continue, la mise en production de l'artefact de build nécessite une intervention manuelle. Le processus de publication est généralement entièrement automatisé, mais quelqu'un doit décider si et quand un build particulier sera publié. En revanche, avec le déploiement continu, le build passe automatiquement en production à chaque fois que vous avez terminé les étapes précédentes du processus.

Choisir entre la livraison continue et le déploiement continu

Pour déterminer si la livraison continue ou le déploiement continu est plus approprié, vous devez prendre en compte votre contexte.

Pour les produits logiciels tels que des applications mobiles ou des API, publier une nouvelle version pour chaque commit réussi n'est peut-être pas idéal. Vous préférerez peut-être publier selon un calendrier planifié ou attendre d'avoir un nombre minimum de modifications prêtes à être déployées.

Dans ce cas, vous pouvez utiliser la livraison continue pour vérifier les modifications au fur et à mesure et prévisualiser les versions dans un environnement de pré-production. La livraison continue peut également offrir la possibilité de réaliser des tests d'acceptation manuels avant chaque publication.

Le déploiement continu, lui, fonctionne bien pour les applications et services web, pour lesquels des mises à jour fréquentes (tous les jours voire toutes les heures) sont la norme.

Le déploiement continu vous permet de diffuser des mises à jour au compte-goutte et d'obtenir rapidement des retours d'expérience. Vous pouvez également utiliser le déploiement continu pour mener des expériences et valider des hypothèses avec des utilisateurs réels, sachant que vous pourrez changer rapidement de direction avec une nouvelle version si nécessaire.

Enfin, il est important de noter que vous pouvez intégrer des tests manuels d'acceptation et exploratoires dans un processus de déploiement continu.

Au lieu d'exiger des vérifications manuelles avant chaque version, vous pouvez déployer périodiquement des modifications dans un environnement de staging et mener ces tests selon un cycle hebdomadaire (ou plus long).

En attendant, les modifications qui réussissent tous les contrôles automatisés peuvent continuer à passer en production. Si vous découvrez un problème en staging, votre pipeline automatisé vous permet de déployer rapidement un correctif en production.

Le CI/CD représente deux étapes du processus de build, de test et de publication d'un logiciel.

Un pipeline de CI/CD est un outil qui vous permet d'établir une confiance croissante dans votre code.

Chaque étape réussie renforce votre confiance jusqu'à ce que vous soyez prêt à publier le code pour les utilisateurs. Si toutefois une étape échoue, vous arrêtez le processus de build et devez corriger le bug ou annuler les modifications. Après cette résolution, le processus redémarre au début.

En tant que première phase du processus de build, de test et de publication, la CI se concentre sur une rétroaction rapide via des vérifications. Un retour rapide sur les modifications apportées à votre code vous aide à travailler plus efficacement en réduisant le besoin de changer de contexte. Au lieu d'attendre des heures ou des jours pour obtenir les résultats des tests manuels, vous recevez des alertes en quelques minutes sur tout problème introduit par vos modifications.

Si le build contenant vos modifications réussit les tests de CI, vous pouvez alors le déployer dans des environnements de pré-production. À ce stade, vous pouvez mener des tests plus longs et plus gourmands en ressources.

L'automatisation d'autant d'étapes de CD que possible raccourcit encore la boucle de rétroaction et permet un workflow plus efficace. En plus d'automatiser les tests, par exemple, vous pouvez actualiser les environnements de pré-production et y déployer automatiquement des builds.

Si vous débutez en CI/CD, au lieu de vous focaliser sur le choix entre l'intégration continue et la livraison continue ou le déploiement continu, nous vous suggérons de déterminer plutôt par où commencer et jusqu'où vous voulez aller.

CI et CD impliquent tous deux plusieurs étapes, ce qui signifie que vous pouvez développer vos processus progressivement.

Trouver votre point de départ

Si vous avez déjà automatisé certaines parties de votre processus de build ou de publication, ou si vous avez écrit des tests automatisés, ceux-ci peuvent constituer un point de départ naturel. Dans le cas contraire, commencez par déterminer quelles parties de votre processus de build, de test et de publication prennent le plus de temps ou risquent le plus d'entraîner des problèmes en production en raison de tests inadéquats.

De nombreuses équipes choisissent de commencer par la CI car cela nécessite moins de coordination avec d'autres parties de l'organisation, et les retours rapides des tests unitaires et d'intégration automatisés contribuent à améliorer la qualité du code.

De plus, reconnaître les avantages de l'intégration continue favorise une culture de tests automatisés, qui est essentielle pour un CI/CD efficace et encourage à étendre la couverture des tests automatisés.

D'un autre côté, si actuellement vous gérez à la fois la coordination des versions et le développement du code, automatiser d'abord la dernière étape du CD (la mise en production) peut vous faire gagner du temps sur le long terme.

Bien que la CI fournisse une base solide pour le CD, le choix entre la livraison continue et le déploiement continu dépend de vos besoins. Même si votre objectif à long terme est le déploiement continu, une stratégie courante consiste à commencer par la livraison continue. Une fois que vous avez confiance dans vos workflows, vous pouvez passer à l'automatisation de la mise en production finale.

Améliorer vos processus de CI/CD

CI et CD fonctionnent mieux lorsque vous divisez les tâches de développement en livrables de taille réduite et que vous validez régulièrement vos modifications.

Si votre objectif est le déploiement continu, vous devez réfléchir à la manière de gérer les fonctionnalités qui ne sont pas encore prêtes à être publiées, même si des modifications ont été validées pour elles. Vous pouvez y parvenir en utilisant des indicateurs de fonctionnalités ou une stratégie de branches qui isole les travaux en cours de la branche de publication tout en vous garantissant de générer et tester automatiquement chaque modification de code.

Pour récapituler :

• L'intégration continue (CI) implique d'exécuter des tests automatisés et de vérifier que votre solution peut créer un build à chaque commit de modification.
• La livraison continue et le déploiement continu (CD) impliquent le déploiement automatique d'artefacts de build dans des environnements de test et de staging pour exécuter d'autres tests. Vous effectuez généralement ces étapes après l'intégration continue.
  • Dans le cadre de la livraison continue, vous décidez quand publier un artefact de build particulier en production et lancez la publication manuellement.
  • Dans le cadre d'un déploiement continu, chaque modification de code qui réussit les étapes précédentes est automatiquement mise en production.
• CI et CD sont des pratiques complémentaires conçues pour identifier rapidement les problèmes et vous donner confiance dans vos modifications avant de les publier.
• Un processus de CI/CD robuste doté de tests automatisés vous permet de déployer des correctifs plus rapidement et avec plus d'assurance en cas de bugs en production.
• Un processus de build, de test et de publication entièrement automatisé se compose à la fois de CI et de CD, mais vous pouvez commencer par l'une ou l'autre et créer votre processus progressivement.
  • De nombreuses équipes commencent par l'intégration continue, car les tests automatisés relèvent généralement de la responsabilité des développeurs.
  • Toutefois, si vous êtes également responsable de la gestion des versions, les automatiser en premier peut vous aider à gagner du temps afin de pouvoir vous concentrer sur la création de votre processus de CI.