Ein Paket für alle Fälle

Wer seine Software dagegen selbst in installierbare Pakete umwandelt, sollte die Daten klar strukturieren und standardisieren - dann lassen sich dieselben Applikationen mit relativ wenig Aufwand in verschiedenen Systemtest-, Integrationstest- und Produktionsumgebungen nutzen: Die jeweilige Anpassung erfolgt über Umgebungs- und Softwareparameter, ohne die Software selbst zu verändern. Die nötigen Informationen werden bei der Anlieferung der Software dokumentiert übergeben und idealerweise automatisch verarbeitet, um auch hier Zeit zu sparen und Fehler zu vermeiden.

Liegen Software und Konfigurationen dann standardisiert vor, steht dem Bau des installierbaren Pakets nichts mehr im Weg. Auch hier ist es wieder sinnvoll, nur eine kleine Anzahl an Systemen zuzulassen: Die meisten Build-Tools geben Workflow und Integrationsstandards vor, und die sollten für alle Releases einheitlich sein. In der Regel reicht hier ein einziges Werkzeug aus, um alle Anforderungen zu erfüllen. Selbst wenn ein Team sich täglich abspricht, wie etwa beim Agile & Scrum, sollten zudem die Build-Skripte grundsätzlich versioniert werden - nicht zuletzt, weil dieses Vorgehen Revisionssicherheit verleiht und es durch die Versionierung möglich ist, Fixes für die Produktion automatisiert an neue Releases weiterzugeben.

Übergreifende Installationsroutine

Eine ähnliche Strategie wie im Build lässt sich für die Standardisierung des Deployments anwenden: Eine einzige, übergreifende Installationsroutine fasst alle zentralen Schritte zusammen, die für das Deployment notwendig sind. Diese Overlay-Komponente ist für alle Projekte gleich und wird bereits im Build-Prozess in jedes Softwarepaket integriert.

Ein solches Vorgehen ist nicht nur weniger aufwendig und fehleranfällig als eine manuelle Anpassung für jede einzelne Applikation - auch Änderungen werden jeweils nur am zentralen Overlay vorgenommen und gelangen beim nächsten Build automatisch in jedes einzelne Paket. Modifizieren Entwickler eine Anwendung also während eines agilen Entwicklungsprozesses, kann das Deployment ebenfalls sofort reagieren.

Als weiteren automatisierten Bestandteil eines ausgereiften agilen Deployment-Verfahrens enthält das Overlay ein Modul mit Prüfmechanismen, die beispielsweise die Erreichbarkeit der Applikations-Server und Ziel-Container, Datenbanken, Zielschemata oder der geforderten Queues kontrollieren. Ergeben sich dann bei der Auslieferung trotz erfolgreichem Test noch Fehler, ist deren Quelle bereits gut eingegrenzt: Sie liegt höchstwahrscheinlich in der Infrastruktur.