Anpassen: Anpassung der Bereitstellungspakete an Ihre Zielumgebungen

Irgendwann in der Zukunft werden Sie in der Lage sein, dieselbe virtuelle Appliance, die Ihre Anwendung enthält, ohne Anpassungen in all Ihren Zielumgebungen einzusetzen. Bis dahin bedeutet die Bereitstellung in traditionellen DTAP1-Landschaften jedoch fast immer, dass Sie die Anwendung und die damit verbundenen Konfigurationen und Ressourcen an die Zielumgebung anpassen müssen - denken Sie an Endpunkte, Eigenschaftsdateien oder Datasource-Benutzernamen und Kennwörter, um nur einige zu nennen. In Ermangelung etablierter Standards oder gar Richtlinien in diesem Bereich wurden viele verschiedene Lösungen für dieses Problem der Anpassung von Bereitstellungspaketen verwendet, von recht eleganten Ansätzen wie JMX bis hin zu grobem Suchen und Ersetzen von Strings. Darüber hinaus bieten verschiedene Arten von Middleware-Plattformen einen unterschiedlichen Grad an Unterstützung für Anpassungen: Portale, ESBs und Prozessserver bieten in der Regel eine "native" Lösung für das Problem, während Anwendungsserver die Benutzer eher sich selbst überlassen. In den meisten Fällen ist das Ergebnis eine chaotische Mischung von Anpassungsansätzen für verschiedene Projekte, Zielplattformen und ^Abteilungen2. Im Folgenden werden wir uns einige dieser Ansätze ansehen, sie klassifizieren und einige Nachteile und Vorteile untersuchen.

Wichtige Überlegungen: Wonach suchen wir also...?

Wenn Sie verschiedene Ansätze zur Anpassung vergleichen, müssen Sie einige Dinge beachten:

1. Bequemlichkeit: Das Anpassungsverfahren sollte einfach einzurichten und schnell auszuführen sein. Dies ist vor allem für Entwickler wichtig, die eine Anpassung durchführen müssen, sobald die Anwendung in der Entwicklungsumgebung bereitgestellt wird.
2. Sichtbarkeit: Es sollte für entsprechend autorisierte Benutzer einfach sein, sowohl die Anpassungspunkte (d.h. welche Teile der Anwendung angepasst werden können) als auch die ihnen zugewiesenen Werte in einer bestimmten Umgebung zu sehen.
3. Ausfallsicherheit: Wenn eine Anwendung mit fehlenden oder ungültigen Werten für Anpassungspunkte bereitgestellt wird (z.B. wenn Sie vergessen haben, einen Timeout zu setzen oder den Test-Endpunkt für die Produktionsumgebung zu verwenden), sollte dies schnell erkannt werden. Vorzugsweise sollten fehlende oder falsche Werte bereits bei der Bereitstellung erkannt werden, damit sie nicht erst durch fehlerhaftes Verhalten zur Laufzeit auffallen.
4. Überarbeitung und Zugriffskontrolle: Nur geeignete Benutzer sollten in der Lage sein, die den Anpassungspunkten einer Anwendung zugewiesenen Werte anzuzeigen und zu bearbeiten. Vorzugsweise sollte eine Historie der Änderungen an diesen Werten geführt werden. Dies erleichtert den Vergleich der Werte für eine Anwendung zwischen verschiedenen Versionen und ermöglicht es Benutzern, die Werte für dieselbe Version einer installierten Anwendung in verschiedenen Zielumgebungen zu vergleichen.

Warten Sie es ab... Tun Sie dies zur Laufzeit

