Artifactory vs. Nexus vs. ProGet

Hinweis: Die erste Version dieses Artikels wurde im September 2018 veröffentlicht. Seitdem hat sich viel verändert. Wir haben alle drei Produkte umfassend erneut geprüft, um den ursprünglichen Artikel zu aktualisieren und diese Änderungen aufzunehmen.

Die Zeiten, in denen wir unser Release auf einem gemeinsamen Laufwerk oder einem öffentlichen FTP-Server ablegen und uns dennoch professionelle Softwareentwickler nennen konnten, sind vorbei. Unseren Quellcode können wir in einem ausgereiften Ökosystem von Repository-Managern wie Bitbucket oder GitHub problemlos mit Versionskontrollsystemen verwalten. Bei unseren Produkten – den Ergebnissen unserer Builds – stehen wir jedoch vor einem Problem. Binary Repository Manager (BRM) unterstützen die Nachverfolgbarkeit, indem sie eine zentrale, verlässliche Quelle für Binärdateien bereitstellen. Außerdem können sie Durchlaufzeiten verkürzen, indem sie redundante Builds vermeiden.

Im BRM speichern wir unsere DLLs, JARs und Container Images. Ein BRM kann euch beim Sicherheits- und Lizenzmanagement unterstützen, indem es als Proxy für öffentliche Package Manager wie pip oder apt-get dient.

Das Experiment

Aber für welchen solltet ihr euch entscheiden? Und wie trefft ihr diese Entscheidung? Wir haben die Vor- und Nachteile der beliebtesten Binary Repository Manager untersucht. 

In unserem Experiment haben wir folgende Lösungen verglichen: Artifactory von JFrog (v.7.7.3), Nexus von Sonatype (v.3.26.1) und ProGet von Inedo (v.5.3.10).

Sie werden alle aktiv weiterentwickelt, unterstützen mehrere Repository-Typen und bieten nach dem Erwerb einer Lizenz Support-Services. 

Wir haben die Binary Repository Manager anhand der folgenden Kriterien verglichen, die das gesamte Spektrum von Dev bis Ops abdecken:

• Repositories

• Flexibilität und Durchsuchbarkeit

• REST API und Tooling

• CI/CD-Promotion

• Bereinigung

• Benutzerauthentifizierung

• Benutzer- und Zugriffsmanagement

• Speicher

• Erweiterbarkeit

So erhielten wir die breiteste Grundlage, um einen Gewinner auszuwählen. Die Preisgestaltung wurde bewusst aus dem Vergleich ausgeklammert, da die Zahlungsmodelle je nach angebotenen Funktionen stark variieren. Das Experiment wurde in der gängigsten Umgebung durchgeführt – einem Single-Node-Setup mit einer Pro- oder Basic-Lizenz. Damit decken wir die meisten Anwendungsfälle ab, die wir bei unseren Kunden sehen.

Testlizenzen

Es gibt selten eine Lösung, die für alle passt, und BRMs sind keine Ausnahme. Deshalb solltet ihr jede Lösung ausprobieren, um zu sehen, wie gut sie zu eurer Arbeitsweise passt. 

Ihr könnt unsere Installationsskripte nutzen, die alle notwendigen Informationen enthalten, um schnell mit der Evaluierung zu starten.

Artifactory

Registriert euch einfach auf der Website für eine Testlizenz, die ihr per E-Mail erhaltet. Der Testzeitraum beträgt 30 Tage und kann durch Kontaktaufnahme mit dem Vertrieb verlängert werden. 

Nexus

Seit der letzten Überarbeitung dieses Artikels hat das Nexus-Team die Verteilung seiner Testschlüssel deutlich verbessert. Besucht einfach die Website und fordert eine 14-tägige Testversion an. Kurz darauf erhaltet ihr Anweisungen für den Einstieg in eurem Posteingang. 

ProGet

Um eine Testlizenz für ProGet zu erhalten, besucht https://my.inedo.com und fordert in der Weboberfläche einen Testlizenzschlüssel an. Der Testzeitraum beträgt 30 Tage.

Gewinner

Artifactory und ProGet gewinnen diese Kategorie knapp, da ihr Testzeitraum doppelt so lang ist wie der von Nexus. Die Beschaffung war bei allen drei Kandidaten gleich schnell, und alle bieten Docker-Images für eine schnelle Evaluierung.

