Vorschau auf Bamboo 5: Mehr als nur Continuous Integration – auf dem Weg zu Continuous Delivery?

Warum ein neuer Projekttyp?

Build-Projekte bestehen aus Build-Plänen, welche aus automatisch oder manuell ausgeführten Stages bestehen. Stages beinhalten Jobs und diese können wiederum Tasks beinhalten, wie z.B. SCM-Checkout-, Build- oder Deployment-Tasks. Derzeit ist es üblich, für das Deployment eines Artefaktes pro Zielumgebung jeweils eine manuelle Stage innerhalb eines Plans festzulegen, welche Administratoren bei Bedarf ausführen können. Dies ist umständlich in der Handhabung, da hier die Verantwortlichkeiten und Schnittstellen zwischen Anwendungsentwicklung und –betrieb verschwimmen.

Laut Atlassian ist dies mit der Tatsache zu begründen, dass die derzeitig verfügbaren Werkzeuge für Continuous Integration keine ideale Grundlage für die Umsetzung von Continuous Delivery bieten.

Bei Continuous Integration ist für Entwickler lediglich der Status des aktuellen Builds von Relevanz, da dieser deren weiteres Vorgehen bestimmt.

Jedoch ist für Deployment-Verantwortliche unter Umständen Zugriff auf historische Build-Ergebnisse und Metadaten relevant, um ein bestimmtes Artefakt in eine Umgebung (erneut) zu veröffentlichen.

Es ist derzeit ebenfalls umständlich, Änderungen an Quelltext und zugehörigen JIRA-Issues sowie den aktuellen Deployment-Status eines Artefakts nachzuverfolgen. Fehlende Zugriffsberechtigungen und kein klar definierbarer Qualitätssicherungsprozess erschweren Deployments zusätzlich.

Um diesen Problemen entgegenzuwirken, wird Atlassian mit Bamboo 5 den neuen Deployment-Projekttyp und neue Bedienoberflächenelemente für eine übersichtlichere und einfachere Ausführung von Deployments einführen.

Abbildung 1: Bamboo 5 Workflow

Deployment-Projekte erlauben damit eine klarere Trennung von Entwicklung und Betrieb einer Anwendung. Administratoren können aus einer Liste erfolgreicher Builds wählen und vom Build-Plan unabhängige Deployment-Versionen definieren sowie Zielumgebungen (Environments) und deren Deployment-Tasks konfigurieren.

Abbildung 2: Kernkonzepte eines Deployment-Projekts

Ein Deployment-Projekt muss eine Referenz zu einem Build-Plan eines Build-Projektes besitzen und basiert auf drei Kernkonzepten:

• Artefakte, welche aus dem referenzierten Plan stammen, beispielsweise Maven-Snapshots.
• Deployment-Versionen, welche ein Bündel aus Artefakten mit einer unabhängig von den Artefakt-Versionen vergebenen Versionsnummer darstellen und für das Veröffentlichen in einer Zielumgebung vorgesehen sind.
• Verschiedene Zielumgebungen (Environments), in welche die entsprechenden Deployments ausgeführt bzw. rückgängig gemacht werden, z.B. Produktion oder Entwicklung

Ein Environment stellt eine Zielumgebung wie Produktion oder Entwicklung mit deren entsprechenden Einstellungen und Parametern dar. Ein Deployment-Projekt kann mehrere Zielumgebungen besitzen und bietet diesen Zugriff auf die Artefakte und Variablen aus dem referenzierten Build-Plan. Innerhalb einer Umgebung lassen sich jeweils die auszuführenden Tasks und der Auslöser für diese festlegen. Zur Auswahl stehen derzeit manuell, zeitbasiert und zusätzlich automatisch nach erfolgreichem Build, was eine Umsetzung von Continuous Deployment möglich macht.

Damit entfallen die vorher nötigen manuellen Stages innerhalb von Build-Plänen und Environments bieten zusätzliche, nützliche Funktionen wie Zugriffsberechtigungen.

Möchte man ein Resultat eines Builds in eine Zielumgebung veröffentlichen, muss man zuerst eine Deployment-Version erstellen. Eine Deployment-Version stellt ein Bündel aus Artefakten dar, welche aus einem Build des referenzierten Build-Plans stammen.

Der Erstellprozess beinhaltet das Festlegen einer Versions-Nummer und die Auswahl des gewünschten Build-Resultats. Die vorgenommenen Änderungen an Quelltext und verwandten JIRA-Issues seit der letzten erstellten Deployment-Version werden ebenfalls angezeigt.

Abbildung 3: Erstellen einer neuer Deployment-Version

Erstellte Versionen können anschließend in eine Umgebung veröffentlicht werden.

Wichtig ist hierbei anzumerken, dass Deployment-Versionen nichts mit Artefakt-Versionen, der Build-Nummer aus Bamboo oder gar JIRA-Versionen zu tun haben müssen, diese jedoch in Form von Variablen-Substitution beinhalten können. Eine Deployment-Version könnte man also mit Namen wie „Deployment-V1.0-from-Build#23-with-mvn-1.0-SNAPSHOT“ versehen. Die Begrifflichkeit der Deployment-„Version“ kann in diesem Kontext durchaus verwirrend sein. Atlassian erwägt deswegen derzeit eine alternative Namensgebung für diese Bündel aus Artefakten.

Neu erstellte Versionen können entweder automatisch oder händisch in eine Umgebung veröffentlicht werden. Nach einem erfolgten Deployment lassen sich diese mit Bamboo 5 komfortabel verwalten. Eine Version kann einen simplen Qualitätssicherungsprozess durchlaufen, indem sie als lauffähig oder nicht lauffähig markiert und ggf. zurückgesetzt wird. Detaillierte Informationen, z.B. wann eine Version wohin veröffentlicht wurde, können ebenso eingesehen werden.

Abbildung 4: Verwaltung erfolgter Deployments

Die Änderungen mit Bamboo 5 in Form von Deployment-Projekten ermöglichen eine visuelle und logische Trennung von Anwendungsentwicklung und deren Veröffentlichung. Entwickler und Administratoren müssen nicht mehr zwangsläufig innerhalb eines gemeinsamen Build-Plans operieren. So wird eine Umgebung für beide Disziplinen mit klar definierten Schnittstellen geschaffen und die Verantwortlichkeiten sind sauber voneinander getrennt.