Wie immer ist ein guter Weg, ein Problem anzugehen, der, es zu vermeiden. In diesem Fall können Sie die Notwendigkeit, die Anwendung zur Bereitstellungszeit zu optimieren, umgehen, indem Sie die Suche nach Anwendungseigenschaften auf die Laufzeit verschieben und JMX (das schließlich auch für diesen Zweck entwickelt wurde) mit geeigneten Standardwerten verwenden. Sie erhalten die gesamte Zugriffskontrolle, die Verlaufsverwaltung usw. der JMX-Implementierung kostenlos und können die umgebungsspezifischen Werte aktualisieren, ohne die Anwendungsdateien bearbeiten zu müssen.Das funktioniert natürlich nur, wenn Ihr Container eine geeignete JMX-Implementierung bereitstellt - andernfalls macht die Einrichtung Ihrer Entwicklungsumgebung wahrscheinlich nicht viel Spaß. Grundsätzlich funktioniert dies nicht für Attribute, die vor dem Start der Anwendung festgelegt werden (z.B. der Kontext-Root) oder für Eigenschaften von Middleware-Ressourcen (wie z.B. eine Zeitüberschreitung für Warteschlangenwiederholungen).

1. Bequemlichkeit: In der Regel mäßig, da die Umgebung des Entwicklers in der Regel nicht einfach einzurichten ist. Dies hängt jedoch stark von der Unterstützung der Zielplattform für JMX oder dem verwendeten Nachschlagemechanismus ab. Dies muss gegen den Vorteil abgewogen werden, dass Sie das Verhalten der laufenden Anwendung ändern können.
2. Sichtbarkeit: Im Falle von JMX gut, da alle MBeans und ihre Eigenschaften leicht zu erkennen sind, insbesondere wenn eine vernünftige Namenskonvention verwendet wird.
3. Ausfallsicherheit: JMX verlangt normalerweise "sichere" Standardwerte (die nicht umgebungsspezifisch sein sollten).
4. Überarbeitung und Zugriffskontrolle: Auch hier hängt es von der Implementierung der Zielplattform ab. Aber im Allgemeinen gut, vor allem die Zugriffskontrolle, da sie normalerweise in die Verwaltungskonsole des Middleware-Stacks integriert ist.

Ersetzen Sie mich: Token-basierte Ersetzung

Token-basierte Ersetzung bedeutet im Grunde Platzhalter - das Bereitstellungspaket enthält (in Artefakten, Ressourcendefinitionen usw.) spezielle Symbole, und zum Zeitpunkt der Bereitstellung werden diese Symbole durch die für sie bereitgestellten Werte ersetzt. Die Token-basierte Anpassung erfordert, dass der Anbieter, in der Regel die Entwickler, die Deployment-Artefakte speziell vorbereitet.Das bedeutet, dass erstens alle Token, die ersetzt werden müssen, zum Zeitpunkt der Auslieferung bekannt sind3, was den zusätzlichen Vorteil hat, dass die Anwendung nun über einen genau definierten Satz von Anpassungspunkten verfügt. Die spezielle Syntax der Token macht es außerdem relativ einfach zu überprüfen, ob die Werte für alle Token geliefert wurden.Selbst wenn diese Überprüfung fehlschlägt, wird die Anwendung vermutlich aufgrund von Syntaxfehlern - Token sind in der Regel keine gültigen Werte - abbrechen, was einen zusätzlichen "Fail-Safe"-Mechanismus bietet.Natürlich kann dieser Fail-Safe-Mechanismus aus Sicht eines Entwicklers auch ein Ärgernis sein. Da die Anwendung erst dann funktioniert, wenn die Token ersetzt wurden, müssen Build-Prozesse so eingerichtet werden, dass dies schnell geschieht, vor allem in Entwicklungsumgebungen.

