XML Entwicklerhandbuch

4.3.5.3 Deployment-Tools

Will man eine größere MarkLogic Applikation maintainen, dann wird man um einen Build- / Deployment-Manager nicht herumkommen. Denn gewöhnlich gilt es einen Entwicklungsserver, einen Testserver und einen Prod-Server zu pflegen.

ml-gradle ↗ und ml-proj ↗ sind solche Tools. Das eine basiert auf der populären Java-Buildchain gradle, das andere ist eine NodeJS Applikation vom gleichen Maintainer, wie die zuvor beschriebene EXPath Konsole.

Wie ich bei einer größeren Evaluierungssaufgabe aber herausfinden konnte, eignen sich beide Tools eher für Projekte, die von der grünen Wiese aus gestartet werden, weil sie auf Namenskonventionen in der Dateistruktur setzen.

Beide beanspruchen zwar für sich eine (fast) vollständige Konfigurierbarkeit der Projektstruktur, jedoch ist diese mit einigen Fallstricken behaftet, so dass ich eine Migration eines Bestandsprojekts leider nicht empfehlen kann.

4.3.5.3.1 ml-gradle

ml-gradle basiert auf dem populären Java Build-Tool ml-gradle ↗ . Mittels vordefinierter oder eigener Tasks werden JSON Dateien automatisiert erstellt, die als Payload für REST Calls auf MarkLogic fungieren. Dabei wird die MarkLogic REST API bedient. Bei der Deployment-Aktion selbst wird schliesslich das Payload eingesammelt und abgesetzt.

Grds. ist diese Idee nicht verkehrt, es gibt aber nun mehrere Stellen, an denen die Konfiguration modifiziert werden kann - was sich bei fehlender Disziplin der Entwickler natürlich eher nachteilig auswirken könnte:

Setzen vordefinierter Properties ↗ in der Datei gradle.properties
Mittels vordefinierter
Create-Tasks
, z.B. gradle mlNewDatabase

werden Skelett-Dateien erzeugt, die man manuell bzgl. fehlender Konfigurationsinformationen vervollständigt.
Es gibt einen Token-basierten Mechanismus ↗, mit dem vordefinierte Platzhalter in Konfigurationsdateien (Payload-Files) dynamisch ersetzt werden.
Eigene Groovy-Tasks können implementiert werden. Diese werden z.B. in der Datei build.gradle eingebunden. Beispiel für einen einfachen Groovy-Task ↗

4.3.5.3.2 mlproj

mlproj ist eine NodeJS Applikation von Florent Georges ↗. Wie auch bei ml-gradle würde ich den Umzug einer bestehenden Projektstruktur auf mlproj aber nicht empfehlen, sondern damit ein Projekt von der grünen Wiese aus starten.

Während es bei ml-gradle darum geht, den Überblick über mehrere, teilweise automatisch generierte, Konfigurationsdateien und -optionen zu behalten, geschieht die Konfiguration bei mlproj in nur einer Datei prod.json bzw. dev.json , welche die Einstellungen einer Basiskonfiguration base.json übernimmt bzw. überschreibt.

Natürlich ist der Erweiterungsmechanismus nicht ganz so mächtig, wie bei ml-gradle - schliesslich fehlt eine ausgewachsene Build-Chain als Unterbau. Ein NodeJS Programmierer wird damit aber gut zurechtkommen. Der Quellcode wirkt aufgeräumt und das Projekt ist gut dokumentiert.

Beide Tools haben einen "Watch"-Modus, bei dem die Dateistruktur des Entwicklers überwacht wird. Sobald sich eine Datei ändert, wird diese nach MarkLogic hochgeladen. Als Beispiel für die umfangreichen Konfigurationsmöglichkeiten ist folgend der Docstring des "Watch"-Modus in mlproj wiedergegeben:

mlproj watch [-a srv|-b db] [-s src|-/ dir|-1 file] [what]

-a, --as, --server <srv> server, get its modules database
-b, --db, --database <db> target database
-B, --sys, --system-database <db> the name of the target system db
-s, --src, --source-set <dir> source set to watch
-/, --dir, --directory <dir> directory to watch
-1, --doc, --document <file> file to watch
<what> source set or directory to watch