Intégration continue

Introduction du cours

L'intégration continue (CI : Continuous integration) est un ensemble de pratiques qui permettent de s'assurer :

• de la qualité d'une application. On peut ainsi s'apercevoir au plus tôt d'erreurs intégration, suite à un oubli d'inclusion par exemple, ou des régressions possibles.

• du respect des normes de nommage, de programmation... établies pour l'application.

À l'origine, les serveurs d'intégration servaient à compiler le code centralisé, ce qui permettait de voir si toutes les dépendances étaient satisfaites. Ils se sont rapidement mis à lancer automatiquement des tests unitaires. C'est une technique de développement appelée Test Driven Development (TDD), qui consiste à décrire et écrire les tests avant même de commencer à développer une fonctionnalité. Ils se sont également dotés d'autres fonctionnalités et font ainsi partie intégrante du processus d'Assurance Qualité (AQ ou QA).

C'est l'une des pratiques de l'Extrem Programming (XP), mais n'est pas limité à cette méthode de développement, et peut s'appliquer à tout projet en cours ou à venir.

Grâce aux fonctionnalités d'un serveur CI, cela permet :

• un travail d'équipe puisque le code est centralisé, la documentation technique générée (donc à jour), ce qui concourt à une appropriation collective.

• de s'assurer de la qualité du code, en mettant en place des vérifications de règles : normes, duplications de code...

• et de la  conformité du livrable. En effet les tests (unitaires et éventuellement fonctionnels) sont effectués au plus tôt et automatiquement. On s'assure lors du remaniement du code (refactoring). de la non-régression, qu'il n'y a pas de conflit, que toute les dépendances sont satisfaites...

Ne pas confondre tests unitaires et tests fonctionnels

• Un test unitaire, c'est de tester la fonction d'addition pour vérifier si 1 + 1 = 2. Plus concrètement, si nous prenons l'exemple de la COGIP, qui, pour accéder à la ressource REST produit, a une méthode Slugify dans la classe Produit. Le test unitaire vérifie que cette méthode retourne une réponse, celle attendue, au bon format.

• Un test fonctionnel vérifie que la fonctionnalité entière a été développée telle que spécifiée. Pour la COGIP, ce serait de tester l'ajout d'un nouveau produit au catalogue par exemple.

Les principes

Il y a quelques règles à mettre en place pour appliquer cette technique.

Centraliser le code

Il faut que le code source soit partagé en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial...

Faire des commits réguliers

En commitant régulièrement, les contributeurs réduisent ainsi le risque de conflit. En effet plus les commits sont espacés plus il sera difficile de résoudre ces conflits éventuels. Les développeurs doivent donc communiquer entre eux, et/ou bloquer (lock) les composants dans le gestionnaires de version

Commit quotidiens et commits finalisés

Bien que normalement on doit commiter tous les jours, en pratique, il n'est pas toujours judicieux de commiter régulièrement, car le build doit néanmoins se faire. En effet le développement peut ne pas être finalisé. Il sera donc normal que des dépendances ne soient pas présentes. De même, il sera difficile de revenir en arrière (revert) dans le gestionnaire si on committe tous les jours, plutôt qu'une fois le travail terminé.

Automatiser les builds

Comme tout le monde committe régulièrement, le trunk/master est donc compilé  sur une machine d'intégration. Il est donc possible d'automatiser les compilations. Tout problème est alors rapidement identifié.

Rendre les compilations auto-testantes

Une fois le code développé, des tests doivent être faits pour confirmer qu'il a le résultat attendu. Des tests d'intégration doivent être développés pour valider l'application. Le TDD (Test Driven Development) a popularisé les ouils Xunit (JUnit/PhpUnit par exemple).

Les outils XUnit  sont intégrés à la plupart des serveurs CI, et sont un point de départ. Il est cependant bon de regarder aussi d'autres outils plus orienter fonctionnels, tels que FIT, Selenium, Sahi, Watir, FITnesse...