1. Bequemlichkeit: Mäßig, da der Build-Prozess so eingerichtet werden muss, dass er Dateien mit Token korrekt verarbeitet. Wenn Sie in einer Entwicklungsumgebung wie Eclipse mit WTP arbeiten, kann es schlimmer sein, vor allem, wenn es die "Hot-Update"-Funktionen beeinträchtigt.
2. Sichtbarkeit: Wo immer es ein Token gibt, gibt es auch einen Anpassungspunkt, so dass sie klar und selbstdokumentierend sind. Wenn Sie JNDI verwenden, die wohl "richtige" Art der tokenbasierten Ersetzung in JEE, sind die zugewiesenen Werte in der Regel auch sehr leicht in der Konsole zu sehen. Die Einsicht in die zugewiesenen Werte kann schwieriger sein, wenn Sie mit dateibasiertem Suchen und Ersetzen arbeiten, wie es bei Eigenschaftsdateien üblich ist, da Sie nicht nur das endgültige Artefakt haben müssen, um die Werte zu sehen, sondern sich auch das Original ansehen müssen, um zu sehen, wo die Platzhalter waren.
3. Ausfallsicherheit: Hoch, was im Zusammenhang mit einer geschäftskritischen Aktivität wie der Bereitstellung entscheidend ist. Token sind fast nie gültige Werte. Wenn Sie also vergessen, einen Wert zuzuweisen, führt dies in der Regel zu einer fehlgeschlagenen Bereitstellung. Natürlich besteht immer noch die Gefahr, dass die Token durch Werte für die falsche Umgebung ersetzt werden.
4. Überarbeitung und Zugriffskontrolle: Hängt davon ab, wie die Werte, die den Anpassungspunkten zugewiesen werden sollen, bereitgestellt werden. Bei JNDI sind eine gute Revisionierung und Zugriffskontrolle in der Regel "kostenlos" in der Konsole enthalten. Was den allgemeinen Fall der Eigenschaftsdateien betrifft, so haben wir schon alles gesehen: von Dateien, die nicht versioniert sind und als Teil eines "Vorlagenprojekts" mit allen geteilt werden, bis hin zu solchen, die in einem speziellen Versionskontrollsystem gepflegt werden.

Ersetzen Sie das: Zeigerbasierte Ersetzung

Zeigerbasierte Ersetzung ist im Wesentlichen eine schicke Umschreibung für "Suchen und Ersetzen" und seinen etwas fortgeschritteneren Cousin, die XPath-basierte Ersetzung, die häufig in Portal- oder ESB-Umgebungen verwendet wird. Diese Methode ist anfällig, weil das Bereitstellungspaket gültige Werte enthält, so dass die Gefahr eines stillen Fehlers groß ist. Außerdem sind die Anpassungspunkte des Pakets im Wesentlichen unsichtbar. Ironischerweise kann dies nützlich sein, um Pakete zu "patchen", die nicht in einer anpassbaren Weise geschrieben wurden.Es ist im Allgemeinen wahr, dass es viel einfacher ist, ein Bereitstellungspaket für eine zeigerbasierte Anpassung vorzubereiten - es geht einfach darum, die Einstellungen und Artefakte der Entwicklungs- oder einer anderen "Autoren"-Umgebung zu exportieren oder einen Schnappschuss davon zu erstellen. Natürlich kann ein solcher Export "tokenisiert" werden (indem die Werte, die angepasst werden müssen, durch Token ersetzt werden), aber das ist fehleranfällig und kann einen unerschwinglichen manuellen Aufwand bedeuten, was vor allem während der Entwicklung ein Problem darstellt, wenn solche Exporte häufig durchgeführt werden. Natürlich ist eine zeigerbasierte Anpassung nur möglich, wenn die Artefakte oder Definitionen, die angepasst werden müssen, in irgendeiner Weise strukturiert sind - andernfalls ist es nicht möglich, einen Zeiger zu konstruieren, der auf das zu ändernde Element verweist. XML- und Ressourcendefinitionen (d.h. Eigenschaftsdateien ) fallen in diese Kategorie, aber z.B. einfache Textdateien fallen nicht darunter.

