Die Bereitstellung ist der neue Build (Teil 2)

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 On-Demand-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 letzten Beitrag haben wir das Deployment mit einem anderen Schlüsselprozess im Anwendungslebenszyklus verglichen - dem Build - und gefragt, welche wichtigen Entwicklungen es von einer magischen "Blackbox" zu dem "einfach funktionierenden" Prozess gemacht haben, der es heute ist. Wir haben wiederverwendbare Befehle, Modelle und Konventionen++ als drei wichtige Schritte identifiziert, auf die wir in diesem Beitrag näher eingehen werden. Dann werden wir uns wieder mit der Bereitstellung befassen und fragen, welche Verbesserungen wichtig sind, um hier zu "just works" zu gelangen.

Wiederverwendbare Befehle

Der erste Schritt, der durch Apache Ant verkörpert wurde, war die Erkenntnis, dass die meisten Aufgaben oder Aktionen auf niedriger Ebene unabhängig von der zu erstellenden Anwendung gleich sind, sei es der Aufruf eines Compilers, das Kopieren von Dateien oder das Ersetzen von Platzhaltern. Anstatt dieselben Betriebssystembefehle in jedes neue Build-Skript zu kopieren, kapselten wir diese Befehle als Bibliotheken mit wiederverwendbaren Komponenten, die nur einmal geschrieben werden mussten. Außerdem entdeckten wir, dass bestimmte Muster von Schrittfolgen in vielen verschiedenen Builds auftauchten. Diese "Abschnitte", wie z.B. das Erstellen eines Klassenpfads oder das Kopieren und Verarbeiten statischer Ressourcen, stellten offensichtlich eine übergeordnete Build-Aktivität mit einer bestimmten Funktion dar.

Modelle

Während die Erkenntnis, dass alle Aktionen, die in einem Build ausgeführt werden, im Grunde eine Abfolge gemeinsamer Chunks sind, ein wichtiger Anfang war, wurde der nächste große Fortschritt dadurch erzielt, dass wir erkannten, dass wir nicht nur wiederkehrende Muster von Aktionen sahen, sondern dass auch die Arten von Daten, die diese Aktionen bearbeiteten, gemeinsam waren. Daraus entstand das Konzept eines echten Domänenmodells für Anwendungs-Builds mit Quellensets, Ressourcensets, Modulen, Abhängigkeiten usw., das ursprünglich von Maven eingeführt wurde und seitdem in allen Build-Systemen zu finden ist und wiederverwendet wird. Durch die Kombination der Abfolge gemeinsamer Chunks mit dem neuen Domänenmodell, das die zu verarbeitenden Daten strukturiert, entstand der Begriff der verschiedenen Phasen, in denen Teile des Build-Modells generiert, vorbereitet und für nachfolgende Befehle verfügbar gemacht werden. Darüber hinaus unterstützte Maven auch die Idee, dass das Domänenmodell und damit die Build-Phasen leicht variieren können müssen, um verschiedene Arten von Java-Artefakten, die bereitgestellt werden müssen, wie JARs und EARs, zu berücksichtigen. Dies wurde später weiterentwickelt, um Builds von völlig anderen Technologien wie Adobe Flex-Anwendungen zu unterstützen.

Konventionen++

Ein zusätzlicher Vorteil von Domänenmodellen für Builds war die Möglichkeit, Standardwerte auf strukturierte Weise zu verwenden, z.B. für die Namen der erstellten Artefakte oder den Speicherort von Ressourcendateien. Die Kehrseite dieser Bequemlichkeit, sicherlich in Kombination mit XML als Deskriptorsprache für Builds, bedeutete jedoch, dass ein Abweichen von diesen Standards eine ziemliche Herausforderung sein konnte. Vor allem dann, wenn das Ziel darin bestand, das Domänenmodell in irgendeiner Weise zu erweitern oder eine Sprache oder Technologie zu unterstützen, deren Build-Flow sich deutlich von dem von Java unterscheidet, wie z.B. die Erstellung von Dokumentationspaketen oder Images virtueller Maschinen.Dies hat zu einer Generation von Build-Tools wie Gradle geführt, die darauf abzielen, dem Entwickler wieder die volle Kontrolle zu geben, in dem beliebige Aktionen einfach definiert und in Phasen, Aufgaben und ganze Builds organisiert werden können. Angesichts der Tatsache, dass wir uns an die Bequemlichkeit von "es funktioniert einfach" in einfachen Fällen gewöhnt haben, unterstützen diese Tools natürlich immer noch die vollständigen Domänenmodelle und Konventionen von gängigen Technologien wie Java.

