Continuous/Integration

Un article de Agora2ia.


Sommaire

Présentation

Intro

Le système est intégralement assemblé et testé une à plusieurs fois par jour.

L'idée de cette pratique est de détecter le bug le plus tôt possible.


Idéalement, une machine dédiée surveille le gestionnaire de version et lance un cycle complet d'intégration (par exemple : compilation, jeu des test unitaires, construction de l'application, déploiement, jeu des test release, livraison et génération des rapports) à chaque fois qu'elle détecte le remontée d'une modification.

Selon les systèmes et les interprétations, la durée totale de jeu les tests release peut/doit ne pas dépasser quelques minutes ou bien atteindre voire dépasser l'heure. Entre ici en jeu les techniques utilisées (C++ vs Java, compilation à la volée, distribuée, intelligente...) et l'architecture déployée (être capable de reproduire l'environnement et l'arborescence de développement, la base de données et ses identity...).

En détail

On entend par intégration continue le fait de "continuellement intégrer" l'ensemble des sources du projet, à savoir constamment répéter le cycle suivant :

  1. Obtenir au "moment opportun" les sources du gestionnaire de version,
  2. Jouer l'intégralité des tests unitaires,
  3. Construire l'ensemble des cibles et des livrables du projet,
  4. Jouer l'intégralité des tests release,
  5. Publier les rapports et éventuellement les livrables.


Cela est fait sur une machine, que l'on appelle communément "serveur d'intégration continue".


La notion de "moment opportun" peut être déclinée de différentes manière en fonction des contraintes :

  1. Idéalement, on indique à l'outil d'intégration continue une période (de quelques minutes au plus) pendant laquelle il va attendre avant de vérifier si de nouveaux changements ont été remontés vers le gestionnaire de version. Si au moins un changement a bien eu lieu, l'outil lancera alors un cycle d'intégration pour l'application concernée.
  2. En pratique, pour ne pas surcharger le serveur d'intégration, il est fréquent de forcer le nombre de cycles journaliers... à 1, et la nuit (quand personne ne l'utilise) : on parle alors de nightly build.
  3. Dans ce deuxième cas, il peut être pratique de pouvoir lancer manuellement un cycle d'intégration, pour une application donnée, lorsque l'on souhaite valider une modification, sans pour autant "(im)mobiliser" sa propre machine par de longs tests release.


Les freins à une véritable intégration continue et favorisant les Nightly build forcés et systématique sont :

  • Des dépendances à des fichiers qui ne sont pas dans le gestionnaire de version, et donc on n'est pas capable d'identifier (seulement à partir du gestionnaire de version) s'ils ont changés ou non (exemple des dépendances SNAPSHOT dans Maven).
  • La plate-forme d'intégration (base de données incluses) n'étant pas gérée par l'équipe de développement, il peut être nécessaire de vérifier régulièrement si elle n'a pas changée.
  • Si l'application que l'on intègre utilise une base de données, et cette base de données est celle de développement (ou que le nombre de base est réduit en regard du nombre de développeurs), il est très contraignant (voir impossible) de d'intégrer dans la journée parallèlement aux développements.
  • Si le serveur d'intégration héberge d'autres applicatifs, il peut être contraignant (voir interdit) de le solliciter en journée.
  • Celui qui valide l'application (voire le client XP) peut vouloir utiliser le dernier build (sur le serveur) pour vérifier certains aspects de l'application.


L'intégration continue prend tout son sens :

  • avec des équipes étoffées,
  • ou des équipes Agiles (voir ExtremeProgramming) qui pratiquent la propriété collective du code.


L'intégration est donc le point d'orgue d'une longue et perpétuelle quête de la perfection, qui voit passe dans l'ordre par la mise en place :

  1. d'un gestionnaire de version (CVS voire Subversion),
  2. de tests unitaires, voire des tests release,
  3. d'une construction de projet rationalisée (Ant voire Maven).


Au delà

Voir aussi :

Outils

Il existe de nombreux outils d'intégration continue, commerciaux ou OpenSource, aux fonctionnalités plus ou moins nombreuses, comme le montre la très complète Continuous Integration Servers Features Matrix sur le site de l'outil DamageControl.

Voir aussi /Tools


Outils OpenSource

On peut notamment y trouver :


Outils commerciaux

  • TeamCity (home) : Je n'ai as encore essayé cet outil commercial de la société JetBrains, mais IntelliJ (l'IDE Java de la même société) est tellement génial, qu'il ne saurait en être autrement de TeamCity...


Outils en ligne : services


Autres

Exemples de formations

Processus de développement et intégration continue

Sysdeo

  • Public : Chefs de projets, Directeurs de projet
  • Durée : 2 jour(s)
  • Objectifs : Comprendre les objectifs de l'intégration continue lors de la mise en oeuvre de projets, Utiliser Ant et Maven
  • Pré-requis : Aucun


Programme détaillé

  • Introduction
    • Cycles de vie de l'application
    • Les motivations de l'intégration continue
  • Les builds automatisés avec Ant
    • Ant n'est pas make
    • Rappels de base sur XML
    • Structure d'un build Ant
    • Cibles et dépendances
    • Ensembles de fichuiers, références, propriétés
    • Tâches courantes et optionnelles
    • Master-build multi-projets
    • Partage de propriétés et de tâches inter build
    • Création d'une tâche spécifique
  • Les builds automatisés avec Maven
    • Maven n'est ni make ni Ant
    • Rappels de base sur XML
    • Le Project Object Model
    • La définition d'un projet
    • La définition des dépendances
    • La définition du build
    • Référentiels locaux et distants
    • Réutilisation de cibles Ant
    • Création de buts et plug-ins spécifiques
  • Les revues de codes automatisés
    • Checkstyle
    • Findbugs
    • Problématique du développement de tâches spécifiques
  • Les tests automatisés
    • Test infected development
    • Tests unitaires avec JUnit
    • Tests embarqués au sein d'un conteneur avec Cactus
    • Tests avec la technique des MockObjects
    • Calcul de couverture
  • L'intégration continue sous CruiseControl
    • Architecture et installation
    • La configuration à base de plug-ins
    • L'attente des modifications
    • L'accès à un gestionnaire de version
    • Le déclenchement du build
    • La génération du rappord de build
    • La notification des développeurs
    • A l'échelle de grands projets
    • La console JMX
    • Le plug-in Eclipse Dashboard de monitoring de build

Ressources