Qu’est ce que l’intégration continue ?

L’intégration continue (ou Continuous Integration, CI) est un processus de développement de logiciels permettant aux développeurs l’assurance d’une qualité produit sur toute la durée du développement d’un logiciel. Autre objectif, celui de permettre la fabrication d’un livrable logiciel, destiné ensuite à la mise en production.

Lors de l’intégration continue, le code source du livrable est soumis à un serveur, appelé usine (ou software Factory). Il effectue régulièrement une batterie de tests, puis confirme ou invalide l’état du logiciel à l’instant T.

Finalement, l’usine peut également, et uniquement dans le cadre du déploiement continu, déclencher elle-même le déploiement d’un logiciel (cf.schéma).

déploiement continu
Schéma Build ➡️ Test ➡️ Package ➡️ Deploy

Un processus particulier à mettre en place

Lors de la mise en place d’une CI, l’équipe doit se plier à l’avis de l’usine avant de mettre en production, signifiant alors qu’il ne faut surtout pas mettre en production si l’usine a invalidé l’état du logiciel. L’usine effectue ainsi ses tests de manière itérative, assurant le suivi sur plusieurs étapes préalablement définies par les Craftsmen. 

⚠️
Si l’une des étapes échoue, le processus doit être arrêté et le build est alors déclaré comme invalide. ​

Il est important de prendre en considération trois conditions à remplir afin de confirmer l’état d’un logiciel, à savoir :

Le Was Built : le code source ne comporte aucune erreur de syntaxe et compile/ s’interprète sans problème.

Le Was Tested : tous les tests automatiques (fonctionnels, d’intégrations, unitaires…) passent et ne présentent aucune erreur d’assertion.

Le Was Packaged : le livrable a été préparé (placé dans un format compréhensible pour l’outil de déploiement), et est prêt pour la livraison.

Des étapes additionnelles s’ajoutent, comme :

Le Code Coverage : un outil d’audit automatique valide la qualité du code et prévient notamment de la présence des codes smell ou des potentielles références nulles.

Nota Bene

L’usine ne devrait pas procéder elle-même à la livraison en production, mais plutôt déclencher un événement à un outil dédié au déploiement. 

Comment choisir son outil et l’utiliser ?

Comme dans tout projet, le choix de l’outil est le clé de la réussite. L’intégration continue ne fait pas défaut à cette règle. Aussi, voici quelques conseils pour vous aider à choisir cet outil et appréhender, voire améliorer, votre utilisation de ce dernier.

Déterminer et choisir votre langage de programmation

Et, si cela peut paraître évident, c’est pourtant crucial. Cet outil doit être à même de supporter le langage mais aussi les frameworks du logiciel développé.

Le déploiement

« Initialement, le but de l’usine n’était que de générer (build) le package qui devait être mis en production. Il fallait développer ses propres scripts pour pouvoir déployer depuis son usine. Une pratique qui
était difficilement maintenable. Or, ça a bien changé. Avec l’apologie du DevOps et de la tendance « Agile », des outils permettant à la fois 
build et déploiement ont fait leur apparition sur
le marché. »
 

Christopher Jamme de Lagoutine

Christopher Jamme de Lagoutine

Crafter

Une mise en production sans douleur, avec deux options: 
  • L’utilisation d’un outil annexe uniquement dédié au déploiement (du style de Octopus Deploy)
  • L’utilisation d’usines qui permettent de déployer le logiciel de manière fluide, et qui disposent directement des outils pour déployer (du style d’Azure DevOps ou de GitLab).
Bannir l’infra as code

Eviter les custom scripts à rallonge qui deviennent impossibles à maintenir pour vos successeurs. Des processus tels que l’infra as code préconisent de développer chaque script de build avec des langages tels que Groovy ou F#.

L’infra as code complique le processus car ce sont généralement des technologies peu maîtrisées par les développeurs. De plus, le script de build est édité très peu de fois lors du cycle de développement. De ce fait, cela prend du temps pour se ré-onboarder sur un outillage de scripts que l’on utilise une fois par an.

Il faut privilégier des solutions de déploiement intégrées afin de faciliter la mise en place du déploiement continu.

Combien d’utilisateurs vont utiliser mon usine en même temps ?

