Il y a encore quelques années, le développement logiciel restait relativement artisanal, avec beaucoup de processus gérés manuellement, et souvent non reproductibles. Il était alors compliqué de garantir la qualité du code source développé, et de se protéger des régressions potentielles d’une version à l’autre. L’avènement des méthodes agiles  telles que Scrum ou XP ont bouleversé les habitudes, et le développement logiciel s’est industrialisé, avec l’apparition d’outils spécialisés. Désormais, impossible de développer sans parler de « continuous integration », ou intégration continue.

 

Principe de la « continuous integration »

On considère généralement que la « continuous integration » ou intégration continue est issue de la méthode agile XP, pour eXtreme Programming. Globalement, XP encourage diverses bonnes pratiques comme une revue de code permanente (notamment grâce à la programmation par paire), le passage systématique de l’ensemble des tests, le refactoring du code tout au long du développement, des livraisons fréquentes (souvent plusieurs fois par jour) ou encore des cycles de développement très courts de façon à minimiser l’impact des changements éventuels dus à l’évolution des besoins.

La continuous integration est donc une évolution logique des méthodes de travail pour le développement logiciel. Dans un processus classique, l’intégration d’un logiciel, d’une évolution ou d’une « simple » correction (pour autant qu’une correction « simple » puisse réellement exister) se fait une fois sa réalisation terminée. Il est alors possible de s’apercevoir que l’intégration des fonctionnalités est plus compliqué qu’il n’y paraissait et que l’on se retrouve face à des difficultés imprévues.

Le principe de la continuous integration est donc de détecter ces éventuels problèmes d’intégration le plus tôt possible dans le cycle de développement du logiciel. L’objectif est d’améliorer la qualité du code et d’en garantir le niveau du début à la fin des développements, jusqu’au produit final. Des contrôles sont donc effectués durant tout le processus de développement, grâce à des ensembles de tests, généralement automatisés. Si un seul de ces tests échoue, la cause de cet échec doit être analysée et le problème résolu avant de continuer le développement.

 

Qu’apporte réellement l’intégration continue dans un projet ?

La continuous integration s’appuie généralement sur un ensemble de logiciels permettant l’automatisation d’un certain nombre de tâches répétitives. Des options et des contrôles automatiques sont mis en place à chaque compilation lorsque le langage de programmation utilisé le nécessite, et des tests unitaires ainsi que des tests fonctionnels sont créés. Chaque fois qu’un changement dans le code source du logiciel est enregistré, l’ensemble des contrôles et des tests créés sont exécutés.

Les résultats sont regroupés dans un rapport, qui peut alors être utilisé par le développeur pour améliorer son travail. Des outils de contrôle de la qualité du code source écrit par le développeur peuvent également être mis en place. Ainsi, dès que le développeur écrit du code, l’outil vérifie automatiquement qu’il respecte les règles communes mises en place pour l’ensemble de l’équipe. Si ce n’est pas le cas, le développeur est invité à corriger son code. Cette procédure garantit la qualité du code produit par le respect des bonnes pratiques de développement.

En intégrant l’ensemble de ces contrôles de façon continue dans le cycle de développement, il est possible de considérablement améliorer la qualité du code écrit ainsi que sa stabilité dans le temps. Il est impossible d’oublier un test avant de livrer une nouvelle version en production puisque cette dernière serait obligatoirement bloquée.

La continuous integration fait gagner énormément de temps aux équipes de développement. En effet, chaque modification du logiciel est immédiatement testée. Si un seul test échoue, qu’il s’agisse d’un test créé précédemment ou d’un nouveau lié à la modification, le processus est bloqué. Ce n’est que lorsque le problème sera réglé et que le test réussisse que le développement peut se poursuivre. Si un élément de code source écrit par un développeur entre en conflit avec le code créé par un autre développeur, le problème est immédiatement identifié, même chose avec les incompatibilités entre le logiciel et l’écosystème dans lequel il devra évoluer (système(s) d’exploitation, systèmes d’information externes, format d’échange sur le réseau…). Inutile d’attendre que le logiciel soit mis en production pour s’apercevoir qu’il ne fonctionne pas…

De plus, grâce à la continuous integration, il existe toujours une version fonctionnelle du logiciel. Cela permet d’effectuer des tests, des démonstrations, voire des formations pour les utilisateurs finaux dans certains cas, sur une version à jour, intégrant les dernières fonctionnalités. Cette version peut être ouverte à d’autres que l’équipe de développement, au client, à une équipe qualité ou à une équipe de validation chargée de vérifier l’adéquation entre l’expression des besoins et l’application livrée.

 

Comment mettre en place l’intégration continue ?

La première chose à faire est d’utiliser un gestionnaire de version du code source qui permette à tous de travailler sur un dépôt unique. On a ainsi une seule source commune à tous, partagée par tous les développeurs. Les logiciels Subversion (SVN) ou Git sont très répandus dans les projets de développement.

Chaque développeur doit impérativement réintégrer l’ensemble de ses modifications dans le dépôt de code source (commit) au moins une fois par jour. Le tronc ou le code source racine peut alors être compilé (si nécessaire) et livré ou déployé automatiquement chaque sur un serveur dit d’intégration afin que cette version puisse être testée tous les matins.

Si le code source nécessite d’être compilé pour être utilisé (comme Java par exemple), il faut automatiser cette étape. Toute compilation ou livraison de code doit déclencher une série de tests et de vérification de la qualité des sources.

Enfin, le déploiement de l’application doit être automatisé. Il est loin le temps où chaque développeur devait manuellement transférer ses fichiers et modifier la configuration pour que tout fonctionne.

Désormais, des outils comme Jenkins permettent de définir des scénarios de livraison, afin que telle version de l’application soit déployée sur un serveur particulier avec la configuration correspondante pour que tout fonctionne. Une fois les processus définis, il suffit de cliquer sur un bouton pour que le déploiement se fasse tout seul.

Naturellement, la continuous integration doit faire partie intégrante de la gestion de projet. Un outil tel que Nutcache prend facilement en compte les contraintes liées. N’hésitez pas à l’essayer et profitez de Nutcache durant 14 jours gratuitement.