Parlons intégration continue

Technique, User Experience

15 jan, 2019

Comme beaucoup de termes en informatique, sa définition varie énormément en fonction des personnes qui l’emploient.

Wikipédia nous dit : «L’intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l’application développée. […] Le principal but de cette pratique est de détecter les problèmes d’intégration au plus tôt lors du développement. De plus, elle permet d’automatiser l’exécution des suites de tests et de voir l’évolution du développement du logiciel.»

Pour certains pourtant, sa définition se borne à une livraison continue. Mais faisons un petit tour du net pour voir de quoi il s’agit.

Afin d’appliquer l‘intégration continue, 2 conditions sine qua non : un serveur d’intégration continue et un gestionnaire de version.

Serveur

Il existe de nombreux serveurs permettant de faire de l’intégration continue : Jenkins, Travis, Tinderbox, etc.

img01 Parlons intégration continue

Le principe est relativement simple : le serveur récupère le code sur le gestionnaire de version, puis effectue un certain nombre de vérifications et termine souvent par une livraison sur un serveur d’intégration pour des tests « manuels ».

Vérification

Ces vérifications peuvent être de plusieurs sortes :

Test

Les tests sont le coeur de l’intégration continue. Notre précédent article aborde ce point.

– Tests unitaires : les tests unitaires doivent couvrir le plus de code possible. Afin de ne pas perdre de temps par trop d’exhaustivité, le développeur ne passe que les tests en rapport avec le code modifié. Le serveur d’intégration continue passera l’intégralité des tests afin de vérifier qu’il n’y ait pas d’effet sur une autre partie du code que le développeur n’a pas vue.

img04 Parlons intégration continue

– Tests fonctionnels : les tests fonctionnels doivent couvrir toutes les fonctionnalités et tous les cas possibles. Les données sur le poste de développement risqueraient d’être trop nombreuses, et souvent contradictoires (par exemple : un test avec un tableau vide, un test avec un tableau plein). Il est donc impossible au développeur d’envisager tous ces cas de tests sur son serveur local. Le serveur d’intégration va permettre de couvrir l’ensemble des tests, en ayant à disposition un ensemble de jeux de données permettant de couvrir l’exhaustivité. Le temps de chargement de ces jeux de données n’est plus pénalisant pour le développeur et/ou le testeur, puisque les tests sont maintenant automatisés.

img05 Parlons intégration continue

– Tests d’environnement : une application est rarement conçue pour un environnement unique. Une application web doit fonctionner sur 3 ou 4 navigateurs et sur plusieurs versions de ceux-ci. Une application mobile doit passer sur iOS et Android, sur un iPhone 6 comme sur un iPhone 10, etc. Souvent la compilation elle-même existe sur des environnements différent (Windows, Linux, Unix, IOS, etc.)

Encore une fois, il est impossible pour le développeur de tester tous ces environnements sur son propre poste, et même s’il existe des astuces et/ou applications permettant de simuler différents environnements, le temps que cela implique reste encore une problématique.

C’est là qu’intervient le serveur d’intégration qui peut simuler plusieurs machines virtuelles, plusieurs navigateurs, et fait donc économiser son temps au développeur.

img03 Parlons intégration continue

C’est ainsi avec tous les autres tests et cela implique des problématiques similaires : économiser le temps de travail du développeur afin qu’il puisse se centraliser sur sa fonction première pour les tests : ajouter, améliorer et corriger les fonctionnalités existantes, et lancer les tests dans tous les environnements qui doivent être couverts par ces derniers. Un serveur d’intégration permet de répondre à ces deux problématiques : il tourne en continu sans intervention humaine, et possède un ensemble de jeux de données et d’environnements adaptés aux prérequis du projet.

Compilation (fabrication des exécutables)

Le serveur d’intégration continue permet agilement de générer les exécutables (qui, nous le rappelons, ne doivent pas être mis dans le gestionnaire de version). Le serveur d’intégration peut donc se charger de récupérer les librairies externes (qui seront peut être différentes des librairies de développement), compiler les sources pour les différents environnements et appliquer leur mise à disposition.

Propreté du code

Quand on parle qualité, on restreint souvent à des tests. Cependant une application propre contient souvent moins de bugs car ceux-ci s’illuminent comme des sapins et la maintenance en devient évidente. On évite ainsi les «verrues ».

img06 Parlons intégration continue

L’intégration continue permet également l’utilisation d’outils qui checkent la complexité et la propreté du code (comme Sonar par exemple).

Ces outils ne sont pas à négliger, et permettent de couvrir un ensemble de détails :

– Algorithme

– Bonne pratique de codage (noms des variables, tailles des fonctions, etc.)

– Documentation automatique (javadoc, phpdoc, etc.)

– Documentation technique (commentaires du code)

– etc.

Et le reste

Les serveurs d’intégration continue permettent de lancer des commandes « utilisateurs » et vous laisse le loisir de faire « ce que vous voulez »:

– Envoyer un mail au chef de projet pour lui dire que tout va bien

– Envoyer un Slack aux autres équipes de dev qui utilisent ce module

– Mettre à jour le numéro de version et la date de compilation dans le fichier.

– Ajouter un tag sur le gestionnaire de version

– Etc.

Livraison

L’intégration continue inclut souvent la livraison continue.

La livraison peut se faire sur des serveurs de pré-production (intégration, test, pré-prod, etc) afin que le flux d’élaboration reste le plus continu possible.

La livraison peut se faire sous conditions : « les tests passent », à heure fixe, à chaque commit, etc. car certains déploiements peuvent couper l’utilisabilité du serveur, de l’application ou de grosses ressources qui généraient les autres intégrations.

img02 Parlons intégration continue

L’intégration continue favorise qualité et maintenabilité, donc du temps gagner à moyen et long terme.

Pour les chefs de projet et managers, elle permet un meilleur suivi  de la qualité et des livrables, et permet également de voir les lacunes de l’application et potentiellement des développements. A court terme cela optimise la visibilité du projet. A long terme, elle fait monter en compétences équipes et processus (tout en simplifiant les processus de livraison)

Amis développeurs, prendre le temps de configurer un tel serveur, c’est s’assurer que les tests seront effectués par tous. Cela permet de garantir aussi les dev de tout le monde dans le respect des bonnes pratiques.

Bref, un vrai sujet à aborder en interne 😉

 

Laisser un commentaire.