L'absence de bugs ne prouve pas l'inexistence de bugs. On ne teste que les fonctionnalités pour lesquelles des tests ont été faits. Attention donc qu'ils soient à bon escient.

Tester dans une configuration identique à celle de production

On a vu que les tests unitaires et les tests fonctionnels sont faits par des scripts dédiés. C'est-à-dire s'assurer au maximum de la VABF (Vérification d'Aptitude au Bon Fonctionnement), recette fonctionnelle cependant réalisée par la MOA. Il faut aussi tester les performances et anticiper la VSR (Vérification au Service Régulier), phase de mise en production sur un site pilote.

L'environnement de test peut être différent de l'environnement de production de façon significative. Cependant mettre le serveur CI dans l'environnement de production est à prohiber. Avoir alors un environnement de pré-production permet de d'être au plus près des conditions d'utilisation.

Bénéfices apportés

L’intégration continue apporte donc tranquillité d'esprit, car dans un intégration différée, on ne sait jamais combien de temps cela va prendre. Les principaux avantages d'une telle technique sont :

• Tout le monde voit  ce qui se passe. Le résultat de la compilation (metrics) et la version sont au vu et au su de tout le monde.

• Les développeurs sont avertis rapidement des incompatibilités, des dépendance cassées, des bugs... Il fixent les problèmes de façon continue, empêchant ainsi les problèmes de dernière minute.

• On peut mettre en place la métrologie sur les tests et le CI, ce qui accroît la qualité du livrable et crée une cohésion de l'équipe, grâce à l'envoi immédiat des résultats des metrics.

• Une version est toujours disponible pour un test, une démonstration ou une distribution.

• De ce fait, on peut facilement automatiser le déploiement de la version. Si une méthode agile est mise en place, on peut alors avoir aisément des déploiements fréquents, et abattre ainsi les barrières qu'il peut y avoir entre équipe de développement et utilisateurs.

Serveurs CI

• Apache Continuum: serveur de l'Apache Software Foundation supportant Apache Maven et Apache Ant.

• CruiseControl: serveur d'intégration continue en Java.

• PhpUndeControl : plugin de CruiseControl spécifique pour les projets PHP.

• Jenkins (fork de Hudson) : serveur d'intégration continue en Java.

• MS Team Foundation Server : plate-forme collaborative avec intégration continue et code source centralisé.

• [...]

Vous connaissez maintenant ce qu'est l'intégration continue, mais ça n'est qu'un début... ! Il faut maintenant le mettre en pratique et implémenter un serveur CI.

• #

Waouh !

Très heureux de voir que nos cours vous plaisent, déjà 3 pages lues aujourd'hui ! Vous pouvez continuer la lecture de nos cours en devenant un Roomie, un membre de la communauté d'OpenClassrooms. C'est gratuit !

Vous pourrez aussi suivre votre avancement dans le cours, faire les exercices et discuter avec les autres Roomies.

S'inscrire Se connecter

• Thématiques du cours : Programmation

Chaque cours est créé par un professeur ou un expert dans le domaine. Il est composé d'une ou plusieurs parties et peut comporter du texte, des images (schéma, illustration) et des vidéos. Chaque partie d'un cours certifiant est ponctuée d'exercices de 2 types : Des quiz corrigés automatiquement Des devoirs libres (exemple : créer un site web avec des consignes précises). Ces devoirs sont évalués par les pairs. Chaque devoir est corrigé 3 fois par 3 autres élèves, dans un processus en double aveugle, selon un barème fixé par le professeur. La note finale est la moyenne des 3 notes reçues sur le devoir. 50% des devoirs corrigés par les pairs obtiennent quasiment les 3 mêmes notes, avec une variance inférieure à 1. La recherche académique montre d'ailleurs que l'évaluation par les pairs peut être aussi précise que celle des professeurs.