Strukturierung eines Deployment-Pakets, Teil 1: Die Komplexität verstehen

Ein Deployment-Paket ist wohl nie nur eine einzelne Datei, die Sie irgendwo ablegen und fertig. Nein! Die Auswahl und Bündelung Ihrer Artefakte für die Bereitstellung ist nicht weniger komplex als die Ausarbeitung einer effizienten Bereitstellungsstrategie selbst. Die Java EE-Spezifikation schlägt EARs als Standard-Paketierungs- und Verteilungsmechanismus vor, aber wir alle wissen, dass dies nicht ausreicht. In Wirklichkeit umfasst das "Bereitstellungspaket" eine ganze Liste von Artefakten und mehr:

• EARs
• WARs
• Datenbank-Skripte
• statische Inhalte wie Bilddateien und Symbole
• Skripte zum Erstellen von Warteschlangen, Themen und Datenquellen
• ...

Kurz gesagt, eine EAR und eine Menge drum herum! Aber warten Sie, es gibt noch mehr, was ist mit der Fülle von umgebungsspezifischen Konfigurationen, die ebenfalls dazugehören?

Das wirft einige Fragen auf und ist der Grund für diesen Blog.

Was gehört in ein Bereitstellungspaket und was nicht? Gibt es eine Standardmethode, um die Gruppierung zu bestimmen? Welche Faktoren beeinflussen die Bündelung und wie können die umgebungsspezifischen Eigenschaften verwaltet werden? Es gibt keine einfache Antwort, aber lassen Sie uns damit beginnen, die Komponenten zu kategorisieren, die Teil des Bereitstellungspakets sein können. Im Großen und Ganzen gibt es vier Kategorien von Komponenten.

1. Anwendungsartefakte: EAR, WAR, statische Inhalte usw.
2. Middleware-Ressourcenkonfigurationen: Skripte zur Erstellung von Warteschlangen, Themen, Datenquellen usw.
3. Umgebungsspezifische Konfigurationen: Verbindungseigenschaften für Datenbanken, Server und andere Middleware, LDAP-Konfigurationen, Sicherheitsanmeldeinformationen usw.
4. Prozess-Skripte: Skripte zur Automatisierung der Bereitstellung

Vor diesem Hintergrund lassen sich in der gesamten IT-Landschaft die folgenden Muster (in der Reihenfolge ihres Reifegrads) beobachten:

Einfach ad hoc:

Es gibt keinen Standard, der als solcher befolgt wird. Ein Anwendungs-Build mit den Artefakten wird an die Bereitsteller weitergegeben. Die Entwickler führen die erforderlichen Einstellungen durch und stellen die Anwendung bereit, indem sie sich auf ein Bereitstellungsdokument beziehen, das Teil der Veröffentlichung sein kann oder auch nicht. Bei diesem Dokument kann es sich um eine E-Mail handeln, in der die auszuführenden Schritte beschrieben werden, oder um ein Dokument für die Erstveröffentlichung. Dieses Dokument enthält auch die umgebungsspezifischen Konfigurationen und Einstellungen. Es mag zu rudimentär klingen, ist aber selbst in großen Unternehmen eine gängige Praxis.

• Es liegt auf der Hand, dass dies ein zeitraubender und mühsamer Prozess ist.
• Sie geht davon aus, dass sich der Verteilungsprozess oder der Inhalt des Verteilungspakets im Laufe der Zeit nicht ändern wird, was falsch ist.
• Das Bereitstellungswissen (umgebungsspezifische Konfigurationen, Middleware-Konfigurationen und Prozessskripte) ist verstreut und nicht synchron.

Übergang zur Standardisierung:

Jede Version wird von einer Deployment Release Note begleitet, in der Sie alle umgebungsspezifischen Schritte und die Konfiguration für Entwicklung, Test und Produktion finden können. Die erste Version kann eine detaillierte Anleitung zur Bereitstellung sein, gefolgt von späteren Deltaversionen. Diese Deltadokumente enthalten lediglich Anleitungen zur Anpassung der Schritte und der Konfiguration an die Änderungen. Ein allgemeines Bereitstellungsdokument enthält Details wie die auszuführenden Datenbankskripte, die auf dem Server zu erstellenden Warteschlangen, die Konfigurationen für die Verbindung mit LDAP usw. Und auch die für jede Umgebung erforderlichen Konfigurationseigenschaften. Das ist definitiv besser als das vorherige Szenario, kann Ihnen aber immer noch Alpträume bereiten.

