Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo

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.

Unit test stage configuration in Bamboo

Konfiguration der Unit-Test-Stage in Bamboo

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).

Artefakt für die Projekt-Quelltexte definieren

Artefakt für die Projekt-Quelltexte definieren

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.

Verwendung geteilter Artefakte in einer Stage

Verwendung geteilter Artefakte in einer Stage

Mittels eines Tasks für den Artefakt-Download können wir diese Daten integrieren:

Using shared artifacts in a stage's job

Geteilte Artefakte in einem Stage-Job

Anschließend fügen wir wieder einen Maven-Task hinzu, um die Anwendung via mvn clean package zu bauen:

Maven Task zum Bauen und Packen der Web-Anwendung

Maven-Task zum Bauen und Packen der Web-Anwendung

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:

Bamboo Artifakt zur Bereitstellung der war-Datei aus dem Build

Bamboo-Artefakt zur Bereitstellung der War-Datei aus dem Build

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.

Neues Deployment Projekt in Bamboo erstellen

Neues Deployment-Projekt in Bamboo erstellen

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:

Neue Deployment Umgebung "Preview" erstellt

Neue Deployment Umgebung „Preview“ erstellt

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:

War-Datei als Artifakt bereitgestellt

War-Datei als Artefakt bereitgestellt

Deinstallation der Anwendung auf dem Tomcat-Server: Wir entfernen die Anwendung vom spezifizierten Tomcat-Server mithilfe eines Tasks Undeploy Tomcat Application.

Task zum Deinstallieren der Anwendung von einem Tomcat-Server

Task zum Deinstallieren der Anwendung von einem Tomcat-Server

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.

Task zur Installation einer Webanwendung auf einem Tomcat-Server

Task zur Installation einer Web-Anwendung auf einem 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:

Übersicht über die Deployment-Umgebungen im Bamboo

Übersicht über die Deployment-Umgebungen in Bamboo

Im nächsten Schritt kann dann ein neues Release aus dem Ergebnis des Durchlaufs unseres Build-Plans erstellt werden:

Neues Release wird aus Build-Ergebnis erstellt

Neues Release wird aus Build-Ergebnis erstellt

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:

Deployment in Bamboo wurde erfolgreich abgeschlossen

Deployment in Bamboo wurde erfolgreich abgeschlossen

Die Release-Übersicht bietet Details zum Release:

Release Übersicht in Bamboo

Release-Übersicht in Bamboo

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.

Freigegebenes Release in Bamboo

Freigegebenes Release in Bamboo

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

Artikel teilen:Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page