Développement logiciel agile : informations sur l'outillage

Introduction

De plus en plus d’entreprises et d’équipes s’intéressent aux outillages modernes permettant d’industrialiser et automatiser leurs productions logicielles. Et récemment, à plusieurs reprises, lors d’échanges avec des clients, j’ai pu me rendre compte que les confusions sont nombreuses entre les différents outils, leurs rôles, leurs intérêts, leurs interactions, etc …

Je vous propose donc ce petit article pour essayer de recenser ces outils avec des présentations rapides et succinctes. Nous parlerons donc de :

• Gestionnaire de sources et de versions
• Système de build
• Gestionnaire de repositories
• Séquenceur pour intégration continue

Précisions

Pour certains outils, je préciserai le « mode » d’installation et d’utilisation :

• « Serveur » : il s’agit d’un service qui s’installe sur une machine et fonctionne en permanence. Il n’utilise pas le CPU de la machine en permanence, mais il est exploitable à distance à tout instant, généralement au travers du serveur WEB qu’il contient
• « Utilitaire » : il s’agit là  d’un outil qui doit être installé sur la machine mais qui est « passif ». Il est accessible par son chemin complet ou grâce au « PATH » du système d’exploitation. Il est utilisé à la demande, soit par l’utilisateur avec une ligne de commande en console, soit par des scripts regroupant plusieurs opérations successives

Je parlerai également d’ « artifact ». Ce sont des livrables importés dans notre projet et disponibles sur des dépôts appelés « repositories ». Ces artifacts sont en quelques sortes des librairies. Un artifact est essentiellement identifié par le groupe auquel il appartient (« groupId »), son identifiant au sein de ce groupe (« artifactId »), et son numéro de version (« version »). Un artifact dans sa version « n » est donc unique.

Gestionnaire de sources et de versions

Objectifs : stocker des fichiers sources, les partager et échanger entre les membres d’une équipe, les archiver, les « versionner », les « tagger » (repère à un instant donné), les retrouver ultérieurement, etc …

Mode : serveur

Outils :
Je ne mentionne ici que les outils client-serveur (je ne parlerai donc pas de PVCS, un des premiers SCM).

• CVS : un peu ancien et désuet (je suggère de passer à SVN)
• SVN ou Subversion : probablement le plus répandu actuellement (fondation Apache)
• Git ou Mercurial : la nouvelle génération, très souples et puissants, mais peut-être un poil complexe selon les besoins de l’équipe
• A noter que ces outils séparent la création des commits et leurs publication, offrant une plus grande souplesse pour chaque développeur ainsi que la possibilité de travail hors ligne ou en l'absence du dépôt central
• Rational ClearCase (que je ne connais pas) : outil propriétaire IBM, semble pas mal répandu, puissant mais apparemment beaucoup plus lourd et lent que les autres (source).

D'après moi, un SCM (Source Control Management) doit être simple à installer et administrer, et ne doit pas gêner les développeurs dans leur quotidien, notamment pour les (permanents) refactorings (ce qui ne semble pas être le cas de ClearCase).

Système de build

Introduction : Les éditeurs (IDE) classiques comme Eclipse ou NetBeans permettent de compiler les sources. Mais désormais, il n’est plus question de s’en satisfaire, ces solutions ne vont pas dans le sens de l’industrialisation et de l’automatisation. Il est donc impératif de mettre en place un système de build permettant l’automatisation de la construction logicielle.

Objectifs : Ces systèmes doivent permettre par exemple de compiler les sources, jouer les tests unitaires, générer des archives JAR ou WAR, etc … Ils doivent également permettre de gérer de façon précise et rigoureuse les dépendances, en liant notre projet à des « artifacts ».

Mode : utilitaire

Outils :

• Ant
• Maven

Ant

Ant (fondation Apache) est un système de « scripts ». Basé sur un fichier « build.xml », il permet de définir une succession d’actions basiques, soit des actions intrinsèquement connues par Ant, soit des commandes externes. On peut ainsi copier des fichiers (avec inclusions et exclusions), lancer une compilation, générer une archive JAR, etc …


Ivy (fondation Apache) est un utilitaire de gestion de dépendances. Ajouté à Ant, il permet de spécifier les artifacts externes nécessaires à notre projet.

Ant permet quasiment de tout faire, mais il faut souvent le faire soi-même. De plus, les solutions de chacun sont différentes, il n’y a ni normes, ni homogénéité, un nouvel arrivant dans l’équipe devra donc se former à la solution « maison ».

Maven

Contrairement à Ant, Maven est un outil spécifiquement développé pour la construction logicielle. La description du projet se fait dans un fichier « pom.xml ».


Maven possède de façon intrinsèque un « cycle de construction » définissant une succession d’étapes (« goals » dans le langage Maven) pour la génération et la mise à disposition d’un livrable. En simplifiant, les principales étapes sont la compilation, l’exécution des tests, le packaging, et l’envoie du livrable sur un repository. Evidemment, si l’une de ces étapes échoue (les tests unitaires par exemple), le cycle de construction est interrompu.

En fait, Maven est basé sur des conventions comme le cycle de construction, mais également l’emplacement des fichiers, etc … Ces conventions peuvent être modifiées, mais la bonne pratique consiste à les suivre, la génération du projet est alors grandement simplifiée.