• Es handelt sich immer noch um einen manuellen Prozess, bei dem viel davon abhängt, wie gut der Verteiler die Anweisungen befolgt, und der daher fehleranfällig ist.
• Es gibt keine Möglichkeit, zwei Versionen zu vergleichen.
• Die Bereitstellung dauert länger und ist für einen neuen Mitarbeiter schwierig. Er wühlt sich durch einige Jahre alte Dokumente, die vielleicht nicht mehr relevant sind. Viele Informationen über das "Wie", "Was" und "Wo" befinden sich noch in den Köpfen des Implementierungsteams. Es ist also weder hilfreich noch effizient, einfach nur Deltas freizugeben.
• Deployment Knowledge ist organisiert, aber mit Einschränkungen.

Der standardisierte Ansatz:

Es wird eine Veröffentlichungsstruktur festgelegt und ein bestimmtes Format für die Anordnung der Artefakte befolgt.

Es mag zwar ein Versionsdokument geben, aber der Schwerpunkt liegt eher darauf, das Bereitstellungswissen aus den Dokumenten herauszunehmen und für die Automatisierung verfügbar zu machen. Es geht also um den Übergang von der manuellen Bereitstellung zur automatisierten Bereitstellung.

Ein typisches automatisiertes Bereitstellungspaket besteht aus ordentlich angeordneten Artefakten, begleitet von umgebungsspezifischen Konfigurationen und wahrscheinlich auch den Bereitstellungsskripten. Ist es also gut? Bis zu einem gewissen Punkt, ja. Es macht Ihre Bereitstellungen zuverlässig und schneller. Aber wie Sie sehen können, sind die umgebungsspezifischen Konfigurationen und die Bereitstellungsartefakte, die beide Teil des Bereitstellungspakets sind, eng miteinander verbunden. Dies führt zu einigen neuen Problemen, die gelöst werden müssen:

• Die Entwickler sind für die Freigabe verantwortlich und verpacken die umgebungsspezifischen Konfigurationen, die ihnen vom Bereitstellungsteam zur Verfügung gestellt werden. Dies ist anfällig für Fehler.
• Außerdem sind einige der Konfigurationen (z.B. die Konfigurationen der Produktionsumgebung) für die Entwickler möglicherweise nicht sichtbar. Diese können also leer bleiben und erfordern weiterhin manuelle Schritte.
• Rollbacks zu einer bestimmten Version bereiten immer noch Kopfschmerzen. Es gibt kein Gerät, mit dem Sie die Änderungen und Schritte direkt vergleichen können, um zu einer früheren Version zurückzukehren.
• Es gibt keine Möglichkeit, redundante Infrastrukturen oder Konfigurationen, die nicht mehr verwendet werden, automatisch loszuwerden.
• Die Anpassung Ihres Bereitstellungspakets für eine neue Umgebung ist ebenfalls ein manueller und zeitaufwändiger Prozess.
• Die Versionsstruktur könnte ein komplexer Baum von Ordnern und Unterordnern mit den dazugehörigen Skripten und Konfigurationen werden.

Die Bündelung der Umgebungskonfigurationen in das Bereitstellungspaket selbst birgt also gewisse Nachteile und Einschränkungen. Gibt es einen Ausweg?

Alles richtig machen:

Aus unserer Erfahrung haben wir gelernt, dass eine ideale Einsatzeinheit die folgenden Merkmale aufweisen sollte:

• Eine Bereitstellungseinheit sollte einfach sein und sich nur auf die Artefakte (und Middleware-Konfigurationen) konzentrieren. Wenn wir ein einfaches Bereitstellungspaket mit Artefakten und Middleware-Konfigurationen vorschlagen, scheint es, als wären wir wieder bei Null, aber die Idee ist, dass die umgebungsspezifischen Konfigurationen von Automatisierungswerkzeugen für die Bereitstellung verwaltet werden.
• Die Umgebungskonfiguration sollte als ein Aspekt betrachtet werden, der auf ein Bereitstellungspaket angewendet wird, damit es in einer bestimmten Umgebung funktioniert. Es ist verständlich, dass sie die "Brücke" zwischen Ihrem Bereitstellungspaket und der Umgebung, in der es bereitgestellt wird, darstellt. Daher sollte sie separat behandelt werden.
• Die Bereitstellungseinheit und die darin enthaltenen Artefakte sollten versionierbar sein.
• Es sollte einfach sein, mit wenig oder gar keinem Aufwand zwischen den Versionen zu wechseln.
• Die Bereitstellung von Wissen sollte automatisiert werden.

Ist es möglich, das Bereitstellungspaket einfach zu halten und dennoch die Vorteile der Bereitstellungsautomatisierung zu nutzen? Mit Deployit ist es genau das, was wir erreichen wollen. Im nächsten Blog folgen wir dem Ansatz von Deployit und den Vorschlägen, wie man es "richtig" macht.