Il faut réfléchir à la manière dont sera échelonnée l’usage de l’usine avant de choisir quel outil utiliser. Cela permet d’éviter la surcharge de la Software Factory, et donc la longueur du build.

Combien d’équipes sont amenées à utiliser l’outil ? Pour combien de projets par équipe ? Combien d’instances du même outil vais-je mettre à disposition des développeurs ? Voici les questions que l’on doit se poser avant de choisir son usine.

Des solutions techniques existent. On peut citer notamment les slaves sur Jenkins ou TeamCity, qui permettent de compiler en parallèle plusieurs tâches de build.

Les solutions dans le cloud comme Azure DevOps semblent être dépourvues de ces aspects complexes d’échelonnage, car gérées à la volée dans le nuage. A prendre avec des pincettes cependant.

A quel moment lancer l’usine ?

Si vous avez mis en place un système de Code Review avec Git Flow (et j’espère pour vous que c’est le cas), ou un processus similaire, il faut savoir qu’il est commun de coupler ce processus avec une intégration continue. 

En effet, il peut être intéressant de lancer les tests unitaires via l’usine à chaque pull request. L’usine devrait alors être capable de notifier l’outil de gestion des sources (comme GitHub), si la build est valide ou non. Il convient ensuite de refuser une pull request qui n’est pas validée par l’usine.

Egalement, il est recommandé de lancer régulièrement l’usine sur les branches develop, avec code coverage, pour s’assurer de l’état stable du package à envoyer en recette fonctionnelle (Acceptance Testing). Il peut être paramétré à chaque commit ou chaque chaque nuit (nightly build).

Finalement, les branches de release et/ou master sont chargées de générer le livrable pour la mise en production, et notifient l’outil de déploiement.

S’imposer une rigueur

La clef de la réussite d’une bonne CI est la rigueur. La qualité du produit ne s’en fera que ressentir. Si le build est invalidé, on corrige le test, le bug potentiel, le code smell, puis on relance le build jusqu’à ce qu’il soit validé.

Mes recommandations d’outils de CI

Team City & Octopus

Tandis que TeamCity est l’une des usines les plus populaires sur le marché, sa simplicité d’utilisation ainsi que sa feature de templates de build réutilisable en font un outil très utile pour les équipes basés sur plusieurs projets. Sa popularité lui confère un large panel de plugins, dont l’un qui s’interfaçe parfaitement avec Octopus, un outil de déploiement que je me dois là aussi de vous recommander.

Azure DevOps

La suite royale pour tout développeur travaillant avec Azure. Cet outil permet d’associer le contrôle des sources avec Git, les tests automatiques et le déploiement directement sur Azure. 

Bitbucket Pipelines

Fonctionnant directement au coeur de l’outil de contrôle de sources Bitbucket, Bitbucket Pipelines est l’un des outils que j’apprécie le plus. Avec une configuration en YAML et une infrastructure de build basée sur Docker, il est intuitif et très pratique à prendre en main.

SonarQube

Nous parlions plus haut de code coverage. SonarQube en est l’un des principaux acteurs. Véritable pépite, il pousse l’analyse de code au maximum, et est même capable de prédire des bugs potentiels. Il est également possible de paramétrer la sévérité de certains code smells. Disponible pour les langages les plus utilisés en entreprise comme Java, Javascript ou C#.

Conclusion

Aujourd’hui, pour assurer la qualité de développement de leur logiciel, les développeurs doivent eux-mêmes établir un processus d’intégration continue. Heureusement, grâce à la simplification des méthodes DevOps appliquées aux outils que nous avons vu dans cet article, nous pouvons admettre que tous les développeurs peuvent devenir maîtres de leur produit.

Afin d’en acquérir la certitude, il faudrait un outil complet qui mêle la gestion de projets à l’intégration continue, sans avoir à passer par des outils externes ou des plugins. JetBrains Space est un outil qui répond à ce besoin !

Disponible dans les prochains mois, cet outil mixe contrôle de sources, gestion de projet et usine, le tout dans un système de notifications par chat. Il possède même une feature servant à localiser son propre collègue dans l’open-space (!) ainsi qu’un calendrier intégré. Loin des distractions, cet outil apporte de la verticalité dans la gestion de projet, concentrant tout au même endroit. À surveiller !