L’approche CI/CD, c’est quoi au juste ?

Amazon, Facebook, TripAdvisor, Netflix… Tous ces sites sont mis à jour en permanence, souvent même plusieurs fois par jour, avec la contribution d’innombrables développeurs. Le résultat de telles modifications est intégré très rapidement sans que l’internaute n’en ait conscience. À une échelle plus habituelle, les applications déployées et mises à jour dans les entreprises sont le fruit de nombreux développeurs dont la production est coordonnée comme il se doit.

Comment parvient-on à coordonner ainsi les apports de tant de contributeurs ? Grâce à une démarche qui aide à accélérer le déploiement effectif d’applications. Elle consiste en une série d’étapes regroupées sous l’appellation CI/CD (Continuous Integration/Continuous Deployment, ou intégration continue/déploiemement continu en français).

Une petite métaphore

Pour mieux se représenter comment fonctionne CI/CD, tentons un parallèle avec le monde réel. Imaginons la construction d’un vaste hôtel dans un quartier touristique fort concurrentiel, nécessitant que le service client soit à tout moment optimal. Certaines tâches vont être attribuées aux décorateurs, d’autres aux responsables de la plomberie, d’autres aux électriciens…

Lorsqu’une chambre est achevée, il importe qu’elle puisse être opérationnelle au plus vite. Si la coordination n’a pas été effectuée comme il se doit, le mobilier de salle de bains ne va pas correspondre aux installations de plomberie, le logiciel de gestion de l’ouverture des portes est incompatible avec Apple Pay, etc.

Imaginons à présent que la construction ait été gérée en mode CI/CD. Tous les points nécessitant une coordination ont été élaborés en amont. Le CI assure que chaque fois qu’un élément est ajouté, un robot va tester son adéquation avec l’ensemble. Puis, dès lors qu’il apparaît qu’une chambre est fonctionnelle, le CD se charge de faire en sorte qu’elle puisse être occupée.

Par la suite, les touristes qui occupent l’hôtel vont faire remonter des remarques et celles-ci vont être prises en compte, par exemple, la nécessité de modifier la décoration de certaines chambres. Une phase de CI va alors redémarrer et suivre le même parcours jusqu’au CD.

La construction, comme la maintenance d’un grand hôtel, fait intervenir de nombreux corps de métiers dont les actions doivent être coordonnées à tout moment. Le CI/CD fonctionne sur une même logique visant à optimiser les développements d’applications à grande échelle. © D. Ichbiah via Dall.e 3.

Les affres du développement en silo

Revenons au monde de l’informatique. La taille de nombreuses applications actuelles, qu’il s’agisse de sites Web, de jeux vidéo ou de gestion d’un parc d’outils en location, implique de faire travailler de nombreux développeurs en simultané. Certains peuvent être présents dans l’entreprise et d’autres intervenir à distance.

Traditionnellement, le souci s’est posé dès lors qu’il fallait intégrer ces divers apports en un même programme. Il s’avérait alors que le module de calcul de la TVA développé par Jane, par exemple, n’était pas adapté à l’interface de paiement en ligne créée par Benjamin. Ajuster ces multiples apports créés de manière isolée (l’expression couramment employée était « développés en silo ») pouvait représenter un infernal casse-tête.

Le développement en silo s’apparente à l’édification d’un bâtiment par des intervenants isolés sans aucune coordination, qui aboutirait à une construction inexploitable. © D. Ichbiah via Dall.e 3 et Krea.ai

Le manifeste pour un développement agile

En février 2001, 17 grands experts du développement se sont réunis à Snowbird, une ville située dans l’ouest des États-Unis, afin d’évoquer cette situation et de la résoudre. Le fruit de leurs réflexions a abouti à un document Le Manifeste pour un développement de logiciel agile. Plusieurs principes ont été posés :

