Problématique de déploiement et de traçabilité avec Hudson
Hudson est le serveur d’intégration que nous préconisons et mettons en place chez nos clients. Récemment, au sein d’un atelier de génie logiciel sur lequel nous intervenons, nous avons rencontré quelques problématiques de déploiement. Cet atelier s’occupe de fournir des solutions transverses et du support sur l’intégration continue pour environ une dizaine de milliers d’utilisateurs.
En terme de livrable, le produit Hudson se compose d’un noyau (core) et d’un ensemble de plugins se greffant sur le noyau pour ajouter un ensemble de fonctionnalités. Le noyau de Hudson se livre sous forme d’une archive Web (hudson.war) et les plugins sous forme de fichiers zip avec une extension reconnaissable par Hudson (.hpi). L’archive Web peut se déployer très simplement dans un container Web comme par exemple le serveur Jetty ou le serveur Tomcat. Mais cette archive Web est dotée également d’une fonction d’auto déploiement par le fait qu’elle inclue un serveur Jetty dans son archive permettant un startup immédiat. Les plugins quand à eux seront copiés dans l’espace de travail de Hudson. Depuis peu, Hudson propose également la possibilité de packager ses plugins dans l’archive Web (WEB-INF/plugins). Pour des questions de traçabilité; il est recommandé de livrer aux utilisateurs l’archive initiale, l’ensemble des plugins et la procédure de création de l’archive regroupant les deux.
Derrière ces différents mode de packaging, Hudson est capable, une fois installé et déployé, de se mettre à jour très facilement depuis son interface d’administration. Il est possible par simple clique de mettre à jour une nouvelle version d’un plugin et même du noyau (s’il est installé en tant que service windows) dans le cas où une version supérieure serait sortie. Cette approche ouverte est très puissante. Néanmoins, cela peut poser des problèmes de maintenance dans certaines situations d’industrialisation.
En effet, pour une installation de Hudson centralisée, il est très simple d’activer la sécurité et de restreindre l’accès au gestionnaire de mise à jour pour les personnes ayant une habilitation « Administrateur ». Mais dans un contexte de fournisseur de solutions transverses où les utilisateurs réceptionnent les livrables Hudson avec un libre choix d’installation et de configuration des produits, il devient alors très complexe de leur fournir une maintenance car ils peuvent utiliser des versions du noyau et des plugins non recommandés. Et comment ne pas inciter un utilisateur a se mettre à jour ?
On constate ainsi que Hudson fait partie des logiciels dit nouvelle génération avec des procédures d’installations et de mise à jour très légères. A terme, l’atelier transverse ne peut pas connaître et supporter toutes les versions des plugins et du noyau de Hudson. On se dirige alors vers une responsabilité des groupes utilisateurs. Si certaines équipes décident d’utiliser telle ou telle version pour certaines raisons, l’atelier pourra les accompagner mais ne pourra pas fournir des solutions de maintenance.