Entwicklung

Repositories

Die Unterstützung mehrerer Repository-Typen ist entscheidend, wenn in eurer Organisation verschiedene Sprachen auf unterschiedlichen Plattformen zum Einsatz kommen. Nachfolgend findet ihr eine Liste der Repository-Typen, die von den einzelnen Plattformen unterstützt werden. Vergleicht sie mit euren Anforderungen.

X = kommerzieller Support C = Community-Support U = inoffizieller Support „()“ bedeutet Unterstützung bei der letzten Überprüfung „{}“ bedeutet inoffizielle Unterstützung über andere Repository-Typen Grün bedeutet, dass die Unterstützung seit der letzten Evaluierung hinzugefügt wurde

Weitere Informationen findet ihr auf den jeweiligen Websites der Anbieter:

• Artifactory-Typen: JFrog Artifactory unterstützt wichtige Pakete, Build-Tools und CI-Server

• Nexus-Typen

• ProGet-Feeds

• ProGet-Feeds in Entwicklung

Artifactory

Artifactory bietet standardmäßig eine enorme Anzahl an Repositories. JFrog erlaubt keine benutzerdefinierten Repositories.

Nexus

Seit der letzten Überprüfung hat Nexus fünf Community-Repository-Typen zu offiziell unterstützten Typen hochgestuft. Außerdem sind fünf weitere Community-Repository-Typen hinzugekommen, wodurch sich die Zahl der unterstützten Repositories in den vergangenen zwei Jahren deutlich erhöht hat.

ProGet

ProGet bietet die wenigsten Repository-Typen und keine Möglichkeit, eigene bereitzustellen. Erwähnenswert ist jedoch, dass das Unternehmen neue Typen auf Anfrage der Community unterstützt. Mehr dazu.

Gewinner

Nach der letzten Überprüfung gewann Artifactory dank seiner Vielzahl unterstützter Repository-Typen. Seitdem hat Nexus deutlich aufgeholt, sodass sich beide die Medaille in dieser Kategorie teilen.

Artifactory liegt bei der Anzahl unterstützter Repository-Typen leicht vorn, aber Nexus bietet OSGi-Schnittstellen, mit denen ihr bei Bedarf eigene Repository-Typen erstellen könnt.

Flexibilität / Durchsuchbarkeit

Wenn alle eure Binärdateien an einem Ort liegen, kann die schiere Anzahl an Artefakten überwältigend sein. Das Auffinden des exakt benötigten Artefakts kann zur Herausforderung werden. Manche Organisationen nutzen Workflows, die von den standardmäßigen Repository-Layouts nicht unterstützt werden – hier ist Flexibilität eine Stärke.

Artifactory

Artifactory verfügt über ein integriertes Konzept für benutzerdefinierte Layouts, mit dem ihr eigene Layouts für verschiedene Repository-Typen erstellen könnt. Jedes Repository hat einen Typ (Maven, NPM usw.) und ein damit verknüpftes Layout. Seid bei benutzerdefinierten Layouts vorsichtig, denn die meisten clientseitig eingesetzten Repository-Technologien (wie Gradle, PIP usw.) können nicht automatisch auf ein nicht standardmäßiges Layout schließen. Das ließe sich beheben, wenn Artifactory Layouts on the fly für den Endpunkt übersetzen würde. Leider ist diese Funktion jedoch nicht implementiert und steht auch nicht auf der Pipeline.

Bei der Suchbarkeit bietet Artifactory viele verschiedene Möglichkeiten. Direkt über die UI könnt ihr nach Name, Prüfsumme, Binärtyp, Eigenschaften und mehr suchen. Wenn ihr alle Suchmöglichkeiten kombinieren möchtet, könnt ihr Artifactory über die eigene Abfragesprache AQL durchsuchen. Diese ist nicht über die UI verfügbar, sondern nur über die REST API und Tools.

Nexus

Nexus bietet keine Flexibilität bei Layouts, ermöglicht jedoch Deployments außerhalb des Layouts. In diesem Fall könnt ihr die Artefakte nur über die REST API und nicht beispielsweise über Maven oder Gradle abrufen.