• rendre le développement flexible ;
• optimiser la collaboration entre les développeurs ;
• faciliter les changements rapides dans le code ;
• pouvoir opérer des tests en automatique sur ledit code.

Ce manifeste a entraîné l’essor du DevOps, soit une ingénierie visant à unifier le développement de logiciels. Et au sein du DevOps sont apparues diverses solutions de CI/CD...

Ward Cunningham, l’inventeur des Wiki, figure parmi les 17 experts du développement qui ont défini en 2001 le « Manifesto for Agile Software Development », visant à définir des méthodologies optimisées pour la création d’applications. © Carrigg Photography pour la Wikimedia Foundation

Le principe du CI ou intégration continue

CI est traduit par « intégration continue ». Son principe est le suivant : chaque fois qu’un changement intervient dans un projet informatique, il faut qu’il puisse être automatiquement testé afin de vérifier qu’il fonctionne élégamment avec l’intégralité de l’application.

Pour ce faire, une application est décomposée en un grand nombre de micro-services lesquels peuvent être développés et mis au point indépendamment, mais tout en respectant une série de règles qui vont assurer leur coordination.

À partir de là, de nombreux développeurs opèrent simultanément sur différentes fonctions d'une même application.

Un dépôt central

Avec l’intégration continue, à tout moment, les développeurs vont se servir d’un outil de SCM (source code management ou gestion de code source, en français) tel que Gitlab pour placer le code source qu’ils ont développé vers un dépôt central : le dépôt SCM.

Depuis le dépôt SCM, le nouveau code source est acheminé à un serveur d’intégration où il va être compilé (traduit en langage machine), puis fusionné à l’application globale ; suite à quoi, une série de tests sont effectués en automatique par un service tel que Jenkins afin de vérifier qu’aucune anomalie ne puisse être introduite dans le système existant.

Si tout se passe bien, le code validé est archivé dans un Repository (dépôt). En revanche, si des problèmes sont détectés, le développeur doit alors revoir sa copie.

Avec le CI, le code source ajouté ou mis à jour par un développeur est envoyé à un dépôt central à partir duquel une série de tests rigoureux pourront être menés en automatique. © D. Ichbiah via Stable Diffusion XL & Krea.ai.

CD ou distribution continue

Une fois que l’étape du CI s’est déroulée de façon réussie, le nouveau « build » (la nouvelle version) de l’application peut normalement être mise en service. Ainsi, s’il s’agit d’un site Web, une nouvelle version peut être proposée aux internautes. Cette étape s’intitule CD ou distribution/déploiement continu. Pourtant, le déploiement effectif n’est pas immédiat. Le CD démarre par une nouvelle série de tests :

• des tests automatisés dit de « recette », par exemple un outil tel que Selenium Webdriver aide à tester la conformité d’un site sur divers navigateurs ;
• des tests de qualité ;
• des tests de performance afin de vérifier que les mises à jour de l’application ne dégradent pas les temps d’accès.

Le nouveau « build » est ainsi soumis à une série de scénarios à même de tester divers types d’usage et vérifier que cette mouture va répondre aux plus hautes exigences. Si le « build » a franchi avec succès toutes ces étapes, il est alors déployé de manière effective.

Selenium Webdriver teste la conformité d’un site Web sur les principaux navigateurs Web. © Browserstack

Une efficacité décuplée

Nous l’avons vu plus haut, CI/CD est une partie intégrante du DevOps, soit une façon de travailler de manière collaborative dans le développement de logiciels. Cette position de chef d’orchestre est devenue cruciale, et elle est fort recherchée, ce qui explique pourquoi tant d’informaticiens peuvent souhaiter se spécialiser dans le DevOps. Retenons que le CI/CD a permis d'augmenter très fortement la fréquence de déploiement des applications grâce à ces divers systèmes de tests automatisés. À l'aide de ces outils liés à cette approche, une modification apportée par un développeur peut devenir effective très rapidement, parfois au bout de quelques minutes !