Intégration continue

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée. Le concept a pour la première fois été mentionné par Grady Booch[1] et se réfère généralement à la pratique de l'extreme programming. Le principal but de cette pratique est de détecter les problèmes d'intégration au plus tôt lors du développement. De plus, elle permet d'automatiser l'exécution des suites de tests et de voir l'évolution du développement du logiciel.

L'intégration continue est de plus en plus utilisée en entreprise afin d'améliorer la qualité du code et du produit final[2].

Intérêt[modifier | modifier le code]

L'intégration continue repose souvent sur la mise en place d'une brique logicielle permettant l'automatisation de tâches : compilation, tests unitaires et fonctionnels, validation produit, tests de performances... À chaque changement du code, cette brique logicielle va exécuter un ensemble de tâches et produire un ensemble de résultats, que le développeur peut par la suite consulter. Cette intégration permet ainsi de ne pas oublier d'éléments lors de la mise en production et donc ainsi améliorer la qualité du produit[3].

Pour appliquer cette technique, il faut d'abord que :

Un outil d'intégration continue est ensuite nécessaire, tel que TeamCity, CruiseControl ou Jenkins (fork de Hudson) pour le langage Java par exemple. D'autres outils, comme SonarQube ou Jacoco, peuvent être mise en place afin de superviser la qualité du code[2].

Les principaux avantages d'une telle technique de développement sont :

  • le test immédiat des modifications
  • la notification rapide en cas de code incompatible ou manquant
  • les problèmes d'intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute
  • une version est toujours disponible pour un test, une démonstration ou une distribution

Pratiques[modifier | modifier le code]

  • Maintenir un dépôt unique de code source versionné
  • Automatiser les compilations
  • Rendre les compilations auto-testantes
  • Tout le monde commit tous les jours
  • Tout commit doit compiler le tronc (trunk) sur une machine d'intégration
  • Maintenir un cycle de compilation court
  • Tester dans un environnement de production cloné
  • Rendre disponible facilement le dernier exécutable
  • Tout le monde doit voir ce qui se passe
  • Automatiser le déploiement

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Références[modifier | modifier le code]

  1. Grady Booch, Object Oriented Design: With Applications, Benjamin Cummings,‎ 1991 (ISBN 9780805300918, lire en ligne), p. 209
  2. a et b « Approfondissement Technique : Intégration continue »,‎ 19 janvier 2015 (consulté le 29 janvier 2015)
  3. « Usine Logicielle, Qualité & Tests », sur zenika.com (consulté le 29 janvier 2015)