Build automatisé

Pratique

De quoi s'agit-il?

Le terme "build" désigne la production, à partir de l'ensemble des fichiers qui sont sous la responsabilité d'une équipe de développement, du produit sous sa forme définitive.

Cela inclut non seulement la compilation des fichiers sources, éventuellement leur regroupement sous la forme de fichiers compressés (Jar, zip, etc.) mais également la production de fichiers d'installation, de mise à jour ou création de bases de données, et ainsi de suite.

On parle de "build automatisé" dès lors que toutes ces étapes peuvent être réalisées de manière totalement répétable et sans intervention humaine, uniquement à partir des fichiers sources présents dans l'outil de gestion des versions.

Erreurs courantes

  • ne pas confondre build automatisé et intégration continue: l'intégration continue consiste à déclencher le plus fréquemment possible le processus de construction (idéalement, automatiquement à chaque publication de code dans l'outil de gestion des versions) et à vérifier l'intégrité du résultat produit, notamment par l'exécution de tests automatisés

  • en particulier, les outils d'intégration continue (CruiseControl, Hudson, etc.) sont distincts des outils d'automatisation du build (make, Ant, Maven, rake, etc.)

  • la prise en charge par un environnement de développement (IDE) de certaines opérations d'assemblage n'est pas suffisante: il doit être possible de réaliser le "build" en dehors de l'IDE

  • on conseille en général s'assurer que le "build" dure moins de 10 minutes, tests automatisés compris; au-delà, on compromet la capacité de l'équipe à pratiquer l'intégration continue

Origines

  • le principe d'automatiser une mécanique complexe d'assemblage de composants logiciels ne date pas d'hier: l'outil "make" remonte à... 1977

  • bien que la pratique ne soit pas nouvelle, ni limitée aux approches Agiles, ce sont ces dernières qui relancent l'intérêt pour une automatisation complète; la vogue des environnements intégrés pendant les années 90 a plutôt eu pour effet de marginaliser les outils du type "make", on assiste ensuite à un revirement dans les années 2000

Comment reconnaitre son utilisation?

Pour s'assurer de la mise en place d'un build automatisé, le plus simple est d'effectuer un test à l'improviste: demander par exemple à une équipe de fournir une version installable de son produit.

Utilisez un chronomètre pour mesurer le temps nécessaire à l'obtention d'une version, puis tentez l'installation sur une machine qui n'a pas été préparée par l'équipe de développement. Toute "surprise" pendant ce processus peut être considérée comme une piste d'amélioration du build automatisé.

Quels bénéfices en attendre?

L'automatisation du build est un prérequis à l'utilisation efficace de l'intégration continue. Elle apporte cependant des bénéfices propres:

  • elle élimine une source de variation et par conséquent de défauts; une procédure manuelle qui contient de nombreuses étapes, toutes nécessaires, offre autant d'opportunités de se tromper

  • elle impose de documenter l'ensemble des hypothèses et suppositions qui caractérisent l'environnement cible, ainsi que les dépendances envers des produits externes

Où se renseigner pour en savoir plus? (livres, articles)