L’intégration Continue

Xavier, membre de la communauté de blogueurs JobProd, nous parle de l’intégration continue : qu’est ce que c’est ? pourquoi et comment l’utiliser ?

Pourquoi ?

De nos jours, la tendance des méthodes de production est aux cycles courts : développer rapidement un petit nombre de nouvelles fonctionnalités, échanger avec le client et recommencer. Cela demande d’être plus réactif sur les potentielles erreurs de code.

La taille d’un projet pouvant rapidement atteindre la dizaine, voire la centaine de milliers de lignes de code, difficile de tout vérifier à la main, même en mettant en place des revues de code. L’intégration continue permet d’avoir une observation neutre et automatisée de la base de code d’un projet, et d’être notifié lorsqu’un problème apparaît.

Il existe plusieurs systèmes d’intégration continue, installable sur un serveur dédié (Jenkins) ou fournissant un serveur mutualisé (Travis qui offre une intégration avec Github, Bamboo).

Intégration Continue

Le premier principe de l’intégration continue est la compilation automatique et instantanée du code. Dès que le serveur détecte un changement dans la base de code (via Git, SVN, Mercurial ou autre), il récupère les modifications et compile automatiquement le projet.

Le résultat de la compilation est ensuite archivé, et le cas échéant un mail peut être envoyé au développeur pour corriger un éventuel problème.
Cela permet dans un premier temps de s’assurer que le code compile correctement, qu’aucun fichier ne manque, et que les paramètres de compilation sont corrects.

Test Unitaires

Que l’on travaille en TDD (Test Driven Development) ou pas, les projets ont souvent des tests unitaires, ou des tests d’automation existants. Ces tests permettent de vérifier que le code exécuté produit bien le résultat attendu. En effet, tous les programmeurs savent qu’un code qui compile n’est pas un code parfait, loin s’en faut.

Lorsqu’un serveur d’intégration continu est déjà mis en place, il est possible de lui faire exécuter les tests unitaires (une fois par jour suffit). Cela permet de s’assurer que l’existant n’est pas cassé lorsque l’on ajoute de nouvelles fonctionnalités.

En outre, nombre de systèmes permettent, à partir des tests unitaires, de savoir quelles parties du code ont été testées, et quelles parties ne l’ont pas été, ce que l’on appelle Code Coverage. Plus la couverture est importante, plus on peut avoir confiance dans le code écrit.

Analyse statique

En plus des tests unitaires, qui vérifient le code au moment de l’exécution, il est également possible de vérifier le code source lui même à l’aide d’outils d’analyse statique. Ces outils parcourent le code à la recherche de sources potentielles d’erreurs. Selon les langages et les outils, il est également possible de paramétrer des règles de codage (où sont placés les accolades, les espaces, comment doivent être nommées les variables et les méthodes, …).

Cette analyse permet de garder une cohérence sur la forme du code (ce qui peut s’avérer délicat quand le nombre de développeurs augmente), mais également de détecter des sources d’erreurs potentielles. Duplication de code, accès concurrents, valeur non utilisée, tout est passé au crible régulièrement pour éviter les bugs avant qu’ils n’arrivent.

Déploiement, Packaging, et plus si affinités…

Le grand avantage de ce système est qu’il permet également d’automatiser des tâches lorsque la compilation est réussie et que les test unitaires et l’analyse statique ne révèlent pas d’erreurs bloquantes. Il est alors possible de générer un artefact (paquet applicatif, archive, installeur, …) ou même de déployer l’application (sur un serveur, un store d’application mobile) automatiquement.

En outre il est possible d’effectuer bien d’autres opérations, comme par exemple permettre à l’équipe de test de générer des versions spécifiques du code pour tester l’une ou l’autre fonctionnalité.

En résumé

Les serveurs d’intégration continue sont des outils extrêmement flexibles permettant à chacun d’y trouver son compte. Les développeurs y verront un moyen de détecter les bugs avant qu’ils n’apparaissent, les managers apprécieront les graphiques évaluant la “qualité du code” (à prendre avec des pincettes tout de même), et les testeurs y verront un outil permettant d’automatiser les tests les plus simples.

Xavier Gouchet (@xgouchet)

Tout comme Xavier, vous êtes un passionné de développement ?
Alors, que vous soyez simplement curieux de rencontrer des entreprises très techniques et humaines, ou à la recherche de belles opportunités, nous vous invitons à cliquer ci-dessous !

Xavier
Geek, Android-ophile, curieux de nature et aimant partager mes connaissances, je baigne dans le monde de la programmation depuis un bon moment, et aujourd’hui je suis principalement porté sur les technologies mobiles, et principalement Android.

J’apprécie autant découvrir de nouvelles techniques, développer des bouts de codes pour générer des images, échanger sur divers sujets techniques, que partager mes connaissances par quelque moyen que ce soit.
Aujourd’hui, je passe mon temps entre Deezer, où je fais partie de l’équipe Android, mes propres applications Android Open Sources, et mes trajets quotidiens en train, entre ma campagne percheronne et Paris.
En savoir +

Vous souhaitez devenir blogueur pour JobProd ?