L’integration Continue
L’intégration continue est une pratique en génie logiciel qui consiste à intégrer fréquemment le développement des différents membres d’une équipe de projet. Techniquement, à chaque fois que l’un des membres de l’équipe publie ses modifications du code source (“commit”) sur l’outil de gestion de version (comme CVS ou subversion), l’outil d’intégration continue compile le code source et très souvent publie un rapport destiné aux développeurs. Un tel outil peut aussi déployer la version compilé du projet/application vers un serveur d’application et soumettre l’application à des tests unitaires et de non-régressions.
Pour bien comprendre ce qu’est l’intégration continue, je conseil cet article “Continuous Integration” par Martin Folwer dont la version original date de 2000.
Les bénéfices d’une telle pratique sont les suivants :
Estimation de charge, correction de bogues et contribution du client/utilisateur :
Dans un processus d’intégration différé (càd une fois que les développements sont terminés ) il est souvent difficile de prédire la charge effective. En effet lors de l’intégration c’est une multitude de bogues qui vont se superposer et en cacher d’autres. Il devient alors difficile d’estimer combien de bogues on aura à corriger et combien de temps mettront ces corrections.
Avec l’intégration continue, si j’introduis un bogue dans mon code, je m’en apercevrais rapidement (voir immédiatemment) et il sera alors plus facile à corriger (car il n’y aura pas ou peu d’accumulation). De plus il n’y a plus besoin d’estimer la charge du processus d’intégration car il fait parti du processus de développement.
Enfin l’intégration continue permet aussi de pouvoir estimer facilement l’état fonctionnel de notre application. En effet le but est d’avoir à tout moment une application déployée qui marche (et dont l’utilisateur pourra faire un retour).
En ce moment je travaille sur un projet utilisant le principe d’intégration continue. Nous utilisons l’outil CruiseControl. Je sais qu’un outil plus performant est récemment sorti, Hudson, mais je ne l’ai pas encore étudié.
Bonne intro sur la question de l’intégration continue. Est-ce qu’au sein d’une équipe, il n’y a pas à se mettre d’accord avant de se lancer ? A l’intégration continue ne faut-il pas ajouter une coordination continue ?
Effectivement l’intégration continue fait partie des méthodes dites “Agiles”. Pour mettre en place de telles méthodes cela nécessite de cadrer au démarrage du projet un certain nombre de process et d’outils plus particulièrement.
Pour l’intégration continue la problématique est que l’équipe de développement développe sur un environnement qui n’est pas le même que celui de l’équipe de qualification ou celui du client. Ainsi avec le code source du développement nous devons être capable de générer l’application pour n’importe quel environnement cible. Le code source doit avoir le moins d’adhérence possible avec son environnement d’origine. Ceci nécessite donc de mettre en place certaines architecture et d’outils au démarrage du projet.
Pour l’architecture nous pouvons faire le choix du framework Spring s’il s’agit d’un développement Java/J2E, qui nous garantira le couplage faible. Mais pour entrer dans un processus d’intégration continue cela ne suffit pas, il est nécessaire d’utiliser un outil de génération automatique de l’application (la compilation) vers l’environnement cible.
Sur mon projet le choix de l’outil Maven a été fait dans ce but (en partie). Celui-ci nous permet de choisir l’environnement au moment de la compilation.
Nécessairement les éléments d’architecture sont à définir au démarrage du projet, en revanche un outil comme Maven peut-être mis en place plus tard. Cependant je conseillerai d’y penser dès le début, même si la tâche est coûteuse surtout pour un début de projet où il faut souvent pouvoir montrer un résultat très rapidement.
Je me corrige ! Maven est à initialiser au lancement du projet !