Concept de l’Intégration Continue

Introduction

Le processus d’intégration continue a pour objectif principal de vérifier que chaque mise à jour du code source ne génère pas de régressions et/ou d’anomalies sur une application en cours de développement.
Historiquement, l’intégration continue a été utilisée par IBM pour le développement de l’OS/360 depuis les années 60.
L’intégration continue n’est pas un outil mais plutôt une pratique issue de l'eXtreme Programming (XP).
Les développeurs d’une même application réintègrent le programme sur lequel ils travaillent le plus fréquemment possible. Il s’agit de déclencher à chaque intégration un processus qui se base sur une platforme qui vérifié automatiquement le fonctionnement de l’application afin que les anomalies soient détectées à leur entrée.

Le plus difficile pour un développeur est de réfléchir sur l’impact réel d’une mise à jour fondamentale sur l’ensemble des fonctionnalités de l’application. L’intégration continue permet de, donner au développeur cette vision plus générale sur l’application puisque les tests de l’application se font sur un environnement clone de production.

Mots clés

• Build : C’est l’ensemble d’étapes nécessaires à la compilation, à la création des livrables au lancement des tests (fonctionnel, unitaires, IHM,etc).
• Commit : C’est l’opération qui permet la validation des mises à jour du code source existant sur le répertoire de travail local de la machine du développeur moyennant l’outil de gestion de configuration (tel que SVN). Le commit se fait du répertoire de travail local vers le référentiel de l’outil de gestion de configuration.
• Update : C’est l’opération qui permet de la mise à jour à partir du référentiel de l’outil de gestion de configuration du répertoire local.
• Checkout : C’est l’opération d’extraction d’une version d’un projet en cours de développement du référentiel du gestionnaire de configuration sur un répertoire de travail local.

Scénario général

• Le développeur fait son commit sur le référentiel du gestionnaire de configuration.
• Le serveur d’intégration continue détecte le commit , fait un Checkout lance les opérations de compilation et de tests
• En cas de d’échec une notification est générée au chef de projet et/ou à l’équipe de développement.
• Le développeur concerné par l’erreur fait un update du référentiel de gestion de configuration et corrige l’anomalie.

Fonctionnalités générales d’un serveur d’intégration continue

Un serveur d’intégration continue doit principalement permettre :

• De faire les opérations de Checkout du gestionnaire de configuration.
• La compilation du code source
• La création de l’archive de l’application (Ear, Jar, War, …)
• Le déploiement de l’archive sur la machine de test.
• L’exécution d’une suite de tests : Junit, Cactus, Audit de code source, test IHM, tests fonctionnels
• La notification du résultat : mail, RSS.
• La création de rapport de statistiques.
• L’intégration avec d’autres outils

Les serveurs de d’intégration les plus connus

• Cruise Control : open source et gratuit, très connu, très documenté, permet de tester des applications J2EE et des applications en .Net. c’est la référence de l’intégration continue.
• Hudson : open source et gratuit, devenu très populaire plus récent que Cruise Control, permet de tester des applications J2EE. Utilisé par SUN
• Continuum : opensource et gratuit soutenu par la fondation Apache
• Bamboo : opensource et payant

Ce document intitulé « Concept de l’Intégration Continue » issu de CommentCaMarche (www.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.