Gradle: Unternehmensweite Einstellungen und Buildskript-Erweiterungen zentral für alle Entwickler zur Verfügung stellen

Build-Tools wie Gradle und Maven ermöglichen in Verbindung mit unternehmensweiten Repositories (Nexus, Artifactory) die unternehmensweite Auslieferung von Build-Artefakten und zentralen Bibliotheken. Das manuelle Sicherstellen der korrekten Version entfällt somit für die Entwickler, und eine zentrale Pflege der Versionen tritt in den Vordergrund.

Aber was ist mit den Buildskripten? Gerade im Gradle-Umfeld wachsen die Skripte häufig schnell an. URLs für Repositories und zum Upload der Archive, Verwaltung von Versionsnummern, Custom Tasks und das Customizen der Buildskripte sind häufig notwendig und für alle Projekte gleichermaßen vorgegeben.

Konstante Werte wie Versionsnummern können in die gradle.properties Datei ausgelagert werden, welche zentral auf dem Entwicklerrechner abgelegt werden kann. Komplexere Aufgaben können in das init.gradle Skript ausgelagert werden, welches vor jedem Build-Lauf ausgeführt wird und verwendet werden kann, um allgemeine Konfigurationen zu setzen oder Tasks zu definieren. Diese Datei kann ebenfalls unabhängig von den Projekte auf dem Entwicklerrechner abgelegt werden.

Dies funktioniert auf dem lokalen Entwicklungsrechner sehr gut. Nachteil ist, dass dieses Verfahren für mittlere bis größere Teams eher ungeeignet erscheint. Schnell wird hier der Wunsch nach einer zentralen Pflege laut. Kommt es zu Änderungen in den ausgelagerten Build-Schritten, so muss sichergestellt werden, das alle Entwickler die Änderungen auf ihrem Rechner nachziehen.

Maven kennt mit der POM Inheritance eine Lösung für dieses Problem. Unterschiedliche Einstellungen und Verhalten werden in einer zentralen POM Datei abgelegt, welche in ein Repository hochgeladen wird. Projektspezifische POM’s binden mittels parent-Tag dieses zentrale POM ein. Durch die Ablage der POM im Repository ist somit ein zentraler Ansatz gegeben.

Um eine ähnliche Lösung in Gradle umzusetzen, schauen wir uns das apply Keyword in Gradle an. Neben dem Einbinden von Plugins können mittels

apply from: 'repositoryConfig.gradle'

Skripte angegeben werden, welche im Buildlauf eingebunden werden. Teile des eigenen Buildskriptes können hiermit modularisiert ausgelagert werden. apply from unterstützt hierbei neben dem lokalen Filesystem auch die Angabe einer HTTP-Adresse. Hierdurch können Common-Skripte auch auf einem HTTP-Server im Unternehmen abgelegt werden und von dort zentral bezogen werden.

Ist zusätzlich ein Repository wie Nexus im Einsatz, so kann auch dieses zur Auslieferung der common.gradle Skripte verwendet werden, da hier jede hochgeladene Datei ebenfalls direkt über ihre HTTP-Adresse angesprochen werden kann. Änderungen in den Skripten müssen somit lediglich in das Repository hochgeladen werden.

Beim Einsatz eines Continuous Integration Servers (Jenkins, Bamboo) kann dieser Schritt auch von dem Build Server übernommen werden. Ein Build-Job überwacht hierbei im Git/SVN-Repository, ob Änderungen an den common.gradle Skripten eingecheckt wurden. Wird eine neue Version der Skripte eingecheckt/gepusht, so lädt der Build-Server diese Version über die REST-API auf den Nexus.

Dies kann auf Linux-Systemen zum Beispiel durch den Aufruf des Shell-Befehles ‚curl‘ erfolgen:

curl -upload-file common.gradle -u admin:admin123 -v http://localhost:8081/nexus/....

In den Projekt-Buildskripten erfolgt das Einbinden nun mittels

apply from: 'http://localhost:8081/nexus/....'

Änderungen an den zentralen Skripten werden somit für alle Entwickler ohne manuelles Eingreifen sichtbar, sobald eine neue Version eingecheckt wird.

Short URL for this post: http://wp.me/p4nxik-2wP
This entry was posted in Build, config and deploy and tagged , , , . Bookmark the permalink.

Leave a Reply