L’intégration continue et le déploiement continu: c’est quoi ?

Photo de Angely Acevedo sur Unsplash

L’intégration continue (Continuous Integration - CI en anglais) et le déploiement continu (Continuous Deployment - CD en anglais) sont deux concepts au coeur de beaucoup de projets logiciels.

C’est quoi l’intégration continue ?

L’intégration continue est un ensemble de pratiques dédiées à vérifier que les nouvelles fonctionnalités qu’on intègre à une application ne “cassent rien”.

Prenons un petit exemple !

Bob et Alice sont tous les deux dev sur un site e-commerce.

Bob est sur une fonctionnalité de “Wishlist” tandis qu’Alice implémente un paiement par Paypal.

Ces deux fonctionnalités seront intégrées au projet du site e-commerce. Même si on ajoute un nouveau mode de paiement “Paypal”, on veut pouvoir continuer à payer par carte bleue si on le souhaite sans supprimer cette fonctionnalité.

C’est la raison d’être de l’intégration continue.

Cela se manifeste via l’utilisation d’un outil de versionning (comme Git), l’exécution de tests unitaires, de tests fonctionnels et de tests e2e selon ce qui est mis en place dans le projet.

Ce fonctionnement par branches varie selon les équipes (vous entendez parler de git flow ou de trunk based development), mais ce qui est sûr c’est qu’on ne commit jamais tous en même temps sur la branche principale main 😅

C’est quoi le déploiement continu ?

Le déploiement continu est une stratégie où tout nouveau code envoyé sur un outil de versionning (comme Git) est automatiquement envoyé sur un environnement.

Cette stratégie se met en place via des outils et des scripts qui s’exécutent automatiquement à chaque fois qu’un commit est envoyé en production.

Selon l’organisation de l’équipe, les stratégies de déploiement peuvent différer.

Une stratégie classique est d’avoir la branche main déployée systématiquement sur l’environnement de production (l’environnement accessible au public qui utilise l’application!)

Exemples d’outils

Il existe une multitude d’outils de déploiement continu sur le marché. Je ne vais parler dans cet article que de deux solutions que j’ai particulièrement utilisé récemment, CircleCI et Github Actions.

Les deux solutions permettent d’exécuter des scripts (permettant de déployer / exécuter des tests…) lorsque de nouveaux commits sont faits sur une ou plusieurs branches Git (en se connectant à un repository distant Github, Bitbucket, Gitlab…).

Les règles de déclenchement de ces jobs sont paramètrables sur le fichier de workflow (qui définit et décrit en détail les jobs à exécuter).

CircleCI

👵🏼 J’ai travaillé avec CircleCI entre 2018 et 2022. Mes retours sur cette solution se basent essentiellement sur cette expérience, il est possible que la solution ait évolué depuis !

J’ai apprécié travailler avec CircleCI. Il y a les Orbs, des applications réutilisables sur un workflow Circle.

Une marketplace d’orbs existe avec plein de fonctionnalités (ex: mettre en place des notifications Slack à l’issue d’un job de déploiement)

Je me souviens que le dashboard qui permettait de visualiser les différents déploiements en cours était complètement bugué. L’équipe a été assez réactive et a rollback à peine une heure après l’incident.

Je garde quand même souvenir de nombreux incidents sur CircleCI, ce qui n’indique pas une stabilité de la plateforme (du moins, à l’époque!)

Github Actions

Sorti plus récemment sur le marché, on retrouve sur Github Actions les mêmes possibilités que sur Circle CI (ajout de secrets, variables d’environnement).

Le dashboard qui permet de visualiser l’exécution des tests ou des déploiements par les jobs est peut-être moins user-friendly par rapport à CircleCI (mais c’est très subjectif comme avis 😅)

Un concept similaire aux orbs de CircleCI existe aussi sur Github Actions: les actions sont disponibles sur une marketplace et vous évitent de recoder des fonctionnalités pour des besoins assez classiques (notifications Slack, installation d’outils de code coverage…)

Ce que j’apprécie particulièrement dans Github Actions, c’est le fait d’avoir tout au même endroit: mon code, mes jobs de déploiement, mes tests…

Bilan

Ayant déjà bossé à l’époque dans une équipe qui avait à peine Git en place, je peux vous assurer que c’est un état d’esprit qui permet d’avoir un produit logiciel plus sain et d’être plus en confiance sur le code qu’on produit.

Pour aller plus loin sur le sujet, voici quelques articles que je recommande et qui m’ont été d’ailleurs utiles dans la rédaction de cet article (le blog d’Atlassian est très cool et en français !).

• Cinq conseils pour vos dépôts Git permettant l’intégration continue
• Qu’est-ce que l’intégration continue ?

Les schémas de cet article ont été réalisés avec Excalidraw !