Die Suchfunktionen in der UI sind mit Artifactory vergleichbar und erlauben mehrere gleichzeitig aktive Suchkriterien – für Name, Attribute, Version und Prüfsumme.

Seit 2018 steht eine Search API zur Verfügung, die dieselben Funktionen wie die UI nutzt. So könnt ihr anhand mehrerer Suchkriterien nach Artefakten suchen und sie herunterladen. Ein großer Vorteil für die Automatisierung.

ProGet

ProGet kennt keine Layouts. Stattdessen ladet ihr die benötigten Dateien zu ProGet hoch, das sie entsprechend dem Repository-Typ in die richtige hierarchische Struktur einordnet. Wenn ihr mit dieser strikten Dateiverwaltung leben könnt, ist dies ein sauber implementiertes Detail, das Komplexität reduziert.

Die Suchfunktion ist an einen bestimmten Repository-Feed gebunden. Ihr müsst also wissen, wo ein bestimmtes Artefakt gespeichert ist, bevor ihr es abrufen könnt. In unserem Test schien das Suchfeld nur nach dem Namen des Artefakts zu funktionieren.

Gewinner

Artifactory gewinnt dank seiner eigenen Abfragesprache AQL, dicht gefolgt von Nexus. Sowohl Nexus als auch Artifactory bieten viele Suchmöglichkeiten und die Freiheit, Pakete außerhalb des Standardlayouts zu deployen. ProGet wirkt bei der Suchfunktion sehr eingeschränkt und unausgereift und bietet keine Flexibilität beim Layout – falls ihr diese benötigt.

Interaktionen: REST API + Tools

Eine nutzbare Weboberfläche ist für die Interaktion durch Menschen hervorragend. In einer modernen Softwareentwicklungspipeline laufen die meisten täglichen Interaktionen jedoch in Pipelines ab. Zwar unterstützen alle getesteten Lösungen Uploads über Tools wie Gradle und NPM, doch Vorgänge wie das Erstellen von Repositories und Promotions gehören noch nicht zum Standardumfang. Eine leistungsfähige REST API und CLI-Tools zur Automatisierung eurer täglichen Arbeit können eurem Team daher großen Mehrwert bieten.

Artifactory

Artifactory verfügt über eine umfassend dokumentierte REST API, die ihr hier findet.

Sie unterstützt nahezu alle denkbaren Vorgänge – von alltäglichen Aufgaben wie dem Hochladen von Artefakten über die Verwaltung von Benutzern bis hin zur Konfiguration von Reverse Proxies. Auch die UI nutzt die API intensiv, was für die Reife des Tools spricht.

Zusätzlich bieten sie die Anwendung „jFrog CLI“, die auf mehrere ihrer Produkte einschließlich Artifactory zugreifen kann, falls ihr keinen REST-Client zur Hand habt. jFrog CLI unterstützt unter anderem das Hochladen, Herunterladen, Verschieben und Kopieren von Artefakten sowie die Bearbeitung von Builds.

Für dotnet-Fans bietet Artifactory sogar Beispielanwendungsfälle, bei denen ihr das Tool neben eurem MSBuild-Projekt platziert und die Befehle als Teil eures Build-Prozesses verwendet, um die erzeugten Artefakte hochzuladen.

Nexus

Wie bereits erwähnt, hat Nexus seit 2018 eine neue und deutlich verbesserte API veröffentlicht. In der UI findet ihr im Admin-Bereich sowohl einen Open API Browser als auch Swagger-Dateien, die die Funktionen der jeweils ausgeführten Systemversion dokumentieren.

Die OpenAPI-Spezifikation ermöglicht die automatische Erstellung von Client- und Serverimplementierungen in den meisten gängigen Sprachen. Dadurch ist es sehr komfortabel, Clients für die Nutzung der API zu schreiben. Zudem bietet sie eine umfassende, sprachunabhängige Dokumentation der API. Das ist eine sehr nützliche Funktion.

Die API stellt Endpunkte für viele, wenn nicht sogar alle Funktionen von Nexus bereit. So könnt ihr Benutzer, Repositories, Blob Storage und mehr ändern. Hier wurde offensichtlich viel Aufwand betrieben, um es richtig umzusetzen.

Nexus nutzt außerdem das Konzept eines Pagination-Tokens. Statt eine große Anzahl von Elementen zurückzugeben, liefert es eine kleinere Menge. Mit dem Token könnt ihr dann eine Abfrage senden, um die „nächste Seite“ abzurufen. Unseren Tests zufolge liegt das Limit für die Auflistung von Assets bei 20 Elementen und kann nicht angepasst werden. Der Vorteil dieser Strategie: Wenn ihr mit der API arbeitet, lässt sich die Paginierung sehr einfach umsetzen. Der Pagination-Ansatz regt allerdings dazu an, bei Datenübertragungen sparsam vorzugehen.

Um die Funktionen der API zu erweitern, stellt Nexus einen Endpunkt zum Hochladen und Ausführen von Groovy-Skripten bereit. In der Produktion sollte dies mit äußerster Vorsicht eingesetzt werden. Die Möglichkeit, Daten näher an der Quelle zu aggregieren und nur die Zusammenfassung zurückzusenden, kann jedoch viel Bandbreite sparen. Diese Funktion wird außerdem explizit Rollen und Benutzern zugewiesen, damit sie nur bei zwingendem Bedarf verfügbar ist. Beispiele für Anwendungsfälle des Skript-Endpunkts findet ihr in ihrem GitHub-Repository.

Nexus bietet offiziell keine Nexus CLI an, hat jedoch einen Versuch für die Open-Source-Community veröffentlicht. Leider scheint es seit sieben Monaten keine Aktivität gegeben zu haben.

ProGet

ProGet beschreibt das Hochladen von Packages und die Nutzung der Feeds sehr komplex und nur punktuell. So gibt es beispielsweise keine Möglichkeit, ein Maven-Package über die API in ProGet hochzuladen. Zwar stellen sie den Endpoint bereit, wie ihr das Maven-Repository nutzt, müsst ihr jedoch selbst herausfinden oder über einen Publisher eines Drittanbieters wie Gradle abstrahieren.

ProGet gibt offen zu, nur ein absolutes Minimum an Dokumentation zu schreiben, und verweist auf Google-Suchen, um Probleme mit der API zu lösen. Dieser Ansatz ist offensichtlich unzureichend und sollte verbessert werden. 

Als wir uns zuletzt die API von ProGet angesehen haben, enthielt sie nur eine Assert Directory API und eine Package Promotion API. Seit der letzten Überarbeitung dieses Artikels sind mehrere neue Endpoints hinzugekommen: Feed Management API, Repackaging API, Connector Health API und Webhook Management API. Damit lassen sich Artefakte automatisiert verwalten. Bis die Benutzeroberfläche vollständig überflüssig wird, ist es jedoch noch ein weiter Weg, denn der API fehlen weiterhin Funktionen zur Benutzerverwaltung.

Zum Zeitpunkt der Erstellung dieses Artikels hat ProGet eine bald verfügbare Security Management API angekündigt. Die Kritik bleibt jedoch bis zur Veröffentlichung dieser API bestehen.

Für ProGet ist kein CLI-Tool verfügbar.

Gewinner

In der ersten Version wurde Artifactory in dieser Kategorie zum Gewinner erklärt. Seitdem hat sich Nexus jedoch in allen Punkten verbessert. Die Unterstützung von Open API/Swagger und die Möglichkeit, die API bei Bedarf zu erweitern, verschaffen Nexus einen leichten Vorsprung vor Artifactory – die Entscheidung ist jedoch knapp.

Wenn ihr im .NET-Umfeld arbeitet, habt ihr Glück: ProGet hat sich seit dem letzten Vergleich verbessert und bietet mehr Möglichkeiten zur Automatisierung. Beim Hochladen von Maven- und anderen Repository-Typen über die API gibt es jedoch weiterhin Komplikationen.

CI/CD-Promotion

Artifactory

Artifactory hat das Konzept der Builds in sein Domänenmodell und seine Benutzeroberfläche integriert. In Kombination mit der Promotion-Funktionalität ermöglicht das Domänenmodell eine umfassende Nachverfolgung, wo eure Artefakte zuvor gespeichert wurden. Die Promotion-Funktionalität ist über die JFrog CLI, REST oder das Jenkins Plugin für Artifactory verfügbar.

Die Meta-Data-Funktionalität ist ausgereift und ermöglicht es, für alle Artefakte und Builds Eigenschaften mit einzelnen oder mehreren Werten zu speichern.

Nexus

Nexus unterstützt die Promotion beziehungsweise das Verschieben von Artefakten. Die Promotion-Funktionalität ist nur über die REST API verfügbar. Um eine Verschiebeoperation durchführen zu können, müssen die beiden Repositories, zwischen denen ihr verschiebt, jedoch im selben Blob Store liegen (weitere Informationen findet ihr im Abschnitt zum Backend).

Nexus unterstützt das Tagging von Artefakten. Diese Funktion schien jedoch nur wie vorgesehen zu funktionieren, wenn pro Build-Job ein eindeutiger Tag verwendet wurde. Beim Verschieben getaggter Elemente in ein Repository, das bereits Elemente mit diesem Tag enthielt, trat ein Problem auf. Daher könnt ihr nicht mehrere Unit-Test-Phasen in eurer Pipeline haben, die einzelne Artefakte mit demselben Tag promoten. Sonatype empfiehlt in der Dokumentation, einen Tag pro Build-Job zu verwenden. Dadurch könnten wir jedoch keine einzelnen Bestandteile verschieben, und alle Artefakte eines Builds müssten gebündelt hochgeladen und promotet werden. 

ProGet

Meta-Daten werden in ProGet in keiner Form unterstützt, abgesehen von Name, Beschreibung und Version. Wenn ihr euer Artefakt von einem Repository in ein anderes verschieben oder promoten möchtet, müsst ihr dies über die REST API tun.

ProGet bietet keine Nachverfolgung dazu, wo die Artefakte gespeichert wurden. Auch das Tagging von Artefakten wird nicht unterstützt.

Gewinner

Artifactory gewinnt aufgrund der Nachverfolgbarkeit, wo Artefakte zuvor gespeichert wurden. 

Möglich wird dies durch ein Build-Objekt im Domänenmodell, mit dem ihr die gewünschten Artefakte einfach und präzise verschieben könnt. 

Bereinigung

Aufbewahrungszeiträume

Ein CI/CD-Workflow bedeutet, dass ihr viele versionierte Binärartefakte erstellt. Schon nach kurzer Zeit kann es passieren, dass euer Speicher häufig knapp wird. Eine gute Kontrolle darüber, was behalten und was entfernt wird, ist entscheidend, um den Speicherbedarf auf einem angemessenen Niveau zu halten. In einigen Branchen gibt es zudem Compliance-Anforderungen daran, welche Artefakte wie lange verfügbar sein müssen. In solchen Fällen sind klar definierte Bereinigungsrichtlinien nicht nur wichtig, sondern unverzichtbar.

Artifactory

Artifactory verfügt über keine integrierten Aufbewahrungsmechanismen. Stattdessen nutzt es seine Abfragesprache AQL, um Artefakte zu identifizieren, sowie CLI oder REST, um sie zu löschen. Mehr erfahren.

Das ist etwas schwieriger umzusetzen als bei den anderen, bietet aber deutlich mehr Flexibilität bei der Erstellung von Regelwerken, die nicht nur auf Zeit oder Nutzung, sondern auch auf Suchabfragen basieren. Was ihr abfragen könnt, könnt ihr auch löschen.

Nexus

Nexus bietet geplante Bereinigungsaufgaben für alle Repository-Typen. Dazu könnt ihr einen Filter festlegen, der beschreibt, auf welche Artefakte die Bereinigungsrichtlinie angewendet wird. Der Filter nutzt reguläre Ausdrücke zum Abgleich von Dateien und unterstützt Zeit, Downloads und Release-Typ als Kriterien.

ProGet

Die Bereinigung in ProGet erfolgt über sogenannte Retention Rules. Mit diesen Regeln könnt ihr Artefakte abhängig von der letzten Nutzung, der Gesamtzahl der Artefaktversionen oder anhand von Mustern im Regex-Stil löschen.

ProGet verfügt außerdem über das Konzept der Quotas. Ihr könnt festlegen, ob die Regeln jedes Mal ausgeführt werden sollen (keine Quota), wenn der Feed eine bestimmte Größe überschreitet oder wenn die Artefakte, die der Aufbewahrungsregel entsprechen, eine bestimmte Größe überschreiten. Sobald das Limit erreicht ist, hält ProGet die Quota auf diesem Wert, indem Dateien entfernt werden.

Zuletzt haben wir ProGet dafür kritisiert, dass es keine Möglichkeit gab, die Löschrichtlinie zu testen. Diese Kritik ist nicht mehr gültig, da ProGet diese Funktion jetzt bietet. ProGet bietet zudem eine Funktion namens DryRun, die Testläufe ermöglicht, ohne die Artefakte zu beeinträchtigen.

Gewinner

Nexus hat die am wenigsten ausgereifte UI zum Erstellen von Bereinigungsregeln, die Funktionalität ist jedoch mit ProGet vergleichbar. Die Lösung von ProGet ist allerdings intuitiver, was bei der Erstellung von Richtlinien hilft, die möglicherweise Artefakte löschen, die nicht gelöscht werden sollten. Trotzdem bietet Artifactory die fortschrittlichste Bereinigungsmethode und ist unsere Wahl, auch wenn dafür ein eigenständiger Service laufen muss.

Betrieb

Benutzer und Authentifizierung

Alle BRMs verfügen über eine eigene Datenbank, in der ihr Benutzer erstellen könnt, und lassen sich in verschiedene andere Services integrieren. Die Integration mit Active Directory oder ähnlichen Diensten ist entscheidend für Unternehmen und Administratoren, die vermeiden möchten, Benutzer an mehreren Stellen hinzufügen und löschen zu müssen.

Artifactory

LDAP; Active Directory; bietet Unterstützung für OAuth mit GitHub, Google, Cloud Foundry und OpenID; und unterstützt SAML SSO, sodass ihr euren eigenen Provider konfigurieren könnt, beispielsweise den Passwortmanager LastPass oder Ähnliches. Beachtet jedoch, dass die GitHub-Integration nur mit GitHub Enterprise funktioniert, da sie _allen_ auf der Instanz eine Anmeldeberechtigung gewährt. Das bedeutet: Jeder mit einem github.com-Konto kann sich anmelden, wenn ihr diese Option wählt.

Nexus

LDAP, Atlassian Crowd, SAML und RUT

ProGet

LDAP, Active Directory und SAML

Gewinner

Da LDAP der Standard ist und das Enterprise-Protokoll SAML ebenfalls von allen implementiert wird, gewinnen alle.

Einschränkungen für Benutzer/Gruppen und Rollen

Den Zugriff einzuschränken, ist ein Muss – unabhängig davon, ob ihr ein kleines Garagenunternehmen oder ein großes Unternehmen seid.

Alle drei Kandidaten verfügen in der einen oder anderen Form über Benutzer, Gruppen und Rollen. Daher konzentrieren wir uns in unserer Bewertung auf die Benutzerfreundlichkeit und nicht darauf, _ob_ sie Einschränkungen bieten.

Artifactory

verfügt über ein Berechtigungsschema aus Benutzern, Gruppen und Berechtigungen, das den Schwerpunkt auf Benutzer legt, die Gruppen mit zugewiesenen Rollen angehören. Hier werden Rollen als Berechtigungen bezeichnet. Sie legen fest, welche Repositories unterschiedliche Gruppen/Benutzer verwalten, löschen/überschreiben, bereitstellen/cachen, kommentieren oder lesen dürfen.

Nexus

Verfügt über eines der umständlichsten und komplexesten Benutzer-/Gruppen-/Berechtigungssysteme, die ich je gesehen habe – und das ist keineswegs positiv gemeint.

Es gibt Rollen, aber zusätzlich auch Privilegien. Das Problem liegt in der Vielzahl verschiedener Privilegien, die einer Rolle hinzugefügt werden können. Wenn ihr Hunderte unterschiedliche Privilegien hinzufügt, ist es nahezu unmöglich nachzuvollziehen, welche Zugriffsrechte für eine bestimmte Aufgabe erforderlich sind.

Es unterstützt das Deaktivieren von Benutzern, sodass sie sich nicht anmelden können.

ProGet

ProGet verfügt über ein Berechtigungsschema aus Benutzern, Gruppen und Aufgaben, wobei Aufgaben dem entsprechen, was ich normalerweise Rollen nennen würde. Ihr könnt Benutzer ohne zugewiesene Aufgaben erstellen; die Standardeinstellung ist „none“, also anonym. Es gibt eine kleine vordefinierte Gruppe von Aufgaben für globalen Admin, Repository-Admin, Upload und Löschen sowie Download. Falls diese nicht euren Anforderungen entsprechen, könnt ihr neue konfigurieren.

Gewinner

ProGet und Artifactory sind recht ähnlich, aber ProGet hat einen leichten Vorteil, da sich weitere Aspekte besser steuern lassen, etwa die Anzeige geplanter Aufgaben und die Verwaltung von Zugangsdaten. Daher ist ProGet der Gewinner.

Speicher

Artifactory

Artifactory unterstützt mit der Enterprise-Lizenz weiterhin die meisten externen File Stores. Seit dem letzten Vergleich hat JFrog die Azure Blob Storage-Integration ab Version 6.15.0 auch für Kunden mit Pro-Lizenzen verfügbar gemacht.

Wenn ihr jedoch die Vielzahl verfügbarer Speicher nutzen möchtet, benötigt ihr weiterhin die Enterprise-Lizenz, die das Zehnfache einer Pro-Lizenz kostet. Artifactory bietet binäre Deduplizierung anhand von Hash-Werten. Dadurch könnt ihr mehrere Instanzen derselben Datei speichern, ohne dass der File Store unnötig anwächst.

Nexus

Nexus bietet sowohl in der OSS- als auch in der Pro-Version zwei Backend-Speicherlösungen: lokalen Speicher und S3.

Es unterstützt mehrere Speicherbereiche, sogenannte „Blob Stores“, und ihr könnt beide Speichertypen gleichzeitig aktiv nutzen. Allerdings gibt es einige Einschränkungen: Ein Repository kann sich jeweils nur in einem Speicher befinden, und eine Migration von einem Speicher in einen anderen – etwa vom lokalen Speicher in einen S3-Bucket – ist nicht einfach möglich. Außerdem könnt ihr Artefakte nur zwischen Repositories verschieben, die sich im selben Blob Store befinden. Achtet daher darauf, dass sich alle Repositories im Lebenszyklus eines Artefakts im selben Speicher befinden.

Nexus bietet keine Deduplizierung für Blobs oder Artefakte – eine Funktion, die bereits vor über drei Jahren angefragt wurde.

2019 veröffentlichte Nexus für seine professionellen Kunden einen neuen Speichertyp namens GroupBlobStore. Eine Gruppe ist im Wesentlichen eine Sammlung von Blob Stores, die als einzelner Blob behandelt wird. Es gibt zwei Verteilungsmethoden zwischen den Blob Stores: „Round Robin“ und „Write to first“ – entweder wird zwischen allen Blobs abgewechselt oder nur in einen einzigen Speicher geschrieben.

Sonatype empfiehlt Gruppen, um über mehrere Geräte zusätzlichen Speicher für einen Blob-Speicherbereich bereitzustellen und/oder Schreib- und Lesevorgänge auf mehrere Blob Stores zu verteilen.

ProGet

ProGet bietet standardmäßig lokalen Speicher sowie über offizielle Erweiterungen S3 und Azure Blob Storage.

Außerdem bietet es eine Anleitung mit sieben Schritten für die Migration lokaler Speicher-Repositories in die Cloud, allerdings nicht in die andere Richtung. Auch ProGet bietet keine Deduplizierung für Blobs oder Artefakte.

Gewinner

Hier ist es schwer, einen Gewinner zu bestimmen. ProGet ist für den Funktionsumfang direkt nach der Installation gut aufgestellt, während Nexus mehrere Blob-Store-Anbieter nutzen und einen einzelnen Blob Store auf mehrere Geräte verteilen kann. Um die Möglichkeiten von Artifactory wirklich auszuschöpfen, benötigt ihr weiterhin die größte Lizenz und die entsprechende Einrichtung. Immerhin steht Azure Blob Storage inzwischen auch Pro-Benutzern zur Verfügung. Knapp gewinnt ProGet.

Erweiterbarkeit

Artifactory

Es gibt keinen Plugin-Marktplatz, aber ein Repository mit einer großen Anzahl von Beispielen – auch wenn die Dokumentation der einzelnen „User-Plugins“ in sehr unterschiedlicher Qualität und Tiefe vorliegt. Erweiterungen sind über „Events“ möglich, also nach dem Prinzip „Wenn etwas in Artifactory passiert, dann tue dies“. Das bedeutet, dass ihr fast alles umsetzen könnt. Der Haken: Meist müsst ihr selbst herausfinden, wie. Die einfachste Option besteht oft darin, die Plugin-Logik einfach zu löschen und sie als Grabstein zu behalten.

