Par Gologic en collaboration avec Alexandre Couëdelo.
La différence entre intégration continue, livraison continue et déploiement continu est-elle floue pour vous ?
Combien de fois avez-vous essayé d’expliquer à un collègue les nuances entre ces trois pratiques DevOps pour finir par chercher la réponse sur Google ? Peut-être est-ce justement la raison qui vous fait découvrir cet article.
Chez Gologic, la question nous est très souvent posée, et bien que nous soyons consultants experts DevOps depuis plusieurs années, faire comprendre les différences et les complémentarités entre ces trois étapes cruciales est un bon défi en soi !
Pour vous en souvenir, imaginez une tour faite de cubes en bois. Une tour pour jouer avec une lettre majuscule sur le côté de chaque cube.
Le cube au sommet de cette tour, c’est le déploiement continu, le Saint Graal. Mettre en application le déploiement continu implique que l’ensemble de la chaîne d’assemblage logicielle est automatisée, du développement jusqu’à l’opération en production. Pour ce faire, quatre concepts supportent le déploiement continu.
Chaque concept s’appuie sur le précédent. Un seul bloc mal placé peut fragiliser l’ensemble de la structure, mettant ainsi à risque la qualité et l’efficacité du processus.
Dans cet article, nous allons revoir les définitions d’intégration continue, livraison continue et déploiement continu. Puis, nous allons approfondir chaque notion pour mieux comprendre comment les mettre en place.
Définitions d’intégration, livraison et
déploiement continus
L’intégration continue est la base de la tour. Construire cette base implique de fusionner fréquemment le code des développeurs dans une même branche, compiler le code source et l’emballer sous la forme d’un artéfact.
La livraison continue est le niveau intermédiaire. Le but de cette étape est de décider si un artéfact est prêt pour aller en production. La validation requiert de tester en continu le programme pour s’assurer qu’il respecte les critères de qualité et les attentes du client.
Le déploiement continu est le sommet de la tour. Non seulement vous êtes capable de construire et de valider automatiquement un artéfact, mais surtout l’artéfact est déployé automatiquement en production, sans qu’aucun individu n’ait à cliquer sur un bouton. Le déploiement continu requiert un robuste système de surveillance ; sans quoi vous serez aveugle et incapable de réagir en cas de problème post-déploiement.
Au cœur de l’intégration, la livraison et du
déploiement continus
Maintenant que nous avons défini chacun des concepts de notre pyramide, il est temps de rentrer dans le cœur du sujet. Vous l’aurez compris ; la différence entre les trois concepts réside dans le niveau d’automatisation de votre chaîne de livraison logicielle.
Intégration continue
Tout commence par le code produit par les développeurs. Ce code est automatiquement versionné, compilé puis emballé dans ce que nous appelons un artéfact. L’artéfact contient tous les fichiers nécessaires pour exécuter l’application. Il est souvent accompagné d’évidences, qui retracent les étapes du processus. Par exemple, nous trouvons dans les évidences de la documentation (OpenAPI/Swagger Spécifications), un rapport de tests unitaires, un rapport de couverture de tests et des métriques de qualité.
L’intégration continue commence avec le code source et se termine avec un artéfact.
Livraison continue
L’histoire ne s’arrête pas avec cet artéfact. Maintenant, vous voulez y apposer un sceau prêt pour la production. Il est commun d’appeler l’artéfact à ce stade `release candidate`. Le `release candidate` est déployé dans un environnement de développement afin de subir une série de tests. Si l’artéfact `release candidate` passe l’ensemble des tests, il est promu au rang de `release` et est prêt à être déployé en production.
Attention, le processus de validation d’un artéfact doit être aussi simple que possible afin de déployer souvent en production. C’est pour cela que nous disons que la livraison continue a besoin que vous mettiez en place les tests en continu. Vous avez besoin de construire une série de tests automatisés afin de réduire la quantité de validation manuelle.
La livraison continue commence par une `release candidate` et produit une `release`.
Déploiement continu
Avec une `release` entre les mains, vous pouvez déployer vous-même en production et vous arrêter à la livraison continue. Mais vous pouvez aussi automatiser une étape de plus dans le processus et passez au déploiement continu.
Vous devez sûrement vous dire que c’est simple de déployer automatiquement en production. Mais laissez-nous vous poser cette question : quel est votre niveau de confiance vis-à-vis d’un déploiement automatique ? Êtes-vous certain que le déploiement se déroulera sans embûches ? Comment saurez-vous que tout s’est bien passé si vous n’êtes pas là pour regarder les logs et contre valider le déploiement ?
Déployer en continu, sans intervention humaine demande trois choses :
1) Une confiance élevée dans le processus de livraison continue.
3) Être capable de déployer sans interruption de service.
2) Un système de surveillance réactif qui vous alertera si quelque chose semble anormal.
De plus, il est recommandé d’avoir des stratégies de mitigation des risques afin de limiter l’impact d’un échec. Par exemple : le `rollback` automatisé, le déploiement canari, le `feature toggling`et le déploiement progressif.
Le déploiement continu commence par une `release` et se termine avec un déploiement en production.
En résumé
Nous aimerions que vous vous souveniez de la tour de cubes la prochaine fois que vous pensez à la différence entre intégration continue, livraison continue et déploiement continu. Ce n’est pas tant la différence dont il faut se rappeler, mais comment chaque concept s’appuie l’un sur l’autre pour créer une chaîne de déploiement logicielle entièrement automatisée.
Nous pensons qu’il est également important de se souvenir des entrées/sorties de chaque processus :
- L’intégration continue : transforme du code en artéfact.
- La livraison continue : valide un artéfact (`release candidate`) et le transforme en `release` en utilisant le processus de tests en continu.
- Le déploiement continu : utilise une `release` et l’envoi automatiquement en production. Cela requiert un bon système de surveillance et d’observabilité.
Obtenez des conseils d’experts du DevOps
Vous désirez créer votre chaîne de déploiement logicielle automatisée et accélérer vos livraisons ? Les conseillers DevOps de Gologic peuvent vous aider à mettre en place des pipelines as code, incluant le développement, l’intégration, les tests, la livraison et le déploiement continus (CI/CD). Explorez nos services ou contactez-nous pour en apprendre davantage sur notre approche stratégique.
Par Gologic en collaboration avec Alexandre Couëdelo.
