Read in English.
Continuous Delivery macht es sich zum Ziel, durch hochgradige Automatisierung Entwicklungskosten zu senken, Deployment-Vorgänge zu beschleunigen, die Qualität der Prozesse zur erhöhen und so auch flexibler und frühzeitiger auf Kundenanforderungen eingehen zu können. (Eine ausführliche Einführung in das Konzept bietet unsere Video-Session.)
Wie sich dies in der Praxis gestaltet, ist Gegenstand dieses Artikels: Wir werden Atlassians CI-Server Bamboo konfigurieren, um eine einfache Java-Web-Anwendung auf einem Tomcat-Anwendungsserver per Knopfdruck zu installieren.
Grundsätzliches
Wir folgen bei der Verwaltung unseres Prozesses dem Ansatz "fail fast" und wählen einen Methode, die sich aus den folgenden vier Phasen zusammensetzt:
Kompilieren: Hier kompilieren wir Quelltexte, fügen Ressourcen hinzu und generieren benötigte Artefakte für Test und Betrieb unserer Anwendung.
Unit-Tests: In dieser Phase werden isolierte Tests mit schneller Durchlaufzeit ausgeführt. Ein Fehlschlagen in dieser Phase verhindert die zeit- und ressourcenintensivere Ausführung der nächsten Phase.
Funktionale Tests / Integrationstests: In dieser Phase werden komplexere Tests mit höherer Laufzeit und höherem Ressourcenaufwand, die bspw. das Zusammenspiel von Komponenten testen, durchlaufen.
Deployment: In dieser finalen Phase wird die Anwendung auf ein definiertes Zielsystem installiert.
Stages vs. Jobs vs. Tasks: Stages ermöglichen es uns, logische Einheiten zur Ausführung von Jobs zu bilden. Dabei können Jobs innerhalb einer Stage parallel, auch über mehrere Agents verteilt ausgeführt werden. Tasks innerhalb eines Jobs hingegen werden immer seriell innerhalb eines Agenten (Agents) abgearbeitet. (Weitere informationen finden sich in der Bamboo-Doku.)
Erstellung eines neuen Build-Plans in Bamboo
Ein Build-Plan stellt die Grundlage für die beschriebenen Prozessabläufe dar. In ihm werden wir nun zunächst die benötigten Stages hinzufügen.
Konfiguration der Stages
Wir erstellen drei Stages: Unit Test, Integration Test und Package Application.
Stage: Unit Test - In dieser Stage werden wie gesagt schnelllaufende, isolierte Unit-Tests ausgeführt: Ein früher Abbruch unseres Build-Vorgangs hilft, Ressourcen zu sparen. Wir fügen hier einen gleichnamigen Job hinzu. Als ersten Task des erstellten Jobs checken wir zunächst die Quelltexte von einem Git-Repository eines verbundenen Stash-Servers aus. Dann fügen wir einen Maven-Task hinzu, der die Testausführung mittels mvn clean test
triggert.
Artefakte können zwischen Jobs, Build-Plans und natürlich Deployment-Projekten geteilt werden und ermöglichen es, Ergebnisse des Workflows auf dem Bamboo-Server an Folgeoperationen weiterzureichen (siehe nochmals die Bamboo-Dokumentation). Also speichern wir hier die ausgecheckten Projektdateien als Bamboo-Artefakt unter dem Namen Project Sources, damit darauffolgende Stages und Jobs die Daten nicht erneut herunterladen müssen. Artefakte eines Jobs sind über den gleichnamigen Reiter verfügbar (Artifacts).
Stage: Integration Test - Hier würden komplexere Tests mit längerer Laufzeit und höherem Ressourcenbedarf ausgeführt werden. In unserem Beispiel bleibt diese Stage leer; sie soll nur der Veranschaulichung eines realitätsnahen Workflows dienen.
Stage: Package Application - Hier erzeugen wir die Web-Anwendung und packen sie als War-Datei, die dann für das Deployment genutzt werden kann. In diesem Stadium verwenden wir die Sources wieder, die wir in der ersten Stage als Artefakt verfügbar gemacht haben.
Mittels eines Tasks für den Artefakt-Download können wir diese Daten integrieren:
Anschließend fügen wir wieder einen Maven-Task hinzu, um die Anwendung via mvn clean package
zu bauen:
Da wir die gebaute War-Datei für das Deployment zur Verfügung stellen möchten, definieren wir hier erneut ein Artefakt namens Application War File:
Damit können wir mit der Erstellung eines neuen Deployment-Projekts beginnen.
Konfiguration eines neuen Deployments
Deployment-Projekt erstellen
Beim Anlegen eines neuen Deployment-Projekts geben wir zunächst einen Namen für unser Projekt an und wählen den entsprechenden Build-Plan und den Branch für das Deployment aus.
Neue Umgebung erstellen
Wenn die Anwendung auf unterschiedliche Server eingespielt werden soll (beispielsweise Staging, Produktion, Preview, Test etc.), so können wir diese durch die Konfiguration von Deployment-Umgebungen (Environments) differenzieren. Wir erstellen hier eine neue Umgebung namens Preview:
Deployment-Tasks erstellen
Hier definieren wir die einzelnen Schritte, die für das Einspielen unserer War-Datei auf den Anwendungsserver notwendig sind:
Arbeitsverzeichnis aufräumen: Dieser Schritt (Clean working directory) ist per Standard bereits aktiviert. Wir belassen diesen Schritt, um immer mit einem bereinigten Arbeitsverzeichnis zu starten.
Download des War-Datei-Artefakts: Im nächsten Task weisen wir Bamboo an, die War-Datei, die wir als Artefakt im Build-Plan exportiert haben, für das Deployment bereitzustellen, indem wir einen Artifact Download Task hinzufügen:
Deinstallation der Anwendung auf dem Tomcat-Server: Wir entfernen die Anwendung vom spezifizierten Tomcat-Server mithilfe eines Tasks Undeploy Tomcat Application.
Installation der Anwendung auf dem Tomcat-Server: Nun installieren wir die aktuelle Anwendung mithilfe der War-Datei und eines Tasks Deploy Tomcat Application auf dem dedizierten Tomcat Server.
Durchführung eines Deployments
Jetzt sind wir bereit, ein Deployment per Knopfdruck durchzuführen. Die einzige Bedingung ist, dass der Build-Plan erfolgreich durchlaufen wurde. Also los: Wir wählen die Umgebung Preview aus und klicken auf Deployment:
Im nächsten Schritt kann dann ein neues Release aus dem Ergebnis des Durchlaufs unseres Build-Plans erstellt werden:
Start Deployment startet den Vorgang und wechselt in die Protokollansicht, wo wir die Log-Ausgaben der einzelnen Tasks und Prozesse einsehen können. Im Anschluss sollte eine Erfolgsmeldung wie die folgende ausgegeben werden:
Die Release-Übersicht bietet Details zum Release:
Optional kann ein Release nun noch freigegeben werden. Diese Information lässt sich dann beispielsweise für weitere Deployments (automatisiert oder manuell) nutzen, etwa auf Produktiv- oder Kundensysteme.
Ihr Partner für individuelle Software-Projekte
Planen Sie bereits ein konkretes Software-Projekt? Oder gibt es bestimmte Prozesse in Ihrem Unternehmen, die Ihnen schon lange Kopfzerbrechen bereiten? Bremst ein System oder eine Schnittstelle Ihre Mitarbeiter auf der einen oder Ihre Kunden auf der anderen Seite aus? Dann sprechen Sie mit uns darüber! Wir freuen uns darauf, gemeinsam eine individuelle Lösung zu entwickeln – bei höchster Qualität und voller Kostenkontrolle. Wir legen größten Wert auf Erweiterbarkeit, Performanz, Skalierbarkeit, Plattformunabhängigkeit und Testbarkeit und schaffen individuelle High-End-Software-Lösungen, die sich auch im Nachhinein flexibel ausbauen und verändern lassen.
Weiterführende Infos
Code-Coverage-Metriken mit Bamboo und Clover
Code-Qualität optimieren mit SonarQube und Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Was agile Software-Projekte dem Kunden bringen
Der Beginn eines Happy Ends: Initialer Anforderungs-Workshop für erfolgreiche Projekte
Darum ist eine regelmäßige Kundenpräsenz beim Entwicklungsteam so sinnvoll
Mehr über die Creative-Commons-Lizenz erfahren