Le mot build, sans traduction convaincante en français, n’a pas de définition clairement établie. Il regroupe toutes les étapes qui nous permettent de passer du code source à un logiciel livrable. En fonction des règles et des enjeux de chacun, cela ira de la simple compilation à l’analyse complète du code par des outils d’audit et de mesure de qualité, en passant par l’exécution d’une suite de tests et à l’intégration avec les outils de développement. Quelle que soit la définition qu’on donne du build, il n’est pas envisageable de réaliser ces opérations à la main.

De nombreuses solutions existent pour automatiser ce processus. Une large majorité d’entre elles utilisent des scripts pour figer les commandes nécessaires et les enchaîner sans intervention de l’utilisateur. Selon la richesse et l’intelligence de l’outil, ces scripts peuvent être plus ou moins complexes et plus ou moins précis dans les commandes nécessaires pour répondre aux attentes du développeur. Ces solutions ont toutes ce même point commun : elles permettent de décrire les commandes à exécuter pour arriver à un objectif, et pas l’objectif luimême, en laissant à l’outil le soin de faire le nécessaire. Ce manque d’abstraction aboutit rapidement à des structures complexes et difficiles à maintenir ou à mutualiser. Depuis sa première version, Maven expérimente une approche différente dite déclarative, qui vise à indiquer en quoi un projet est différent d’un modèle type et nécessite des étapes particulières pour le build. D’autres outils comme Gradle lui ont emboîté le pas, tout en conservant une dimension script qui laisse la boîte de Pandore grande ouverte. Le concept clé de Maven est de se baser sur des conventions, que chaque projet doit suivre pour bénéficier de la richesse de l’outil. Largement adopté, Maven est devenu un standard de fait, et un développeur qui arrive sur un projet Maven retrouve naturellement ses marques et exécute sans attendre la commande universelle « mvn install »

Nicolas De Loof