Wer hätte das gedacht?

Wenn man diese Entwicklung aus heutiger Sicht betrachtet, fallen einige Fakten auf, die im Vergleich zu anderen Entwicklungen in der IT ziemlich überraschend sind. Erstens: Obwohl es heute schwer vorstellbar ist, eine Abhängigkeit mit etwas anderem als dem Muster groupId:artifactId:version zu spezifizieren, wurde keines der Modelle oder Konventionen, die sich entwickelten, in Industriestandards formalisiert. Stattdessen basierten sie entweder auf der Beobachtung gängiger Muster oder wurden einfach clever oder sogar etwas willkürlich gewählt (src/main/javazum Beispiel).Zweitens haben wir gesehen, wie die auf Konventionen basierende Benutzerfreundlichkeit in Verbindung mit einem moderaten Störfaktor bei der Anpassung dieser Konventionen das Benutzerverhalten dramatisch verändern kann. Anfänglich verbrachten beispielsweise viele Maven-Neulinge viel Zeit damit, die Standardeinstellungen an ihre eigene Umgebung, Namenskonventionen, Dateipfade usw. anzupassen, und produzierten dabei eine ganze Menge XML.Schon bald wurde es jedoch einfacher, sich an die Standardwerte von Maven zu halten und damit fertig zu werden, insbesondere als das Verhältnis von Greenfield- zu Legacy-Projekten zunahm. Heute sind diese Konventionen so standardisiert, dass sie nicht nur von Maven, sondern im Wesentlichen auch von allen anderen Build-Systemen unterstützt werden.Es sind aber nicht nur die Vorlieben der Benutzer, die zur Übernahme von Standardkonventionen "verführt" wurden. In vielen Fällen wurden Unternehmensstandards, die zuvor als unumstößlich galten, nach und nach verworfen oder modifiziert, wenn sie nicht ohne weiteres von den entstehenden De-facto-Standards übernommen werden konnten. Die Benutzerfreundlichkeit konnte sich gegen abstrakte Regeln durchsetzen.

Und der Einsatz?

So viel zum Build-Prozess. Wie sieht es mit der Bereitstellung aus, die heute die entscheidende Hürde für die Automatisierung in der Wertschöpfungskette eines Unternehmens darstellt? Wie bereits erwähnt, liegt der aktuelle Branchendurchschnitt irgendwo zwischen "Blackbox" und "Schrittfolge". In Bezug auf die Beschreibungen der Entwicklung des Build-Prozesses befinden sich die fortschrittlichsten Systeme zur Automatisierung der Bereitstellung irgendwo jenseits von "wiederverwendbaren Befehlen".Was natürlich die Frage aufwirft: Wie kommen wir zu einem Zustand, in dem wir auf Knopfdruck arbeiten können? Was müssen wir tun, um den Reifegrad des Build-Prozesses von heute zu erreichen? Wenn wir uns ansehen, was wir heute in der Branche antreffen, werden drei Aspekte entscheidend sein:

1. Entwickeln Sie ein gemeinsames Modell
2. Vanille (wieder)entdecken
3. Unterstützen Sie einen "sauberen Aufbau".

    
Deployment is the New Build Part 1
    
Deployment is the New Build Part 2
    
Deployment is the New Build Part 3