Intégration continue : en pratique

Les pré-requis

Les trois éléments suivants sont indispensables :

  • un référentiel de contrôle de version, dans lequel tous les éléments du projet sont publiés
  • un build automatisé
  • le plus important : l’adhésion complète de l’équipe

 Contrôle de version

Le référentiel de contrôle de version est indispensable, quel que soit le nombre de développeurs impliqués dans le projet (même pour des projets mono-développeurs ou de petits projets, on ne peut faire l’économie du contrôle de version).

Ce contrôle de version est réalisé au moyen d’un SCM (source-control management) dont les plus connus sont Git, Subversion, CVS.

Les éléments suivants sont publiés :

  • code source de l’application
  • tests
  • scripts de base de données
  • scripts de build
  • scripts de déploiement
  • tout ce qui peut de près ou de loin être utile à la création, l’installation, l’exécution ou les tests de l’application; cela inclut les éléments de configuration

Automatisation du build

Le build doit pouvoir être construit à partir d’une seule ligne de commande, et ne doit inclure aucune étape manuelle. Cela permet d’abord à toute personne de pouvoir lancer un build de l’application sans se poser de questions, mais surtout le build peut être piloté par un outil d’intégration continue.

Il est important de considérer les scripts de build avec le même niveau de qualité que le code, et ne pas hésiter à les refactorer ou les nettoyer de telle sorte qu’ils soient faciles à comprendre et à maintenir.

De nombreux outils peuvent être utilisés pour scripter le build, du langage de ligne de commande du système d’exploitation, à Maven, outil dédié au build qui rencontre une large adoption.

Adhésion de l’équipe

Le processus d’intégration continue nécessite un certain degré d’implication et de discipline de la part des développeurs qui doivent s’astreindre le plus possible aux règles suivantes :

  • publier fréquemment dans le SCM, par petits changements, dans l’idéal plusieurs fois par jour
  • en cas de rupture du build, la correction du problème doit être la priorité (c’est également une indication que la tâche ayant mené à la rupture n’est pas terminée)

Le système de base

Un système d’intégration continue efficace rend les services suivants :

  • détection des changements apportés au projet sur le SCM à intervalles réguliers et déclenchement d’un build automatique le cas échéant
  • notification en cas d’échec du build, avec la cause précise de l’échec (erreurs de compilation, tests en échec, etc.); la notification par email est un moyen efficace, même si certains systèmes évolués notifient les erreurs directement dans l’IDE du développeur
  • possibilités de visualisation de l’état des builds en cours
  • identification des builds : cela se fait généralement en attribuant un numéro incrémental au build, mais également en indiquant les détails du commit ayant déclenché le build
  • sauvegarde et archivage des livrables : il est possible de récupérer les livrables correspondant à un build ou un état du SCM donné
  • historisation des builds : cela permet de retrouver d’anciens builds, mais également de fournir des indicateurs sur la santé du projet

Bonnes pratiques

Pas de commit sur un build rompu

En committant sur un build rompu (ou rouge) :

  • on ajoute du bruit, rendant plus difficile et plus longue la qualification du problème
  • par conséquent, le build est dans un état rouge plus longtemps
  • à terme, on assiste à une banalisation de l’état rouge du build dans un cercle vicieux où les commits s’accumulent
  • au final on perd le bénéfice de l’intégration continue

Tester en local avant de commiter …

… et rafraîchir la copie locale avec celle du référentiel de contrôle de version avant de lancer les tests.

Cela permet au développeur de s’assurer que :

  • ses modifications ne mettent pas de façon évidente le build en danger
  • ses modifications ne rentrent pas en conflit avec celles d’un autre développeur ayant commité entre temps

Cela contribue à garder le build dans un état vert (ou sain) plus longtemps.

Suivre l’état du build après un commit …

… tout en s’assurant d’être disponible en cas d’échec du build, pour corriger au plus vite.

On évite :

  • de commiter avant de partir déjeuner ou en réunion
  • de faire des commits relatifs à une autre tâche entre temps
  • de commiter juste avant de rentrer à la maison

Laisser un commentaire