Naissance et évolutions des CI/CD

Introduction

Les termes CI et CD sont en ce moment des notions connues de tous, ou au moins tous le monde dans le domaine de l’IT, en a entendu parler. Il s’agit de termes anglophones qui signifient :

  • CI pour Continuous Integration, ou Intégration Continue
  • CD pour Continuous Delivery, ou Déploiement Continue

Ce sont des pratiques informatiques mises en place dans le cadre du développement de logiciels. Cela vise à rendre leur développement, ainsi que leur mise à disposition plus fluide, plus sûre (moins de bugs), plus reproductible et moins chronophages !

Le principe est le plus souvent de reconstruire le logiciel pour pouvoir détecter les bugs au plus tôt. Pour arriver à cela, les développeurs sont encouragés à contribuer par petit bout de choses simples, et non pas une énorme modification en profondeur du logiciel. Chaque petit ajout provoque une reconstruction du logiciel, et lorsqu’un bug est détecté, la cause est plus facilement localisée à une petite modification.

Mais l’histoire des CI/CD remonte bien plus loin qu’on ne le pense !

Des générations d’administrateurs systèmes et de développeurs ont dû faire face à des tâches fastidieuses avant d’aboutir aux outils actuels et aux grands domaines connexes que sont l’automatisation et les workflows.

Historique

Nous sommes en 1982 (neuf ans avant la création de Linux). À cette époque, les systèmes informatiques professionnels fonctionnent sous Unix (famille dont Linux est issu), IBM System/360 ou 370, ou encore VMS. L’écosystème des développeurs dispose déjà d’outils de gestion de versions, notamment SCCS (Source Code Control System) [1], en usage depuis dix ans. Sous VMS, la suite VAXset [2] constitue un ensemble d’outils de développement avancé, incluant gestion de versions, tests, compilation et édition de code : on parle déjà d’un IDE complet en 1982 !

En 1989, une équipe de chercheurs de l’Université Columbia et des laboratoires AT&T Bell publie « Infuse: Fusing Integration Test Management with Change Management » [3]. Ce document présente un système de tests permettant de valider les composants d’un logiciel. Il s’agit d’une des premières automatisations modulaires publiques liant gestion des versions, tests et livraisons. Nous sommes déjà proches du concept de CI/CD !

Cependant, ces idées ne se généralisent pas immédiatement. Pendant une dizaine d’années, peu de systèmes adoptent ces pratiques. Ce n’est qu’en 1997 que l’eXtreme Programming (également connu sous le nom de XP) émerge, introduisant le travail en binôme pour développer et tester le logiciel en échangeant continuellement entre les membres de l’équipe.

L’année 2001 marque un tournant :

●      La méthode Agile est formalisée avec The Manifesto for Agile Software Development [4].

●      Le logiciel CruiseControl [5] est publié : il permet de visualiser l’exécution des tâches et des tests automatisés, préfigurant des outils comme Jenkins ou GitLab CI/CD.

●      Watir [6] est lancé pour automatiser les tests web en pilotant Internet Explorer. Il deviendra plus tard Selenium !

Ces avancées vont populariser les pratiques de CI/CD, inspirant le développement de nombreux autres outils. Parmi eux : Hudson [7] en 2005, qui évoluera en Jenkins.

En parallèle, le terme DevOps commence à se déployer. En 2009, les DevOpsDays sont organisés, officialisant cette approche dans des conférences internationales.

L’étape suivante se produit en 2010, avec l’introduction de la notion de Continuous Delivery, citée dans le livre Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation de Jez Humble et David Farley [8].

Et dans le commun des mortels ?

Les bases de l’agilité et les CI ne sont pas arrivées du jour au lendemain dans le monde de l’entreprise.

En 2000, en tant que développeur, je devais encore réaliser des tests et des livraisons à la main, sur CD-ROM !

En 2005, en tant qu’administrateur systèmes, les déploiements automatisés étaient encore rudimentaires. J’utilisais cron (un ordonnanceur de tâches), un fichier déclencheur, et rsync pour synchroniser les fichiers entre environnements (préproduction, production). Nous avions également une interface web faite maison pour faciliter ces opérations.

Nous nous servions aussi de Sitescope pour effectuer des benchmarks avec des scénarios. Cela avait 2 buts : la validation de performance mais aussi la validation d’un parcours simple d’un site web qui avait valeur de test, avant livraison en production. Quant aux développeurs, ils faisaient leurs tests sur leurs postes et avaient même accès à la production via ssh. Le devops était d’une certaine façon plus agile qu’aujourd’hui, car ils avaient des accès (mais limités) en production. Cela permettait d’être plus réactifs dans la résolution de problèmes, mais aussi de mettre en place des mécanismes simples et robustes. D’autres confrères avaient des solutions de CI faites à la main, mais leur sociétés étaient plus importantes en ressources.

Dès 2001, certains outils de tests étaient déjà disponibles, notamment Expect et DejaGnu [9]. L’adoption progressive des pratiques de CI/CD s’est poursuivie dans les entreprises, jusqu’à leur reconnaissance massive durant la décennie 2010.

Et maintenant ?

Ainsi va la conclusion

alors que nous compilions

Un ensemble de sources

pas pour la frousse

un ./configure et DESTDIR=./pkg make install une fois,

une différence (une erreur) deux fois.

l’idempotence n’était pas dans la mouvance

l’IA en présence

les tests unitaire

restent à faire !

 Article écrit par Kilian Hart

Annexes

Par rapport aux éléments de la chronologie: