L'intégration continue : passer du mythe à la réalité

L'intégration continue (IC) est un ensemble de pratiques et d’outils permettant de vérifier la qualité du code source produit par les développeurs, et d’intégrer leurs productions respectives, en vue du déploiement en production.

Les principes et les objectifs de l'intégration continue

intégration continue et développement agile - Smartview


Les objectifs initiaux de
l'intégration continue :

  • Vérifier le respect des règles de développement  (nommage, dépendances, présence du code)
  • Systématiser et automatiser les tests unitaires (couplage avec une logique de TDD) et les tests d’intégration
  • Identifier les erreurs de code le plus tôt possible dans le processus de développement et de les résoudre en amont au moment où ils sont simples à détecter et corriger

Par induction, l'intégration continue permet de  :

  • Travailler de manière comparable au sein d’une équipe de développement
  • Améliorer la qualité du code (Assurance Qualité)
  • Améliorer la productivité des développements (optimisation de la création de nouveau code plutôt que la correction du code existant, du fait de bugs ou de défauts du code)
  • Raccourcir les délais de tests, d’intégration et au final de mise en production du code
  • Améliorer le time-to-market

L'intégration continue (IC) s’est imposée depuis une dizaine d’années comme une pratique courante au sein des équipes de développement ; c’est une des démarches les plus pratiquées de la méthodologie eXtreme Programming ; elle prolonge naturellement la gestion de version et permet de consolider tous les jours le code source livré par les développeurs (le fameux « commit »). L'intégration continue s’accompagne souvent de la mise en place de bonnes pratiques de refactoring et de Test Driven Development (TDD), elles aussi issues de l’eXtreme Programming.

L'intégration continue est parfaitement alignée avec les rituels agiles (comme le daily standup de Scrum) pour travailler en équipe de manière coordonnée et incrémentale, avec un pas de temps journalier. Elle permet synchronisation et transparence sur l’état du code (car « le diable se cache dans les détails »).

intégration continue - agile scrum - Smartview

Dans la plupart des équipes de développement, l'intégration continue est accompagnée par la mise en place d’un outillage dédié (par exemple Jenkins, Hudson ou Cruise Control…) utilisé couplé à la gestion des sources (avec CVS, Subversion et plus souvent avec GIT) et parfois même à l’interface de programmation (IDE).

L'intégration continue est donc devenue dans la plupart des équipes de développement une démarche standard de codage incontournable et une garantie de qualité logicielle et dont elles ne pourraient plus se passer… Elle favorise l’optimisation des moyens alloués à la création de code nouveau plutôt que la correction du code existant, du fait de bugs ou de défauts du code qui porteront préjudice « plus tard ».

Mise en oeuvre de l'intégration continue : les points clés

Quelles sont les contraintes ?

Si les mérites de l'intégration continue ne sont plus à démontrer, la mise en œuvre de l'intégration continue est souvent insuffisante, car elle ne couvre que « partiellement » les objectifs de qualité et de productivité visés in fine :

  • La représentativité des tests d’intégration continue par rapport à l’environnement de production cible n’est pas toujours parfaite : les tests faits en environnement de développement ne sont pas forcément adaptés pour l’environnement de production, la qualité mesurée est parfois « locale » ; virtualisation et containers, qui permettent de simuler simplement l’environnement de production dès le développement sont des axes d’amélioration, mais ils ne couvrent pas tous les contextes…
  • Les bonnes pratiques d’intégration continue et de la connaissance des outils d’intégration mettent la barre « plus haut » pour les développeurs ; l’homogénéité des pratiques est plus difficile à garantir dans les faits (même si la qualité finale est elle aussi rehaussée) :
    • Plus les outils sont nombreux et complexes, plus le niveau des développeurs est potentiellement hétérogène face à ces exigences (d’où l’importance renforcée de la formation et des pratiques XP comme le pair programming)
    • La formation des nouveaux développeurs (cf. turn-over, nouvelle embauche, voire stagiaire) est coûteuse ; le ticket d’entrée est plus élevé et plus long pour disposer d’un développeur bien formé connaissant bien tous les outils à maitriser
    • Il y a parfois un effet de mode vers des outils, choisis par quelques-uns dans l’équipe et qui ne sont pas correctement ni totalement utilisés par toute l’équipe…

… donc l'intégration continue  apporte des contraintes pour l’équipe de développement pour être vraiment opérationnelle. On a donc souvent des variations suivant les équipes ou les équipiers sur les processus et outils utilisés et maitrisés, ce qui rend l’efficacité de l'intégration continue plus aléatoire.

  • Les bonnes pratiques d’intégration continue ne garantissent pas la cohérence d’ensemble

Souvent, la démarche d'intégration continue est forte au sein d’une équipe de développement, portée par quelques personnes convaincues, mais elle n’est pas alignée avec les autres démarches en amont / aval de celle-ci.

Développement agile & intégration continue : les aborder de façon plus globale

L'intégration continue, si elle est isolée, a peu d’impact sur la valeur totale créée pour les clients / utilisateurs finaux :

intégration continue - Agile - Smartview
    • Améliorer la qualité du code (Cf. Assurance Qualité (AQ)) ne suffit pas : si les tests fonctionnels ne sont pas bien gérés par ailleurs, la qualité finale perçue ne sera pas bonne, même si le code est « satisfaisant » en soi. Le code peut « fonctionner » sans passer les tests métier…
    • La productivité des développements n’est pas garantie par l’intégration continue. Si les spécifications en amont ne sont pas efficaces ni les itérations rapprochées, la productivité du développement ne sera pas atteinte ; on peut développer vite et bien mais pas les bonnes fonctionnalités... Le code peut fonctionner sans être conforme aux besoins du métier.
    • L'intégration continue permet de raccourcir les délais de tests, d’intégration, de performance et au final de mise en production si et seulement si elle est incluse dans une démarche plus large de type DevOps, sans quoi l’entreprise peut stocker du code de qualité (testé, conforme au besoin) pendant des semaines sans en profiter (alors qu’elle l’a déjà payé)

L'intégration continue doit être considérée dans une logique de qualité totale et de développement agile plus globale pour faire sens et pour justifier l’investissement consenti ; sans quoi son apport pour la qualité et la productivité logicielle de l’organisation ne sera pas probant pour les décideurs ni les clients. Elle se résumera alors à tort à un « gadget technique » de l’équipe de développement.

Prendre rdv - Expert Devops

« Intégrer l’intégration continue »

L'intégration continue est devenue une réalité pour la plupart des équipes de développement, au même titre que la gestion de code source, ou les tests unitaires. Elle permet de synchroniser les développeurs de manière régulière (commit + tests d’intégration)  et de garantir un certain niveau de qualité du code… C’est un apport indéniable. Ses apports sont indiscutables et largement reconnus dans la communauté technique.

Pour profiter de tous ses apports, l'intégration continue mérite d’être intégrée à un process d’entreprise agile plus large, c’est-à-dire couplée à d’autres démarches agiles, en connexion avec les Métiers (Scrum, tests fonctionnels automatisés) et avec les équipes de Production (DevOps).

Vous avez des questions quant à la mise en oeuvre de l'intégration continue ? Contactez un expert Smartview. Il vous conseillera, vous accompagnera et répondra à toutes vos interrogations.

Agilite & Innovation

À propos de l'auteur : Christophe Monnier

expertise sur mesure devops - Syloe et Smartview