1. Bequemlichkeit: Hoch. Die Quellanwendung enthält gültige Werte, kann also "so wie sie ist" ausgeführt werden.
2. Sichtbarkeit: Anpassungspunkte sind in den Quelldateien nicht sichtbar, obwohl sie (mehr oder weniger leicht) aus der Angabe der Zeiger abgeleitet werden können, die definieren, wo Werte ersetzt werden müssen. Die zuzuweisenden Werte werden normalerweise zusammen mit den Zeigerspezifikationen definiert.
3. Ausfallsicherheit: Schwach, da die Quellanwendung (syntaktisch) gültige Werte enthält, auch wenn die Ersetzung nicht oder nur teilweise durchgeführt wird. Das bedeutet, dass es eine ganze Weile dauern kann, bis sich das Problem manifestiert, und zwar oft auf unerklärliche Weise - ein Alptraum für die Wartung.
4. Überarbeitung und Zugriffskontrolle: Hängt wiederum davon ab, wie die Zeiger und Werte spezifiziert und gespeichert werden. Da die Zeigerspezifikationen in der Regel in derselben Datei enthalten sind wie die zuzuweisenden Werte, ist es in der Regel nicht möglich, den Zugriff auf die Definitionen der Anpassungspunkte (d.h. der Zeiger) - in der Regel eine Aktivität des Entwicklers - vom Zugriff auf die zugewiesenen Werte zu trennen, die oft nur den Operatoren bekannt sein sollten.

Und...?

Wenn die für Ihre Anwendung erforderlichen Anpassungen nach dem Start der Anwendung vorgenommen werden können, ist es sicherlich eine Überlegung wert, Ihre Anwendung so zu gestalten, dass sie zur Laufzeit konfigurierbar ist. Das macht die Verwaltung der Anwendung bequemer und sicherer, erhöht aber natürlich auch die Komplexität bei der Entwicklung. Und in einigen Fällen4 müssen Anpassungen vorgenommen werden , bevor die Anwendung geladen wird.Während die zeigerbasierte Ersetzung bequem ist und auch bei Anwendungen verwendet werden kann, die nicht für eine Anpassung konzipiert wurden, bietet die tokenbasierte Ersetzung erhebliche Vorteile in Bezug auf (Ausfall-)Sicherheit und Transparenz. Da es sich bei der Bereitstellung oft um geschäftskritische Anwendungen handelt, sind dies wesentliche Vorteile, die dazu führen sollten, dass Token bevorzugt werden, wo immer dies möglich ist. Leider haben viele der bestehenden Middleware-Plattformen dieses Problem nicht angemessen berücksichtigt. Dies ist ein weiterer Grund, warum eine Automatisierungslösung für die Bereitstellung wie Deployit, die darauf ausgelegt ist, Anpassungen auf konsistente und sichere Weise zu unterstützen, einen großen Vorteil darstellt.

Ein Wort zu umgebungsspezifischen Builds Jeder, der schon einmal versucht hat, mitten in einer Bereitstellung vage Anweisungen zur Anpassung der Anwendung zu befolgen, hat sich wahrscheinlich gefragt, warum dies nicht auf eine weniger fehleranfällige Weise geschehen kann. Da nur wenige über eine geeignete Automatisierung der Bereitstellung verfügen, besteht eine gängige Alternative darin, zu versuchen, die Anpassung in den (kontinuierlichen) Build-Prozess zu integrieren.Aus technischer Sicht kann dies sicherlich wie eine einfache Option aussehen: Es gibt großartige Open-Source- und kommerzielle Continuous-Build-Produkte, und die meisten Unternehmen haben bereits eines im Einsatz. Viele der Tools unterstützen das Konzept von "Profilen" oder ähnlichen Anpassungsmechanismen, und wenn nicht, bieten sie alle Haken, um Ihre eigenen Such- und Ersetzungsfunktionen hinzuzufügen.Der größte Nachteil dieses Ansatzes ist verfahrenstechnischer Natur: Umgebungsspezifische Details müssen während des Build-Prozesses zugänglich sein. Das sollte sich nicht einfach "falsch" anfühlen, denn einige dieser Informationen können hochsensibel sein - denken Sie nur an die Passwörter für die Produktionsdatenbank -, so dass diese Lösung aus Sicht der Sicherheit nicht praktikabel ist. Außerdem bieten Continuous Build Tools in der Regel keine geeigneten ^{Repositories5} für diese umgebungsspezifischen Werte, und env.properties-Dateien sind notorisch anfällig für Copy-Paste- und andere Fehler. Und aus leidvoller Erfahrung: Bei umgebungsspezifischen Builds ist es nur eine Frage der Zeit, bis Sie den Test-Build Ihrer Anwendung versehentlich in der Produktionsumgebung ausführen.