Anfang des Jahres war ich eingeladen, auf den Devopsdays Boston einen Vortrag über Deployment als das neue Build: wie Deployments heute durchgeführt werden, wie sie sich in einer stärker virtualisierten, bedarfsgesteuerten Anwendungslandschaft anpassen müssen und welche grundlegenden Verbesserungen notwendig sind, bevor das Deployment zu der unsichtbaren, einfach funktionierenden Erfahrung reift , die Build heute ist.
Im vorigen Beitrag haben wir uns angesehen, wie wiederverwendbare Befehle, Modelle und Konventionen++ dazu beigetragen haben, Build von einem "Blackbox"-Prozess zu der "einfach funktionierenden" Erfahrung zu machen, die wir heute kennen.
Wir kehrten dann zur Bereitstellung zurück und identifizierten Develop a common model, (Re)discover vanilla und Support a "clean build" als drei wichtige Schritte, die für einen ähnlichen Übergang erforderlich sind.
Entwickeln Sie ein gemeinsames Modell
Bevor wir zur 'Modell'-Phase übergehen können, brauchen wir zunächst... nun ja... ein Modell. Zum Glück reicht ein sehr einfaches Modell aus:
Pakete,
Umgebungen und
Einsätze.
Das hat nichts Magisches an sich, und die Konzepte sind in den meisten Unternehmen bereits bekannt. Aber wenn Sie diesen Dingen eindeutige Bezeichnungen geben, hilft das nicht nur, die Ideen zu formalisieren und den Entwicklern und Anbietern etwas zu geben, das sie unterstützen können. Es schafft auch ein gemeinsames Vokabular und eine gemeinsame Sprache für die Bereitstellung, was der erste Schritt zu einem gemeinsamen Verständnis und zu wiederverwendbaren Funktionen ist.
Die Konzepte sind in der Tat so grundlegend, dass es anscheinend nicht viel darüber zu sagen gibt.
Pakete enthalten die Komponenten des freizugebenden versionierten Objekts, sowohl Artefakte in Form von Dateien als auch Konfiguration, Ressourceneinstellungen und Metadaten.
Gemäß den Best Practices für das Versionsmanagement sollten die Pakete in einer
DSL gespeichert werden und unabhängig von der Zielumgebung sein, so dass Sie ein "Goldstandard"-Paket haben, das in Entwicklung, Test, QA und Produktion läuft.
Pakete bedeuten auch, dass wir alles versionieren können, nicht nur die Anwendungsbinärdateien, sondern auch die zugehörigen Konfigurations- und Umgebungseinstellungen.
Die gerade erwähnten Entwicklungs- und
Testumgebungen sind Beispiele für
Umgebungen, d.h. einfache Sammlungen von Infrastrukturen - physisch, virtuell, langfristig, auf Abruf, was auch immer -, in denen Anwendungen im Laufe des
ALM-Zyklus ausgeführt werden, möglicherweise mit Genehmigungen oder anderen Kontrollpunkten, die den Übergang von einer zur nächsten regeln.
Die
Bereitstellung ist also vielleicht das Konzept, das nicht sofort allgemein verstanden wird. Eine Bereitstellung ist nicht nur der Vorgang, ein Paket in einer bestimmten Umgebung zum Laufen zu bringen, mit Start- und Endzeit, ausführendem Benutzer, Status usw.
. Vielmehr dokumentiert eine Bereitstellung auch die Art und Weise, in der die Komponenten des Pakets bereitgestellt und gegebenenfalls angepasst wurden. So wird in einer Bereitstellung beispielsweise festgehalten, dass eine bestimmte EAR-Datei des Pakets auf dem/den folgenden Zielserver(n) oder -cluster(n) bereitgestellt wurde oder dass das Kennwort für die Datenquelle für diese bestimmte Umgebung angepasst und auf einen neuen Wert gesetzt wurde.
Die Aufzeichnung dieser Informationen ist von entscheidender Bedeutung, da es sehr schwierig ist, den Zustand einer Anwendung intelligent und korrekt zu ändern - beispielsweise beim Upgrade auf eine neue Version oder beim Hinzufügen neuer Server zum Zielcluster -, wenn Sie nicht wissen, wo und mit welchen Einstellungen die Anwendung derzeit ausgeführt wird.
Vanille (wieder)entdecken
Wenn wir eine mühelose Bereitstellung auf Knopfdruck erreichen wollen, müssen wir auch überdenken, ob wir unsere Infrastruktur wirklich auf jede erdenkliche Weise optimieren und anpassen müssen. In einigen Unternehmen scheint es sogar so zu sein, dass jede Einstellung, die eine Standardeinstellung sein könnte, mit Misstrauen betrachtet und vorzugsweise geändert werden sollte.
Genauso wie benutzerdefinierte Projektlayouts die Einrichtung eines Builds in einem auf Konventionen und Modellen basierenden System unnötig mühsam und kompliziert gemacht haben, wird es durch die sture Weigerung, die Standardeinstellungen für die Infrastruktur zu verwenden, schwieriger, problemlose Bereitstellungen zu erreichen, die wirklich alle erforderlichen Schritte abdecken.
Das Festhalten an Vorgaben fördert nicht nur die Wiederverwendbarkeit, da die Wahrscheinlichkeit, dass eine für ein anderes Szenario entwickelte Lösung auch in Ihrem funktioniert, viel höher ist. Es verbessert auch die Wartbarkeit und verringert das Risiko von "Ripple"-Änderungen, bei denen ein benutzerdefinierter Wert in der Einstellung für die Server, die Anwendung X hosten, weitere Änderungen an der Einrichtung von Anwendung Y usw. erfordert.
Unterstützen Sie einen "sauberen Aufbau".
Bei der Erstellung eines großen Projekts versuchen wir, die benötigte Zeit zu verkürzen, indem wir nur den Quellcode neu kompilieren, der geändert wurde. Bei der Bereitstellung von Anwendungen möchten wir ebenfalls Zeit sparen, wenn wir auf eine neue Version aktualisieren, vor allem, wenn diese Zeit eine Ausfallzeit in der Produktion darstellt.
Wir wissen jedoch auch, dass einige Teile jedes inkrementellen Builds irgendwann nicht mehr synchron sind, was zu seltsamen Kompilierungsproblemen führt oder dazu, dass Funktionen oder Korrekturen nicht zum richtigen Zeitpunkt erscheinen.
Was tun wir in einem solchen Fall? Versuchen wir mühsam, die Dateien ausfindig zu machen, die nicht mehr synchron sind, und bauen sie Stück für Stück neu auf? Nein, wir führen einfach einen Clean-Build aus, um bei Null anzufangen, denn in 99% der Fälle ist es viel schneller, einfach neu zu bauen, als zu versuchen, die Ursache des Problems ausfindig zu machen.
Im Land der Bereitstellung haben wir nur selten die Möglichkeit, einen Clean-Build auszuführen, und das ist eine der Hauptursachen für die stressige, zeit- und ressourcenaufwändige Fehlersuche, die immer noch viel zu häufig vorkommt. Um ein System sauber zu erstellen, benötigen wir natürlich eine vollständige Versionierung der Umgebung, ihrer Konfiguration und der darauf installierten Anwendungen. Virtuelle Appliances und Virtualisierungslösungen mit Snapshot-Funktionen werden hier eine wichtige Rolle spielen.
Auch für langlebige Ressourcen wie Datenbanken benötigen wir einen bekannten Zustand, was nach wie vor eine Herausforderung darstellt, aber von einer wachsenden Zahl von Produkten angegangen wird.
Einsätze auf Knopfdruck
Wenn wir eine Bilanz ziehen, ist klar, dass wir noch einen weiten Weg vor uns haben. Wir entwickeln langsam ein gemeinsames Modell, aber sowohl die "(Wieder-)Entdeckung von Vanille" als auch die "Unterstützung eines "sauberen Builds" sind Visionen, die für die meisten großen Unternehmen noch nicht in Sicht sind.
Tatsächlich sind es nicht so sehr technologische Fortschritte, die erforderlich sind - viele Startups sind schon ziemlich nah dran an Push-Button-Deployments und Continuous Delivery. Die "Aushängeschilder" dieser Bewegung verfügen bereits über Systeme, bei denen jeder Commit eine ganze Reihe von Regressions-, Integrations- und Leistungstests durchläuft und potenziell direkt in Produktion gehen kann.
Nein, die wichtigsten Hürden, die es zu nehmen gilt, sind verfahrenstechnischer und mentaler Natur, d.h. es gilt, eingerostete Arbeitsweisen und eingefahrene Denkweisen zu ändern. Für diejenigen, die es schaffen, sind die Vorteile in Form eines beschleunigten Geschäftsnutzens jedoch schon jetzt ein echter Wendepunkt.
