Nous sommes vendredi, pile juste avant vos vacances, et un commit un peu hasardeux d’un Junior vient de casser l’intégralité du projet. Toute l’équipe est en panique et vous n’avez pas d’autres choix que de rester pour réparer les dégâts, repoussant inévitablement votre départ vers d’autres contrées. En bref, votre cocktail sur la plage semble s’éloigner de plus en plus…

 

Et si je vous disais qu’il existe une solution à tous vos problèmes et bien plus encore. Une méthode permettant d’éviter toutes ces erreurs mais aussi d’alléger votre charge de travail ou bien s’il y en a un, celui de l’intégrateur : Je parle de la « Continuous Integration / Continuous Delivery » ou CI/CD pour les intimes.  
 

D’une manière générale, la CI/CD est surtout un concept reposant sur un objectif simple : être moins prône à l’erreur, faire gagner du temps et produire du code de meilleure qualité, tout en étant le plus souple possible. 

 

 

Qu'est-ce que l'intégration continue ?

 

La CI se caractérise par un ensemble de pratiques visant à vérifier toute modification du code source. Elle peut prendre de nombreuses formes et se doit d’être adaptée à votre besoin. Cela peut aller de simples tests unitaires à des tests automatisés sur cibles et en conditions réelles.

 

L'un des outils les plus utilisés en développement est Git, et par extension souvent Gitlab, et ce pour une raison assez simple : En effet, il met à notre disposition des solutions simples à l’aide de pipelines (https://docs.gitlab.com/ee/ci/pipelines/) pour implémenter sa propre CI/CD que je ne peux que recommander. D’autres alternatives comme Jenkins ou Kubernetes peuvent être également un bon choix et ne relève que de vos préférences personnelles.

 

 

Source : Ultimate guide to CI/CD: Fundamentals to advanced implementation

 

 

 

Source : Create CI/CD Pipeline in GitLab in under 10 mins

 

 

Dans cette CI, on trouvera le plus souvent une première étape de compilation. Elle sera suivie d’une phase de test qui peut être composé des tests suivants, souvent dans cet ordre : 

 

  1. Test unitaires : Ils permettent de tester des bouts de code isolés afin de vérifier leur bon fonctionnement.
  2. Test d’intégration : Ils permettent de tester le code dans son ensemble et de vérifier qu’il répond bien aux besoins et aux exigences. 
  3. Test de régression : Rajoutés à la suite de la correction d’un bogue pour s’assurer qu’il disparaisse pour de bon. 

 

Il n’est pas obligatoire de tous les implémenter et la manière dont ils le sont est également libre du moment qu’ils peuvent être déroulé de manière automatique. 

 

En tant qu’expert en test, vous allez bien évidemment me rappeler que les tests d’intégration se doivent d’être réalisé sur un environnement cible ! Et bien figurez-vous que lors de cette étape de test, il est tout à fait possible de les réaliser dans un environnement simulé à l’aide de votre outil préféré (Docker par exemple). Récupérer et analyser les résultats vous permettra d’éviter toute déconvenue lors du déploiement sur cible. 

 

Les phases de compilation et de test sont la base essentielle de la CI mais d’autres étapes peuvent être rajoutées :

 

  • Vérification de la syntaxe du code (Clang, coverity, Sonar ...) ;
  • Vérification de la syntaxe pour la documentation (Doxygen ...) ;
  • Vérification des commits ;
  • Vérification des titres des merge request ;
  • Test de fuites mémoires ;
  • Vérification du nombre de warning.

 

Cette liste n’est absolument pas exhaustive et il revient à vous de définir vos besoins et de construire votre CI afin de correspondre à vos exigences en termes de qualité et de maintenabilité. 

 

Il est tout de même important de mentionner un des points négatifs de la CI/CD : En effet, toutes ces opérations se déroulent sur un serveur (distant ou local), ce qui prend généralement beaucoup plus de temps que de le faire sur une machine locale. 

 

 

Qu'est-ce que le déploiement continu ?

 

Il nous manque maintenant la seconde partie, à savoir le Développement Continu (CD). Ici, nous nous concentrons surtout sur un mot d’ordre très souvent prisé par les chefs de projet : la flexibilité. Je ne vous parle pas de savoir faire le grand écart au repas de famille pour épater la galerie mais bien de votre capacité à réagir le plus rapidement à toute demande ou à tout imprévu.

 

Reprenons notre pipeline Gitlab, nous allons pouvoir rajouter toute une série d’étapes : une étape de génération de versions ou bien encore de la génération de documents qui permettent de créer des versions de manière régulière ou bien de manière impromptue à la suite d'un besoin, par exemple.

 

Peut-être êtes-vous en train de vous dire que c’est trop beau pour être vrai et qu’il y a forcément un contrecoup. Et bien… Pas vraiment. Le seul inconvénient majeur de cette méthode est le temps qu’il faut prendre en amont pour définir les différentes étapes ainsi que la montée en compétences de l’équipe sur le sujet, sans oublier le coût de l’infrastructure à déployer. Heureusement, cet inconvénient est tout de même largement compensé par tous les avantages suivants : 

  • Gain de temps pour les développeurs : Et oui, cela peut sembler contraire à ce que je viens de dire mais sur des longs projets, le gain de temps est largement supérieur à celui investi. En effet, en plus de gagner du temps sur les livraisons, vous en gagnerez également en diminuant la quantité de bogues détectés en amont ;
  • Robustesse face aux imprévus : Il est facilement possible de générer une nouvelle version pour répondre à un besoin urgent, ou bien rollback assez facilement lorsque cela s'avère nécessaire ;
  • Robustesse face aux changements d’équipes : Il peut arriver que les intervenants changent sur de longs projets. Une bonne CI/CD permet de limiter les problèmes inhérents à ce type d'aléas ;
  • Identification des problèmes en amont : La CI/CD apporte, de manière générale, une meilleure visibilité sur les problèmes qui surviennent pendant un projet ;
  • Réduction de stress : Il arrive souvent que la génération d’une nouvelle version se fasse dans la panique et à la hâte afin que l’équipe / l’intégrateur sous pression puisse s'assurer de respecter les délais. En plus de faciliter le processus, cette méthode en fait l'affaire de l’ensemble des développeurs, plutôt que de se reposer uniquement sur l’intégrateur. 

 

 

Mise à part sur des projets assez courts et où le temps est un élément critique, je ne peux que recommander l’implémentation d’une CI/CD. Certes, cela peut vous prendre un certain temps au début mais n'oubliez pas que la CI/CD pourra être réutilisé pour tous vos projets futurs (y compris les plus petits projets donc) et ainsi améliorer la qualité du travail de manière globale.