Intégration continue : généralités

continuous

Définition de l’intégration continue (CI) par Martin Fowler, précurseur et promoteur de cette pratique :

« Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. » 
– Martin Fowler, ThoughtWorks Chief Scientist

On retrouve la notion de livraisons fréquentes, ici au niveau du code. Les développeurs doivent commiter leur code le plus fréquemment possible.

Un processus de build automatique s’assure que l’ensemble du code publié est conforme, détecte les éventuelles erreurs et en informe immédiatement l’équipe de développement, afin que les actions correctrices soient entreprises.

Le bénéfice est multiple :

  • toute introduction d’erreur est détectée le plus tôt possible, réduisant le coût de correction
  • le travail d’équipe est facilité puisque les problèmes potentiels liés à l’intégration du code sont détectés en amont
  • mise en place d’une boucle de feedback fournissant de précieux indicateurs sur la santé des projets et rendant les équipes de développements plus impliquées
  • l’automatisation nécessaire à la mise en oeuvre de la CI apporte plus de qualité aux projets et contribue à leur industrialisation

En pratique, le processus d’intégration continue écoute périodiquement le système de gestion des sources (SCM). Dès que des nouveaux commits sont détectés, une phase de build démarre afin de construire le livrable. Pour que la phase de build se termine avec succès, il faut que :

  • le livrable puisse être construit ; cela peut paraître naïf, mais cette phase échoue en cas d’erreur de compilation, ou encore si il manque une dépendance
  • le livrable puisse le crible des tests d’intégration continue : c’est une série de tests automatisés qui vérifie que les commits récents n’ont pas entraîné de régression
  • on peut ajouter d’autres vérifications, qui ne seront pas nécessairement bloquantes, comme la couverture du code par les tests unitaires (Cobertura, Emma) ou la qualité du code (Sonar)

L’outil Jenkins, gratuit, est un des plus répandus pour réaliser l’intégration continue. On trouve également Teamcity, payant, mais dont un des principaux intérêts est l’intégration avec l’IDE (notamment IntelliJ).

Il est important que l’intégration continue s’effectue sur un serveur distant, dans un environnement « neutre ». Cela permet de s’affranchir des spécificités des postes de développeurs (ex : librairie présente sur le poste de travail mais non déclarée dans les dépendances du projet).

L’automatisation du processus est un point également important, le serveur d’intégration continue doit disposer de tout ce qui est nécessaire, sans nécessiter d’intervention manuelle.

Le fait d’automatiser l’intégration continue sur une machine indépendante des postes de travail de développeur permet d’obtenir des builds fiables et reproductibles.

 

Durée et fiabilité du processus de CI

La fiabilité d’un processus de CI est dépendante de la qualité des tests automatisés exécutés. On peut considérer les 2 extrêmes suivants :

  • absence de tests : dans ce cas, on sait au mieux si on est capable de construire un livrable, mais nous n’avons aucun indice sur la capacité du livrable à fournir les fonctionnalités demandées
  • pléthore de tests : en cas de succès, le livrable est apparemment de très bonne qualité ; toutefois, il fort probable que le processus de CI prenne beaucoup de temps, dès lors le feedback vers les développeurs n’est pas suffisamment rapide

Il est donc crucial de trouver un bon équilibre sur la durée du processus de CI : trop court, il garantit difficilement une bonne qualité des builds engendrés ; trop long, il devient un goulot d’étranglement pour les équipes de développement.

On estime qu’au-delà d’1 heure, un processus de CI est trop long. Une bonne durée se situe entre 15 et 30 minutes. Sachant que sur des gros projets, la phase de construction des livrables peut prendre entre 5 et 10 minutes, cela laisse moins de temps pour les tests automatisés.

Une stratégie efficace consiste à disposer de plusieurs profils d’intégration continue, lesquels effectuent des séquences de tests différentes.

Ainsi, un profil dit « au fil de l’eau » n’exécute qu’un sous-ensemble de tests permettant de détecter les régressions majeures. Un autre profil, dit « nocturne » sera activé tous les soirs et permettra de faire tourner un ensemble de tests beaucoup plus vaste. En cas de régressions, celles-ci seront plus mineures, et un délai d’une journée pour la détection/correction reste acceptable et peu coûteux.

Enfin, un profil « hebdomadaire », lancé le week-end, permettra de vérifier ou mesurer des aspects liés la qualité, tels que la couverture du code par les tests ou la qualité intrinsèque du code.

L’important est de trouver un bon compromis en mettant au centre des préoccupations la durée du processus de CI, et en admettant qu’il n’est pas nécessaire de tout contrôler/tester à  chaque build.

Laisser un commentaire