Par exemple, pour un projet sans dépendances, avec uniquement des sources Java (tests et prod), sur base d’un fichier pom.xml minimaliste (quelques lignes), Maven sera capable de générer un JAR après compilation des sources et exécution des tests.

Maven intègre une gestion des dépendances, pratique mais finalement indispensable. Il est donc facile de préciser les artifacts dont notre projet a besoin pour ses différentes étapes (compilation, tests, exécution).

Un autre point fort de cet outil est qu’il est possible de lui ajouter des plugins selon les besoins de notre projet. En fait, dans Maven, tout est plugin mais certains sont intégrés d’office. Un plugin va venir se greffer sur une étape (« phase ») donnée lors de la construction. On pourra ainsi générer un ZIP avec un contenu personnalisé (plugin « assembly »), déployer des WAR ou EAR sur nos serveurs d’applications (plugins spécifiques), etc …

Maven est donc un outil très structurant (par exemple par le découpage de notre application en modules), et apporte une certaine normalisation dans les développements logiciels. Si les conventions ont été respectées, et si la mise en œuvre est correcte, un nouvel arrivant dans l’équipe n’aura aucun mal à rentrer dans le projet et être rapidement productif !

Gestionnaire de repositories

Objectifs : plusieurs repositories « publiques » existent sur internet pour la gestion et la récupération d' "artifacts" (voir explications en introduction), mais l’installation de son propre gestionnaire de repositories apportera les possibilités suivantes :

• Déployer les artifacts « maison », produits en interne, par exemple pour les mettre à disposition des autres équipes ou des autres services (intégration, qualification, production)
• Rendre accessible sous forme d’artifact des librairies qui ne le sont pas. On parle parfois de « maveniser » une librairie. Par exemple, certains librairies sont disponibles sur internet uniquement sous forme de JAR, on peut alors les « injecter » dans notre gestionnaire de repositories en leur choisissant une identification « groupId – artefactId – version », les rendant alors disponibles pour Maven ou Ivy
• Faire office de « proxy » pour tous les développeurs de l’entreprise en stockant « en cache » les artifacts disponibles sur internet lors de leur premières demandes, apportant ainsi aux équipe un gain de rapidité et une meilleure autonomie (en cas de coupure internet par exemple)

Mode : serveur

Outils :

• Archiva : probablement le plus ancien et peut-être le moins installé désormais
• Nexus : peut-être le plus récent
• Artifactory : également très répandu

Tous ces gestionnaire permettent la gestion de plusieurs repositories au sein du même serveur : interne, externe, snapshot, release, repositories virtuels, etc …

       

Séquenceur pour intégration continue

Objectifs : le principal objectif d’un séquenceur est de déclencher des builds (« jobs ») et de notifier les utilisateurs (les développeurs) des résultats, ou plus précisément des passages en échec et des retours à la normale

Mode : serveur

Outils :

• Jenkins (dernière version il y a 4 jours), sans aucun doute le plus connu, le successeur et remplaçant de Hudson, (dernière version en mai dernier)
• Continuum, encore un outil fourni par la fondation Apache, semble abandonné, la dernière version date de septembre 2011, mais on le rencontre encore dans bon nombre d'entreprises

                 

Précisions : les builds peuvent être déclenchés de différentes manières :

• Sur changement, en surveillant le dépôt de sources (SVN ou autre) (exemple : toutes les 15’ s’il y a eu un changement)
• Pratique pour mettre en place une véritable intégration continue en exécutant le plus souvent possible un build « compilations+tests » permettant de notifier au plus vite les développeurs en cas d’effets de bords d’une récente modification
• Cycliquement (par exemple : toutes les nuits à 02h00)
• Généralement utilisé pour exécuter un build complet de toutes les artifacts et de l’ensemble de l’application, donc probablement plus long, et permettant de mettre à disposition une nouvelle version tous les jours, par exemple pour les tests d’acceptance par un Product Owner
• Manuellement
• Cet usage un peu dérivé du séquenceur permet de mettre à disposition des utilisateurs (développeurs, intégration, déployeurs, …) des opérations simplifiées (un clic) et plus accessibles (il suffit d’avoir accès au séquenceur par son interface WEB sans avoir besoin d’un poste équipé de droits et d’outillages spécifiques)
• A la suite d’un autre build
• Evidemment utile pour bien enchainer les builds de librairies ou applications dépendantes les unes des autres

Conclusion

Tous ces outils peuvent être mis en place indépendamment les uns des autres et peuvent être interchangés (Nexus à la place de Archiva, SVN à la place de CVS, Maven à la place de son système actuel basé sur Ant, etc …) sans que cela impacte les autres outils mis en place.

Par contre, la mise en place d’un outil (Maven par exemple) nécessitera forcément quelques modifications de l’existant et une adaptation des méthodes et des pratiques actuelles de l’équipe, mais ce sont des investissements dont le ROI rapide ne fait aucun doute !

Il faut également comprendre que ces outils sont indépendants mais étroitement liés. Par exemple, on peut commencer à travailler avec Maven sans gestionnaire interne de repositories mais ce dernier deviendra rapidement indispensable. Une équipe peut également se passer d’un séquenceur mais elle perd le bénéfice d’une intégration continue lui donnant un retour rapide sur la qualité de sa production.

J’espère que cet article permettra d’éclairer ceux qui se perdent un peu, et bien sûr, n’hésitez pas à réagir en laissant des commentaires ou des questions.