Devrions-nous utiliser Nexus ou Artifactory pour un Maven Repo?
Nous utilisons Maven pour un processus de construction volumineux (> 100 modules). Nous avons stocké nos dépendances externes dans le contrôle de source et les avons utilisées pour mettre à jour un référentiel local.
Cependant, nous sommes prêts à passer à un référentiel local pouvant mettre en cache la centrale de manière à ne pas télécharger de manière proactive toutes les tierces parties (mais nous pouvons toujours avoir un référentiel local à extraire). De plus, nous souhaitons publier nos artefacts de construction internes à partir d'une construction nocturne afin que les développeurs ne soient pas obligés de construire le monde.
Nous examinons Nexus et Artifactory. Quelles sont les raisons pour préférer l'un sur l'autre? Y a-t-il d'autres personnes que nous devrions envisager?
Je ne connais pas Artifactory, mais voici mes raisons d'utiliser Nexus:
- Installation simple morte (et depuis 1.2, mise à jour morte simple aussi)
- Très bonne interface web
- Facile à entretenir, presque pas de frais administratifs
- Fournit des flux RSS d'artefacts et d'erreurs cassés récemment installés
- Il peut regrouper plusieurs référentiels, ce qui vous permet de mettre en miroir plusieurs sources tout en ne nécessitant qu'une ou deux entrées dans votre fichier settings.xml.
- Le déploiement à partir de Maven fonctionne immédiatement (pas besoin de hack WebDAV, etc.).
- c'est gratuit
- Vous pouvez rediriger les chemins d’accès (c’est-à-dire que certains fichiers pom.xml endommagés requièrent "a.b.c" à partir de "xxx"). Au lieu de corriger le POM, vous pouvez corriger le bogue dans Nexus et rediriger la demande à l'endroit où se trouve réellement l'artefact.
Je suis sûr que si vous ne parlez que de stocker des binaires à partir de "mvn deploy "les deux iront bien.
Nous utilisons très souvent Artifactory avec toutes les mises à niveau en cours de route. Nombreux projets, nombreux instantanés déployés et référant externe par proxy. Pas un seul problème. J'ai du mal à expliquer comment d'autres personnes rencontrent des problèmes avec sa base de données, son indexation ou quoi que ce soit d'autre. Rien de tel ne nous est jamais arrivé. De plus, Artifactory permet de stocker des données sur un disque et d'utiliser uniquement une base de données pour stocker des métadonnées, ce qui est assez flexible ( voir plus ici ).
Ce qui différencie ces applications very est leur approche de l'intégration avec d'autres outils et technologies de construction. Nexus et Sonatype sont pratiquement bloqués sur Maven et m2Eclipse. Ils ignorent tout le reste et n’ont commencé à travailler que récemment sur leur propre intégration propriétaire de Hudson (voir leur Webinaire Maven ). EDIT: Ce n'est plus vrai à partir de 2017 Nexus donne n support beaucoup plus large pour les autres outils de construction Fin de l'édition
Artifactory fournit un formidable support intégration de Hudson, TeamCity et Bamboo , et Gradle / Ivy . Ainsi, alors que Nexus ne vous donne rien une fois que vous sortez de la "zone de confort" de Sonatype (Maven, m2Eclipse), Artifactory s’adapte parfaitement à tous les outils de construction majeurs et collabore avec eux.
En fait, être capable de déployer des artefacts de construction à partir de Hudson, une fois le travail terminé, et non par "mvn deploy "est une énorme différence: Artifactory Hudson plug-in effectue un déploiement atomique de tous les artefacts en une fois, uniquement lorsqu'un travail de construction est terminé." mvn deploy "s'exécute après chaque module et peut déployer un ensemble partiel d'artefacts si un travail de construction échoue au milieu. Le déploiement à partir de Maven à l'achèvement du module et non à partir d'un serveur de construction à l'achèvement du travail est vraiment une mauvaise chose à faire.
Comme vous le voyez, Artifactory pense "en dehors de la boîte" tandis que Nexus pense "dans la boîte" et ne se soucie que des artefacts Maven et Maven.
Un autre élément qui rend Artifactory plus accessible est leur solution Artifactory Online basée sur le cloud . Pour environ 80 dollars par mois, vous disposez de votre propre instance Artifactory. Inutile de lui dédier un serveur.
Artifactory possède une simple et directe REST) , je ne sais pas comment cela fonctionne pour Nexus. Modifier Nexus a également une REST que vous pouvez également utiliser facilement.
En résumé, pour le stockage de base des artefacts Maven, je pense que les deux vont bien. Mais alors que Nexus cesse de se limiter strictement à un "gestionnaire de référentiel Maven", Artifactory continue, constituant un "stockage binaire" général pour les binaires de tout type, quel que soit l'outil de construction et le serveur CI.
Artifactory prend en charge les deux systèmes de fichiers et systèmes de stockage de base de données. Le stockage est basé sur une somme de contrôle et les fichiers binaires identiques ne sont stockés qu'une seule fois, peu importe le nombre de fois où ils apparaissent dans le référentiel, ce qui rend Artifactory plus efficace en termes de stockage. Déplacer et copier sont également très économiques en raison de cette architecture (dans Nexus, il n'y a pas de REST pour le déplacement/la copie - vous devez déplacer des éléments sur le système de fichiers, puis exécuter des actions correctives sur le dépôt pour laisser il sait que le contenu a changé).
Artifactory constitue un autre facteur de différenciation important et intègre de manière unique Hudson et TeamCity pour la capture d'informations sur les artefacts déployés, les dépendances résolues et les données d'environnement associées aux exécutions de génération, ce qui permet une traçabilité complète de la génération.
Artifactory stocke les artefacts dans une base de données, ce qui signifie que tous les artefacts disparaissent en cas de problème. Nexus utilise un fichier plat pour vos précieux artefacts afin que vous n'ayez pas à vous soucier de leur perte.
Si vous avez besoin des fonctionnalités "Pro" de l'une ou de l'autre (p. Ex. Mise en pension, promotion d'artefacts, NuGet), vous devez envisager les différents modèles de tarification affichés sur leurs sites Web.
En résumé:
- Artifactory Pro
- vous payez par serveur
- vous pouvez payer plus pour des heures de service plus longues
- Nexus Pro
- vous payez par siège , c’est-à-dire combien de développeurs téléchargent des artefacts
- le service de support est disponible du lundi au vendredi de 8h00 à 20h00 (heure de l'Est), peu importe le prix
Quel que soit le nombre de vos utilisateurs, Nexus Pro propose un service de support largement équivalent au "Silver Value Pack" 750 $/an d’Artactory.
7 450 $/an vous achètera environ 67 sièges Nexus Pro (1 à 50 @ 108 $, le reste à 120 $).
Sur le prix et le support, Nexus Pro est donc logique jusqu’à 67 utilisateurs. Artifactory devient alors la solution la moins chère.
Si vous faites tout le soutien en interne; Cependant, ce point magique concerne environ 23 utilisateurs (l'offre d'assistance la plus élémentaire proposée par Artifactory est de 2 750 USD/an).
J'ai récemment fait des recherches sur Artifactory 2 et Nexus 1.3. Je vais énumérer ici les principales différences que j'ai trouvées:
- Artifactory stocke les métadonnées et éventuellement les fichiers dans la base de données, Nexus écrit directement dans le système de fichiers. Il y a des pros. et contre. pour chaque approche. La base de données prend en charge les transactions, tandis que dans FS sont directement accessibles.
- Artifactory a des exigences système plus élevées en particulier pour l'espace disque.
- Artifactory prend en charge LDAP, tandis que Nexus ne l’a que dans sa version payante. D'autre part, le plug-in LDAP gratuit pour Nexus est disponible sur le code Google.
La comparaison la plus complète: http://binary-repositories-comparison.github.io/
Vous devez utiliser Artifactory Sa version la plus récente était un véritable saut. Vous pouvez sauvegarder de manière incrémentielle vos référentiels, ce qui signifie que vous pouvez enregistrer tous vos artefacts et les conserver. Son interface utilisateur est facile à utiliser et très facile à configurer. sa nouvelle version 2.0
Du point de vue des apprenants, je note quelques différences spécifiques entre les deux.
- Le déploiement Sonatype .war n'est pas pris en charge sur le serveur d'applications Jboss pour le moment, bien qu'il soit exécuté sous Tomcat.
- Sonatype ne m'offre pas actuellement une Amazon Machine Image (AMI), que je pourrais rapidement mettre en place et tester.
- Bitnami fournit une AMI artifactory qui ne prend que quelques minutes pour se lever et quelques minutes de plus pour la configuration, peut-être plusieurs dizaines de minutes, en fonction de vos objectifs.
- Artifactory propose une version SaaS d'Artifactory dans le cloud) afin que vous puissiez vous concentrer sur vos tâches plutôt que sur l'infrastructure.
- Je n'ai pas d'expérience avec Nexus, mais j'ai trouvé Artifactory très intuitif et facile à configurer, du moins au début.
- Ajout - Je note que le Guide de l'utilisateur Artifactory, qui peut convenir à un professionnel expérimenté, est un peu léger pour certaines explications plus en profondeur. Par exemple, en commençant, on décompresse puis on ajoute un référentiel, dit JBoss EAP Enterprise Repo de RedHat. Tout se passe bien, mais lorsque j'ai essayé d'afficher les artefacts importés, Artifactory signale zéro artefact? Aucune erreur ou mise en garde, je cherche donc maintenant une explication. Est-ce normal ou pas normal? Une explication simple dans le doco peut rapidement en indiquer une dans la bonne direction. Étant un bon contributeur, j'ajoute ces commentaires au projet pour le bénéfice d'autres personnes.
Toute politique ou religion confondue, l’octroi de licences fait la différence pour certaines organisations.
Nexus est GPL à présent AGPLv3 et maintenant Licence publique Eclipse (EPL) .
Artifactory est Apache sous licence LGPLv sous licence à partir de la version 2.1 du produit.
Vous voudrez peut-être aussi considérer Archiva , juste pour comparer. C'est Apache 2.0 sous licence.
Je vois que l'utilisation de Nexus est en croissance, tandis que l'utilisation d'artifcatoire reste généralement à plat.
La photo est prise à partir d'ici http://blog.sonatype.com/2014/11/42000-nexus-repository-managers-and-growing/
Il existe également une matrice-comparaison http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix