Lesezeit: 4 Minuten

Einführung einer Artefaktverwaltung

Durch eine Artefaktverwaltung können Softwarepakete für Paketmanager verfügbar gemacht werden, ohne für jedes Paket eine (Repository-)URL hinterlegen zu müssen. Dadurch werden die Konfigurationsdateien übersichtlicher, da dann alle Pakete aus einer Quelle bezogen werden können.

In diesem Blogbeitrag werden drei kostenfreie Open Source-Softwares zur Verwaltung von Artefakten verglichen: JFrog Artifactory, Sonatype Nexus Repository und die GitLab Package Registry. Abschließend erfolgt eine Bewertung anhand unseres konkreten Use Cases.

Problemstellung

Als Softwareentwickler kommt man um Paketmanagement nicht herum, ganz egal, ob man ein TYPO3-Projekt, Shopware-Projekt oder ein anderes Projekt hat.
Über Paketmanager, wie Composer und NPM, beziehen wir verschiedene Softwarepakete, wie beispielsweise TYPO3-Extensions – entweder aus öffentlichen Quellen wie Packagist oder eigens entwickelte Extensions aus intern verwalteten Software-Repositories.

Ein typisches TYPO3-Projekt umfasst bei uns acht bis zehn interne Extensions – bei größeren Projekten können aber auch gerne mal über 20 Extensions verwendet werden. Für jede Extension, die im Projekt verwendet werden soll, muss der Entwickler das interne Repository, in dem der Code der Extension liegt, in die Konfigurationsdatei (composer.json) eintragen, damit sie installiert werden kann.

Bei vielen solcher Extensions wird die Datei unübersichtlich. Bei Umbenennung eines Repositories kann der alte Pfad ungültig werden, was eine manuelle Anpassung durch die Entwickler (und ggfs. kaputte Builds bis zur Korrektur) nach sich zieht. Eine Lösung für diese Probleme ist die Einführung einer Artefaktverwaltung.

Anforderungen

Als TYPO3- und Shopware-Agentur arbeiten wir hauptsächlich mit Composer und NPM-Paketen. Daher ist eine Kernanforderung, dass diese Artefakte von der Software unterstützt werden.

Neben der Nutzung für unsere Kundenprojekte bieten wir einige unserer internen Extensions auch für andere Entwickler und Agenturen an. Wir verwenden aktuell Private Packagist, um Kunden mit Solr-Entwicklungsbeteiligung die gekauften Extensions aus dem entsprechenden Entwicklungszeitraum bereitzustellen. Daher wurde als Wunsch formuliert, dies ebenfalls über die Artefaktverwaltung tun zu können.

Must-have: Unterstützung von Composer- und NPM-Paketen als Artefakt

• Ziel: Kleinere composer.json/package.json-Dateien, einheitliche Bezugsquelle für Composer-Pakete

Nice-to-have: Zugriff auf bestimmte Artefakte und deren Versionen einschränken

• Ziel: einheitliche Auslieferung (u.a. von TYPO3-Extensions) an Entwickler und Kunden

Softwarevergleich

JFrog Artifactory (Pro)

Artifactory von JFrog ist vermutlich eine der bekanntesten und umfassendsten Artefaktmanager auf dem Markt. Neben Composer und NPM unterstützt er noch viele weitere Artefakte, wie beispielsweise Docker Container, welche langfristig ebenfalls für uns interessant sind. Jedoch nur in der kostenpflichtigen Pro-Version, welche mit $2,950 im Jahr (self-hosted) zu Buche schlägt – oder ab $98 im Monat in der Cloud erhältlich ist.

Artifactory hat eine Benutzer- und Gruppenverwaltung, bei der Zugriffe auf einzelne Repositories (= Sammlungen von Artefakten) erteilt werden können. Eine spezifische Beschränkung auf bestimmte Artefakte oder -versionen war nach meiner Analyse nicht möglich.

Außerdem scheint JFrog strikt zwischen der Verwendung für die Entwicklung und der Verteilung von Artefakten zu unterscheiden, da es für die Verteilung von Artefakten mit Bintray ein eigenständiges Produkt verkauft.

Sonatype Nexus Repository

Im direkten Vergleich zur Pro-Version von JFrog Artifactory wurde die kostenlose Open Source-Version von Sonar Nexus Repository betrachtet. Sonatype bietet zwar auch eine Pro-Version ab $3000 im Jahr an, diese ist im Kern aber eher eine Cloud-Installation mit Support.

Während u.a. NPM-Pakete nativ unterstützt werden, kann die Composer-Unterstützung über ein Community-Plugin (ebenfalls Open Source) nachinstalliert werden. In beiden Fällen müssen die Artefakte zuvor gepackt werden und können dann HTTP hochgeladen werden.

Das Berechtigungssystem ist sehr gut ausgebaut. Der Zugriff auf einzelne Funktionalitäten können nach Benutzern und Gruppen gesteuert werden. Der Zugriff auf Artefakte lässt sich mittels sogenannter Content Selectors auf einzelne Pakete oder dessen Versionen beschränken.

Nach einer Hands-on-Evaluierung waren wir von Sonar Nexus Repository überzeugt, insbesondere durch den Kostenunterschied zu JFrog Artifactory. Der einzige Kritikpunkt ist aus meiner Sicht, dass Pull Requests zu Community Plugins im Falle von Composer ziemlich lange liegen bleiben können, bis sie gemergt werden.

Und dann kam GitLab

Die GitLab Package Registry ist weniger eine eigenständige Software, sondern ein Feature des Versionskontrollsystems GitLab. Das Feature wurde mit GitLab Version 11.3 der Enterprise Edition eingeführt. Seit Ende August steht das Feature mit Version 13.3 allen GitLab-Instanzen zur Verfügung und ist damit kostenlos geworden.

Wir verwenden GitLab bereits seit etwa einem Jahr als Versionskontrollsystem. Da das Update auf die 13.3 sowieso geplant war, wurde die Package Registry kurzerhand in einem kleinen Praxistest evaluiert.

Composer- und NPM-Pakete werden nativ unterstützt. Anders als bei Sonar Nexus Repository und JFrog Artifactory müssen die Artefakte nicht gepackt und hochgeladen werden, sondern es werden die bereits existierenden Archiv-Links aus den Git-Repositories verwendet.

Berechtigungsseitig gibt es keine besonderen Konfigurationsmöglichkeiten für die Packages. Um Pakete herunterladen zu können, benötigt es den "Reporter"-Status in dem Projekt. Eine Zugriffsbeschränkung nach einzelnen Paketen ist so zwar grundsätzlich möglich, jedoch nicht nach bestimmten Versionen. Damit einhergehend werden jedoch auch die weiteren Reporter-Rechte (wie bspw. der lesende Zugriff auf den Code und das Recht zum Anlegen von Issues) freigegeben.

Fazit

Bezogen auf unseren Use Case bietet Sonatype Nexus Repository im Vergleich zu JFrog Artifactory Pro und der GitLab Package Registry alles, was wir wünschen. Jedoch muss man bedenken, dass dadurch ein neues Tool in die Infrastruktur eingebunden wird, welches gewartet werden muss und durch die Bedeutung zu einer kritischen Komponente unseres Entwicklungsprozesses werden wird.

Unter diesem Aspekt schien uns die GitLab Package Registry geeigneter zu sein, da die GitLab-Installation bereits Teil unserer Infrastruktur ist und regelmäßig gewartet wird. Für die interne Entwicklung werden die Pakete dann in der GitLab Package Registry abgelegt und von dort bezogen. Für die Verteilung interner TYPO3-Extensions an unsere Kunden verwenden wir weiterhin Private Packagist.