Make-loses Java mit der z2-Environment

Inhaltsverzeichnis

Die z2-Environment ist eine Java-Laufzeitumgebung, die sich selbsttätig mit Konfigurationen und Quellcode aus einer Versionsverwaltung oder einem Entwickler-Workspace aktualisiert. Mit ihr entwickelte Systeme haben einen hohen Grad an innerer Konsistenz, und Entwicklung sowie Pflege werden dank geringer Anforderungen an die Entwicklungsumgebung stark vereinfacht.

Java ist eine kompilierte Programmiersprache, und gewöhnliche Java-Applikationsserver erwarten, dass Java-Programme zur Ausführung kompiliert vorliegen. Anwendungsentwickler müssen daher vor der Ausführung einen Kompilier- und Transformationsschritt durchführen, den sogenannten Make (und/oder Build). Der Make-Vorgang überführt das, was Programmierer in ihrer Entwicklungsumgebung in einer Verzeichnisstruktur bearbeiten, in eine Form, die der Ausführungsumgebung, etwa einem Java-Applikationsserver, genehm ist: das sogenannte Deployable. Nur in einfachen, isolierten Fällen ist es sinnvoll möglich, mit integrierten Applikationsservern zu arbeiten und automatische Aktualisierungen durch die Entwicklungsumgebung auszunutzen.

Einerseits bedeutet der Ansatz mit externem Make-Vorgang einen nicht geringen zeitlichen Aufwand für den Entwickler. Andererseits zieht dieser nach sich, dass neben der eigentlichen Entwicklungsumgebung und dem Betrieb eines Applikationsservers eine geeignet konfigurierte Build-Umgebung, also die Ausführungsumgebung des Make, konsistent für alle Entwickler bereitzustellen ist. In kleinen Projekten mit vielen Abhängigkeiten übersteigen dabei die Komplexität der Build-Ausführung und deren Konfiguration leicht die des eigentlichen Entwicklungsvorhabens.

Fast wie Skripten

Wer solche Erfahrungen hinter sich hat, wünscht sich den Komfort von Skripting-Umgebungen auch für die Java-Anwendungsentwicklung. Dort ist man gewohnt, an beliebigen Teilen der Applikation Änderungen vornehmen zu können, die sogleich effektiv sind.

Die z2-Environment implementiert einen Ansatz mit ähnlichen Qualitäten. Sie ist aus der Erfahrung mit der Verwaltung großer Softwaresysteme bei der SAP entstanden. Sie löst zum Test einer Modifikation in der Entwicklungsumgebung lediglich eine Synchronisation der Laufzeitumgebung aus. Die erkennt die Änderungen im lokalen Entwicklungsvorrat des Entwicklers, dem Workspace, und passt ihren Laufzeitzustand geeignet an. Das kann bedeuten, dass eine Webanwendung entladen und anschließend mit neuen Ressourcen wieder gestartet wird oder dass Java-Klassen schnell zu kompilieren und in neuer Version in der Laufzeit zu laden sind.

Tatsächlich ist nur ein kleiner, vorkompilierter Kern lokal zu installieren. Sämtliche Konfiguration und Implementierung, inklusive Web-Container und Datenbanktreiber, kann der Entwickler nach Bedarf aus dem Komponenten-Repository laden und falls nötig ebenfalls schnell kompilieren.

Dafür braucht es allerdings ein wenig mehr Umgebungswissen und einen grundsätzlich anderen Deployment-Ansatz. Statt zu erwarten, dass die z2-Environment alle von Änderungen betroffenen oder anderweitig benötigten Laufzeitkomponenten in neuer Form zum Deployment anliefert, "zieht" sie sämtliche Änderungen aus der Versionsverwaltung sowie gegebenenfalls aus einem lokalen Workspace und appliziert sie geeignet auf den Laufzeitzustand. z2 implementiert ein Pull-Deployment im Gegensatz zum üblichen Push-Deployment.