Venant de réaliser une migration d’Apache Archiva vers Sonatype Nexus, sur un environnement significatif, je vous livre la démarche utilisée, les astuces et écueils rencontrés.
L’article étant un peu long il est découpé en 3 parties. Aujourd’hui je vous présente le contexte pour vous mettre l’eau à la bouche. Demain vous pourrez découvrir la migration, les mains dans le cambouis. Je terminerai jeudi sur le bilan et les gains pour les projets qui l’utilisent.
Merci à Tarpoon, C’est pas dur et toute l’équipe pour leur aide.
<Disclaimer> Etant membre de l’équipe du projet Archiva (rarement actif il faut bien l’avouer) je devrais essayer de le défendre becs et ongles tout au long de l’article. Etant consultant avant tout, j’espère garder une grande objectivité. Je vous laisse juger …</Disclaimer>

Le contexte

Le contexte de la migration est le suivant : une grande entreprise, avec plusieurs dizaines de projets JEE de toutes tailles (de la petite souris au gros paquebot — NON ! je n’ai pas parlé du Titanic !! 😉 ), et au moins 200 développeurs actifs simultanément en pleine journée.

La majeure partie des projets utilise Maven. Pour aider les équipes des études à faire mieux et plus vite nous offrons toute une infrastructure dédiée à l’intégration continue. Un serveur du genre Mister Muscles (Bi-Xeon QuadCore avec 16Go RAM sous RedHat Enterprise Linux 5.1), héberge un serveur d’intégration continue Atlassian Bamboo avec à son bord (environ) : 110 builds d’intégration continue, 40 builds de sites maven (quotidien), 20 builds Sonar (quotidien). Il héberge aussi un gestionnaire de référentiels d’artifacts Maven (Archiva 1.1.1 avant la migration) qui abrite un peu moins d’une dizaine de référentiels locaux et qui fait proxy-cache d’une vingtaine de référentiels externes. Ces référentiels représentent tout de même 400Go de données. La majeure partie est utilisée par le référentiel des snapshots (200Go) et par le référentiel des releases (150Go). Pour comprendre ces tailles il faut savoir que certains projets produisent (pour de bonnes ou de mauvaises raisons) des EARs pouvant faire jusqu’à 100Mo. En rajoutant la taille des WARs et JARs qui composent ces EARs, un projet occupent rapidement beaucoup de place à chaque déploiement.

Pourquoi changer ?

Cela faisait plusieurs mois que la stabilité de notre environnement d’intégration ne nous satisfaisait pas. Nous avions des temps d’exécution très variables d’un build à un autre, et par intermittence nous avions des erreurs qui n’étaient pas liées aux projets mais à l’infrastructure mise en place :

• Erreurs 500 ou 502 sur des uploads sur Archiva sans raison apparente (j’ai cherché sans succès la cause),
• Plantage complet d’Archiva ou d’un autre soft après avoir dépassé le nombre maximum de descripteurs de fichiers ouverts pour l’utilisateur. Il faut concéder que ces outils manipulent beaucoup de fichiers (téléchargements, uploads, et autres manipulations sur un grand nombre d’artifacts). Archiva dépasse allègrement la limite par défaut des 1024 descripteurs ce qui nous avait forcé à l’augmenter. Mais même à 2048 il lui arrive encore occasionnellement de la dépasser.
• Récupération de snapshots impossible si le référentiel local utilisé par Bamboo avait été vidé juste avant. Cela entraînait régulièrement l’échec des builds de sites Maven ou Sonar.

A tout cela il faut rajouter le récent bug d’Archiva (MRM-1136) sur lequel j’ai passé plusieurs heures en diagnostic (problème sur la gestion des meta-données émises par Maven 2.1.0) et qui allait nous obliger à upgrader rapidement vers une version 1.1.4 ou 1.2.

Tous ces problèmes même s’ils n’étaient que ponctuels, dévalorisaient fortement l’intégration continue. Comment reprocher à un projet de ne plus en tenir compte si cette dernière vous envoie des faux négatifs ? Ils ont déjà bien assez de travail pour traiter les véritables erreurs. L’environnement d’intégration continue doit être aussi fiable qu’une horloge suisse.

Il était donc temps pour nous de réagir.

Soit nous mettions à jour Archiva, ce qui représentait un coût non négligeable en recette mais qui n’apporterait pas beaucoup d’améliorations. En dehors de l’incompatibilité avec Maven 2.1.0, rien ne nous laissait penser que les nouvelles versions corrigeraient certains autres de nos problèmes. Et du coté des évolutions, ces dernières se font rares sur Archiva en ce moment (faute de moyen).

Soit nous faisions le pari de prendre un autre outil avec le risque de rencontrer de nouveaux écueils.

Les retours de la communauté à propos de Nexus sont très encourageants. De plus, celui-ci en version pro ouvre de nouvelles possibilités à l’avenir avec ses fonctionnalités novatrices :

• Référentiels de recette (staging repository) pour mettre dans un sas les artifacts en cours de validation avant leur livraison,
• Possibilité de faire proxy pour les updates sites eclipse. Actuellement nous le faisons à la main cependant cela est coûteux, compliqué (je déteste P2), et inintéressant.

Puisque le jeu semblait en valoir la chandelle, nous avons décidé de tenter notre chance avec Nexus…