Mis à jour le 10/09/2014
  • 30 minutes
  • Facile
Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

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...

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

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...

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.

Exemple de certificat de réussite
Exemple de certificat de réussite