Nexus

Nexus bietet einige Plugin-Möglichkeiten und verfügt über einen Marktplatz. Die Oberfläche des Marktplatzes ist nicht besonders gut, ermöglicht aber das Filtern nach Produkt und Version. Es gibt etwa 25 Plugins, die sich in Nexus nutzen lassen.

Die Installation von Plugins erfolgt manuell. Die Plugins basieren auf OSGi-Containern (siehe).

Um ein Plugin zu installieren, müsst ihr den Nexus-Service stoppen, XML-Konfigurationsdateien bearbeiten und das Plugin herunterladen. In manchen Fällen müsst ihr das Plugin auch selbst bauen. Dieser Prozess ist umständlich und sollte eher als Code-Injection denn als Plugin-Funktionalität betrachtet werden.

ProGet

ProGet ist das einzige Tool mit echter Plugin-Funktionalität, die hier Extensions genannt wird. In der UI findet ihr nur einige wenige Extensions, sogenannte integrierte Extensions, die sich mit einem Klick und einem Neustart installieren lassen. Die vollständige Liste der verfügbaren Extensions inklusive Installationsanweisungen findet ihr hier. Derzeit lassen sich 8 Extensions über die UI installieren, insgesamt sind es 26 auf der Webseite. Sollte die etwas eingeschränkte Auswahl eure Anforderungen nicht erfüllen, bietet Nexus ein SDK, mit dem ihr eigene Extensions entwickeln könnt.

Gewinner

Mit großem Abstand bietet ProGet die beste Erfahrung, auch wenn die Auswahl an Plugins eher klein ist und seit dem letzten Vergleich kaum gewachsen ist. Es funktioniert einfach!

Fazit

Artifactory unterstützt die meisten Repository-Typen und bietet mit der eigenen Abfragesprache AQL eine gute Suchfunktion. JFrog stellt sowohl eine REST API als auch die JFrog CLI für die Interaktion mit Artifactory bereit und unterstützt die Promotion verschiedener Artefakte mit vollständiger Nachverfolgbarkeit. Die Bereinigung erfolgt über AQL und bietet einen sehr flexiblen und leistungsfähigen Mechanismus. Die Authentifizierung lässt sich mit fast jedem Login-Provider verbinden und ermöglicht eine umfassende Anpassung von Zugriffsrollen und Richtlinien. Cloud Storage ist keine Enterprise-Funktion mehr. Der einzige Nachteil ist, dass die Erweiterbarkeit nicht so gut ist wie bei anderen Produkten wie ProGet und Nexus.

Nexus hat mit der Einführung seiner neuen REST API mit OpenAPI-Spezifikation und Swagger-Dateien große Fortschritte gemacht. Damit lassen sich in den gängigsten Sprachen Client- und Server-Stubs als Code-Gerüst erstellen, was die Nutzung und Erweiterung der API vereinfacht. Die Promotion-Funktionalität wirkt noch etwas unausgereift, da Artefakte offenbar nicht in ein Repository verschoben werden können, das bereits Artefakte mit diesem Tag enthält. Auch bei der Speicherung ist Nexus in vielerlei Hinsicht gereift – sowohl bei Cloud Storage als auch bei Group Stores, die mehrere Blob Stores umfassen.

Aus der .NET-Welt kommend, verfolgt ProGet einen strengeren Ansatz für binäre Artefakte. Wenn ihr mit der engeren Auswahl unterstützter Repositories leben könnt und für eure Artefakte einen webzentrierten Roll-forward-Ansatz verfolgt, ist ProGet eine gute Wahl.

Eine Empfehlung auszusprechen, ist nicht so einfach wie in der vorherigen Ausgabe dieses Artikels. Unsere Empfehlung lautet, euch die verschiedenen Produkte und die von ihnen unterstützten Repository-Typen anzusehen, bevor ihr anhand eurer Anforderungen und eures Budgets eine Wahl trefft.

Wenn ihr Kommentare habt, sprecht uns gerne an.