Intégration continue

Je vous propose dans cet article de voir ce qu’est l’intégration continue devenue quasiment indispensable dans le monde de l’agilité. Je rencontre encore quelques personnes qui connaissent ce terme mais qui n’arrivent pas forcément à le définir concrètement. Mais alors, qu’est-ce l’intégration continue ?

Définition de base de l’intégration continue

L’intégration continue est un ensemble de pratiques d’ingénierie logiciel permettant de tester automatiquement les aspects techniques d’un produit à différents niveaux. Elle a pour but d’éviter au maximum de potentielles régressions futures.

Cette technique d’intégration continue redevenue très populaire est aujourd’hui très associée à l’Extreme Progamming et au Devops. Il y a de plus en plus d’équipes Scrum qui  font de l’intégration continue ; cela dans le but de répondre à un besoin d’excellence technique.

Nous retrouvons dans le périmètre de l’intégration continue différents outils d’automatisation de tâches : le compilation, les tests unitaires, les tests fonctionnels, les tests de qualité de code, la validation du produit, les tests de performances, les tests de charges…

Pour faire simple, l’intégration continue permet aux entreprises de renforcer la qualité technique des produits et de limiter le nombre de futurs bugs.

Les types d’outils pour faire de l’intégration continue

Un outil de versioning

Aujourd’hui, pour stocker le code de façon intelligente (gestion de version simplifiée, partage des modifications de codes à l’ensemble de l’équipe…), nous allons utiliser un outil de versioning : git étant de loin le plus célèbre d’entre eux aujourd’hui.

Il existe des plateformes qui facilitent son utilisation telles que Github, Gitlab ou Bitbucket. Il existe aujourd’hui de nombreux outils qui se connectent à ses plateformes de versioning pour aider à implémenter des solutions complémentaires d’intégration continue (tests unitaires, tests fonctionnels, tests de charges, mise en production…)

Intégration continue : automatisation de la compilation

Certains langages de développement tels que le Java ont besoin d’être compilés pour pouvoir fonctionner. Cependant le fait que cela s’enclenche automatiquement, est nettement plus pratique pour les développeurs et pour fluidifier l’ensemble des mises en recette ou de production.

Intégration continue : plateforme de recette, qualification, intégration…

Voici juste un petit chapitre rapide pour expliquer les différents environnements qui existent au sein des entreprises dont celles qui font de l’intégration continue :

Développement : chaque développeur a sa propre plateforme de développement avant même de partager son code avec l’outil de versioning.

Intégration : les développeurs se partagent leur code au sein de la plateforme d’intégration (pas toujours disponible d’ailleurs).

Recette/qualification : pour pouvoir tester sur un environnement stable contrairement aux plateformes de développement et d’intégration, on met en place une plateforme de recette (aussi appelée qualification) ; dans le monde de l’agilité aujourd’hui c’est le product owner ou un testeur attitré qui teste le rendu afin de valider ou non ce qui a été livré.

Pré-production : afin de voir le rendu final, on a une plateforme identique à la production ; elle permettra d’avoir une vue finale du produit avant qu’il soit disponible pour les utilisateurs finaux. En devops sous le format du déploiement continue, cette plateforme n’existe pas.

Production : les livraisons sur cette plateforme sont directement à destination des utilisateurs finaux. Aucun test humain ne doit être réalisé sur ces plateformes. En devops sous le format du déploiement continue, des tests automatisés permettent de vérifier si il n’y a pas de soucis rencontrés ; si c’est le cas, la plateforme reviendra automatiquement à sa version précédente stable (ce qu’on appelle un rollback).

Intégration continue : tests de non regression

Il existe aujourd’hui de nombreuses techniques pour éviter d’avoir de la régression sur le code. Nous allons lister ici les principaux tests existants.

Les tests unitaires

Les tests unitaires ont pour but de créer un test pour chaque fonction (technique et non fonctionnelle) créée dans le but de tester qu’elle fonctionne bien.

Nous avons d’ailleurs écrit un article qui parle de la TDD qui est une façon très appréciée dans le monde de l’agilité pour faire ce type de tests.

Article : La qualité du produit avec de la TDD

Les tests fonctionnels

Les tests fonctionnels permettent de tester chacune des user-stories avec plusieurs scénarios différents. Le product owner va écrire les scénarios dans un langage naturel ; celui-ci sera automatiquement transformé en fonction technique à remplir par les développeurs.

Voici un article que j’ai écrit dans le passé qui rentre dans le détail de ce type de tests.

Article :  Et si on faisait de la BDD (Behavior Driven Development)

Les tests de qualimétrie

Ce type de tests automatisés permettent de mesurer la qualité du code. Il existe différents outils avec différents critères qui vont à chaque compilation (ou partage de code pour les langages non compilés) lire le code et attribuer une note à l’ensemble du programme.

Certains vont définir un plafond minimal sous lequel le code sera refusé pour aller vers une mise en recette ou production. C’est assez utile pour s’imposer une qualité de code minimale même si ce type d’outils ne fait pas tout le job.

En exemple nous aurions SonarQube, Scrutinizer, Sensiolab Insight…

Les tests de performance

Il existe également des outils permettant de faire des tests de performance de l’application. C’est fort utile pour définir la performance minimale acceptable pour présenter le produit au client.

Les tests de charges

Les tests de charges vont mettre énormément à contribution l’application pour voir comment celle-ci résiste à des charges extrêmement fortes. On veut s’assurer qu’en cas de grande influence, l’application sera capable de tenir.

On peut également définir un minimum de charge qu’on estimera obligatoire à pouvoir tenir pour livrer l’application en production.

Conclusion Intégration continue

L’intégration continue déjà très populaire avec l’Extreme Programming est revenu en force avec l’univers du Devops. Il n’est pas toujours simple d’avoir une chaîne totalement automatisée ; cependant l’investissement pour la mettre en place devient un bénéfice non négligeable pour le produit.

La BDD est relativement complexe à mettre en place ; elle implique un apprentissage fort du côté fonctionnel comme technique. Je recommande à tout projet agile de se doter d’une chaîne d’intégration continue pour maximiser la qualité de chacune des livraisons.

Avez-vous des astuces à nous proposer sur la mise en place de l’intégration continue ? Bénéficiez-vous déjà de l’intégration continue ?