Das Ausliefern von Software-Projekten ist keine triviale Angelegenheit, insbesondere wenn es darum geht, Änderungen zu deployen, und es sind zahlreiche Kräfte am Werk, die einander entgegenwirken: Geschwindigkeit versus Stabilität, Qualität versus Quantität, Transparenz versus Effizienz.
Das Zusammenspiel von Jira Software, Bitbucket und Bamboo zeigt, wie Teams mithilfe der richtigen Tools rückverfolgbare Deployment-Pipelines aufbauen können, die die richtigen Informationen an den richtigen Stellen bieten. Wie das funktioniert, wollen wir uns etwas näher ansehen.
Build trifft deploy
Bei traditionellen Tools liegt der Fokus zumeist entweder auf "build" oder auf "deploy", und das eine oder das andere können sie auch gut. Mit den Deployment-Projekten in Bamboo können Teams Builds und Deployments zusammenbringen.
Vor diesem Hintergrund hat Atlassian Bamboo weitere Features hinzugefügt, die Entwicklern und Sys-Admins helfen, besser zusammenzuarbeiten. Erstens können Ops ihre Deployment-Arbeit automatisieren, indem sie dasselbe Werkzeug nutzen, das die Entwickler für ihren Build- und Testing-Prozess verwenden. Auch können sie sehen, wie die Artefakte getestet worden sind, wenn sie die Risiken eines Releases einschätzen. Auf der anderen Seite öffnet sich Testern, Entwicklern und Produktmanagern ein Fenster in die Ops-Welt inklusive der Möglichkeit zu sehen, wo eine Version gerade läuft.
Sehen wir uns die Dinge etwas genauer an. Das Erstellen von Deployment-Projekten in Bamboo ist genauso einfach wie das Anlegen von Build-Plänen. Im Erstellen-Menü gibt es dafür eine entsprechende Option, dann geben wir dem Deployment-Projekt einen Namen, wählen einen Build-Plan und einen Branch, von dem aus wir deployen wollen - das war’s. Damit haben wir eine Verbindung zwischen unseren Builds und unseren Deployments geschaffen.
Nun setzen wir unsere Umgebungen in Bamboo auf. (Davon können wir so viele haben, wie wir brauchen.) Für jede Umgebung definieren wir Aspekte wie Berechtigungen, Benachrichtigungen und dedizierte Agents. Und natürlich definieren wir die Deployment-Jobs, die wir mit jedem Schritt, der durch Tasks repräsentiert wird, ausführen möchten - ganz so, wie wir Tasks und Jobs in unseren CI-Builds nutzen. Auf der Deployment-Seite gibt es allerdings Tasks für Schritte wie das Pullen von Artefakten, das SSH-Verbinden mit Servern, das Transferieren und Entpacken von Dateien und das Ausführen von Smoke-Tests.
Jede Umgebung hat auch ihr eigenes Set an Deploy-Triggern: Soll das Deployment nach einem erfolgreichen Build gekickt werden? Ein Cron-Job? Ein Push-Button-Deploy? Eine Kombination daraus? Automatisierte Trigger führen das Deployment-Projekt aus, wenn es im Plan oder Branch, den wir bei der Erstellung des Deployment-Projekts gewählt haben, einen grünen Build gibt. Wenn wir vor dem Deployen einen bestimmten Zeitraum warten möchten, können geplante Trigger helfen (bspw. Cron-Jobs). Für manuelle Deployments navigieren wir zur Seite mit der Zusammenfassung der Build-Ergebnisse und klicken unter Aktionen einfach auf das kleine Wolken-Icon für unsere Zielumgebung.
Haben wir das Deployment-Projekt und seine Umgebung festgelegt, können wir uns den Dingen widmen, die dorthin deployt werden sollen. Wenn unsere Builds und Tests komplett sind, deployen wir die Artefakte in eine Umgebung in unserem Netzwerk, indem wir sie in ein Release konvertieren, wodurch wir seinen Fortschritt durch die Umgebungen tracken können. Bamboo-Releases agieren als Container für unsere Artefakte und eine Fülle damit zusammenhängender Informationen: Commits, Jira-Vorgänge, welche Builds die Artefakte produziert und getestet haben, in welche Umgebungen das Release deployt wurde und von wem.
Hinweis: Obwohl Versionen in Jira und Releases in Bamboo nicht auf irgend eine programmatische oder erzwingbare Weise zusammengebunden sind (Jira-Versionen repräsentieren öffentliche Releases, Bamboo-Releases sind dagegen unikale Identifikatoren für die deployten Builds), können wir leicht ein vollständiges Bild davon erhalten, was zwischen zwei Versionen passiert, wenn Bamboo mit Jira verknüpft ist. Ein Vorgang, der in Jira mit FixVersion 1.3 markiert ist, kann durchaus in eine Anwendungsversion namens 1.3-RC1, 1.30 oder (noch früher) 1.2.9 implementiert sein. Mit einem Klick auf Deployments im Entwicklungs-Panel in Jira können wir die FixVersion des Vorgangs mit dem vergleichen, was in Bamboo deployt wurde.
Ursache trifft Wirkung
Das Verknüpfen von Jira-Vorgängen mit Releases in Bamboo ist simpel. Wir können aus einem Vorgang in Jira Software heraus einen Branch erstellen. Wenn wir Bamboo, Jira und Bitbucket integriert haben, wird der Vorgang automatisch mit allen Commits dieses Branchs sowie mit den daraus resultierenden Builds und Deployments verknüpft.
Wenn wir andererseits nicht aus Jira heraus branchen, können wir den Vorgangsschlüssel in die Commit-Message einbinden. Bamboo registriert dieses Kürzel und fügt es der Liste mit Vorgängen hinzu, an denen wir seit der letzten Version gearbeitet haben. Außerdem detektiert Bamboo einen Vorgangsschlüssel in einem Kommentar auf der Build-Summary-Seite und erzeugt automatisch eine Verknüpfung zwischen Vorgang und Build oder Deployment-Projekt.
Um es zusammenzufassen: Wenn Bamboo, Jira Software und Bitbucket integriert sind, geht der Vorgangsschlüssel an Bitbucket, wenn wir aus Jira heraus branchen, alle Bitbucket-Repo-Details wandern zu Bamboo und Jira und alle Build- und Deployment-Status werden von Bamboo zurück an Jira und Bitbucket gesendet. Und keine dieser Verlinkungen müssen wir manuell vornehmen. Jedes Teammitglied kann in seinem bevorzugten Tool nachsehen und den Projektfortschritt nachvollziehen.
Devs trifft Ops
Zusätzlich zur Informationsbereitstellung über die Systeme hinweg erleichtert Bamboo die Kommunikation bezüglich der Release-Readiness. Releases an zentraler Stelle kommentieren zu können, unterstützt Teams bei der Abstimmung über Ergebnisse aus Tests oder über infrastrukturelle Änderungen, die für das Release vielleicht nötig sind.
Kommentare sind transparent und jederzeit rückverfolgbar, um sie später zu referenzieren. Außerdem kann jedes Release als Approved oder Broken geflaggt werden. Ersteres indiziert den Okay der Qualitätssicherung, Broken signalisiert dagegen den Ops, dass ein Release sich verzögern könnte, und den Entwicklern, dass sie hier noch einmal tätig werden müssen.
Geschwindigkeit trifft Kontrolle
Mit Berechtigungen für Umgebungen lassen sich Deployments in beliebige Umgebungen automatisieren, wobei wir stets die Kontrolle darüber haben, wer diese Deploys initiieren kann. Für jede Umgebung können wir Berechtigungen für Nutzer und Gruppen setzen, die festlegen, wer einen Deployment-Job konfigurieren, wer ihn ausführen und sogar wer die Deployment-Informationen sehen kann. Mit dem richtigen Set an Rechten sind beispielsweise Deploys durch die Entwickler und die QS in niedrigere Umgebungen per Selbstbedienung jederzeit möglich, während produktive und andere sensitive Umgebungen verschlossen bleiben.
Bamboo war das erste Tool seiner Art, das Deployments eine Premium-Behandlung hat angedeihen lassen. Atlassians Integrations-Server ist ein echtes Continuous-Delivery-Tool, das den gesamten Prozess vom Code bis zum Deployment abbildet.
Bamboo einführen und/oder lizenzieren? Wir sind Ihr Partner!
Interessieren Sie sich für Bamboo von Atlassian als Integrations-Server? Wir sind Atlassian Platinum Solution Partner und einer der größten Atlassian Experts weltweit: Gerne beraten wir Sie und unterstützen Sie bei der Lizenzierung sowie bei allen Aspekten der erfolgreichen Einführung und produktiven Nutzung. Bitte sprechen Sie uns unverbindlich an.
Ausführliche Infos über Bamboo, seine Features und sein Lizenzmodell in unserer Infothek
Bamboo: Wie viele Build Agents braucht mein Projekt?
Continuous Integration: Zehn Argumente für Bamboo
Tipps für Bamboo in DVCS-Teams
