Le concept
Définition
D'après wikipédia : L'intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l'application en cours de développement.
Cette définition est un peu trop simpliste à mon goût. Pour moi l'intégration continue est l'art de tester des modules développés par une équipe sur une plateforme automatisée afin d'assurrer la cohésion du code créé. Il permet d'accélérer la productivité et de mettre en avant plus rapidement les bugs pouvant être présents. Il permet en outre de s'assurer de la non regression des logiciels et libère aussi quelques ressources humaines grâce à l'automatisation des tests.
Des mécanismes de rapports ou de détection de bugs peuvent être mis en place ainsi que des systèmes de statistiques qui mettent en évidence la stabilité de chaque code et par conséquent la qualité du travail de chaque développeur.
En bref à quoi ça sert ?
- Tester à chaque modification
- Assurer la non régression
- Reporter
- De manière automatisée
Les avantages
Cette technique nous permet de gagner en productivité, en temps, en argent, mais aussi en qualité de code. On anticipe et identifie rapidement les bugs tôt avant la mise en production du logiciel. Cela nous permet d'avoir une bonne vision du logiciel, notamment sur les différents points forts et points faibles du code ou de l'équipe. Ce qui nous permet de gagner en réactivité pour faire face aux divers problèmes pouvant être présents dans les différentes phases du projet.
L'intégration continue s'applique très bien avec les méthodes de dévelopement agile, telles que SCRUM.
Comparaison Intégration/Intégration Continue
Intégration classique: on code tout puis on teste
L'intégration classique intervient dans la dernière phase de développement d'un projet qui consiste à assembler tous les modules développés et testés unitairement. Cet assemblage est ensuite testé. S'en suit une phase de correction, puis de nouveau des tests en boucle jusqu'à ce que tout soit ok. Cependant il est souvent plus difficle et plus coûteux de corriger les bugs après la fin du projet car cela implique de lourdes modifications sur le code en général. Ou bien par manque de temps tous les tests ne sont pas réalisés et des versions de logiciels voient le jour en conservant plein de bugs.
Intégration continue: on code, on commite, on teste, on code, on commite, on teste...
L'intégration continue a donc pour but de tester l'ensemble du code déjà créé. A mesure que le développement logiciel se poursuit, à chaque publication de code, des tests sont réalisés en parallèle du developpement et ce de manière continue.
Architecture
L'architecture comporte différents éléments n'intervenant pas uniquement dans l'intégration continue mais plutôt dans des équipes de développement en général. Elle se compose donc :
- Un gestionnaire de code source
- Un logiciel d'intégration continue
- Une équipe de développeurs
- Un outil de reporting ou/et d'un serveur de suivi de bug
Fonctionnement
Explication du fonctionnement de l'intégration continue en 4 étapes
Etape 1
Le développeur code sa fonctionnalité ou le module qui lui a été défini. Après avoir conçu son module, il réalise des tests unitaires sur sa machine afin de s'assurer que tout fonctionne correctement dans son environnement. Il récupère le code sur le gestionnaire de source pour mettre à jour le code qu'il a. Il fusionne son code avec le code qu'il a récupéré puis résoud les conflits, teste de nouveau son code sur sa machine et apporte des corrections éventuelles. Si tout est ok, il publie alors son code via son gestionnaire de code source.
Etape 2
Le serveur d'intégration possède un service de détection de modification de code, suite à la dernière publication du développeur il prépare une tâche qui consiste à récupérer le dernier fragment de code développé et à l'intégrer dans sa plateforme. Il exécute cette tâche appelée communément Job.
Etape 3
Une fois le job terminé, des rapports portant sur la qualité, la stabilité ou encore les divers bugs pouvant être rencontrés, sont générés et transmis à l'ensemble de l'equipe ou juste au développeur.
Etape 4
L'équipe peut alors consulter ces rapports, les analyser, traiter des bugs s'il y en a, puis continuer à développer les autres phases du projet.