Das Ausliefern von Software heißt heute, eine Produktivumgebung zu aktualisieren und/oder eine aktuelle Version für Kunden zum Download bereitzustellen. Beide Release-Methoden erfordern viel Koordination zwischen Entwicklern, Testern und operativen Teams, um die Änderungen intern durchzuleiten und dann tatsächlich an den Kunden zu bringen.
In diesem Beitrag geht es um Möglichkeiten, ein Release-Management ohne Silos mithilfe von JIRA Software, Bitbucket und Bamboo zu etablieren.
Änderungen verstehen
Egal, welche Rolle man im Hinblick auf die Auslieferung von Software einnimmt – man muss verstehen, welche Änderungen es von einer Version zur nächsten gibt. Und diese Informationen müssen granularer sein als die bloßen Versionsnummern. Hinter jeder an Kunden ausgelieferten Version stehen diverse interne Versionen, die meist als Release-Kanditaten (RC) oder Milestone-Builds bezeichnet werden.
Wenn ein Release kurz bevor steht, die Intensität der Entwicklung zunimmt und zum Feinschliff angesetzt wird, sind die feinen Unterschiede zwischen solchen Relase-Kandidaten entscheidend. Wir müssen wissen, was sich zwischen RC1 und RC2 geändert hat und dabei durch die Linse von Builds, Commits und Vorgängen schauen. Bamboo bietet die Möglichkeit zu sehen, welche JIRA-Vorgänge und Commits mit einem jeden RC-Build assoziiert sind.
Wenn man JIRA-Vorgangsschlüssel in Commit-Messages verwendet, registriert Bamboo das und assoziiert den sich ergebenden Build wiederum mit dem Vorgang. Wird aus einem Build in Bamboo ein Release erstellt, findet Bamboo all die Vorgänge, die mit allen Builds seit dem vorherigen Release assoziiert sind, und fasst diese Informationen auf einem einzelnen Bildschirm zusammen.
An diese Daten gelangt man über das Releases-Tab im entsprechenden Deployment-Projekt. Per Klick auf ein Release öffnet sich ein Screen mit allen Details.
Von diesem Vorgangsbildschirm aus lassen sich auch die Änderungen zwischen aktuellen Releases und beliebigen anderen Releases in diesem Projekt vergleichen. Beispielsweise können wir ein kommendes öffentliches Release dem letzten öffentlichen Release gegenüberstellen. Dann sehen wir alle JIRA-Vorgänge, die mit all den internen Release-Kandidaten assoziiert sind. Ebenso können wir auf das Commits-Tab wechseln und dieselben Vergleiche für Commits abfragen.
Tests nachvollziehen
Nach den quantitativen Aspekten sind natürlich die qualitativen Aspekte wichtig. Auch hier bieten Releases in Bamboo die benötigten Informationen.
Die Detailansicht eines jeden Releases bietet eine Liste mit allen CI-Builds und ihren Resultaten. Außerdem wird die Build-Nummer angezeigt, die die Artefakte produziert hat. Wenn Bitbucket mit Bamboo verknüpft ist, werden die Ergebnisse dieser Builds auch im Repository dargestellt: Man wählt das Repo, den spezifischen Commit und Branch und kann das Build-Resultat auf der rechten Bildschirmseite unter Builds einsehen.
Auf dieser Seite gibt es noch zahlreiche weitere interessante Daten, beispielsweise Deployment-Status-Informationen, Shortcut-Links, um das Release in die nächste Umgebung zu befördern, und Kommentare von Beteiligten. Entwickler, Tester, Sys-Admins und Produktmanager sollten diesen Bildschirm also stets im Blick haben.
Schließlich kommt jedes Team an einen Punkt, an dem es für einen jeden Release-Kandidaten entweder Go! oder No go! Heißt. Hier werden Zusammenarbeit und Effizienz besonders bedeutsam, und entsprechend sollte man wissen, wie die Atlassian-Tools helfen können.
Zunächst kann in Bamboo jede Version als approved oder broken geflaggt werden. Manchmal ist das schon alles, was wir zunächst wissen wollen.
Darüber hinaus können Teammitglieder auf der Build-Summary-Seite und via Deployment-Releases Builds kommentieren, wie sie das aus JIRA oder Confluence kennen. Hier können sich Systemadministratoren, die Qualitätssicherung, die Entwickler und alle anderen Beteiligten effektiv und zentral zu den Builds abstimmen.
Die oben beschriebenen Möglichkeiten erhöhen die Sichtbarkeit der Continuous-Delivery-Pipeline und des Release-Prozesses schon erheblich. Noch mehr Infos über das Bereit-Sein zum Release bietet ein Dashboard in JIRA Software in Form des Release-Hubs, zugänglich via Sidebar.
Der Release-Hub integriert die anderen Entwicklungs-Tools von Atlassian und zeigt nicht reviewten Code, offene Reviews, nicht gemergte Pull-Requests und fehlgeschlagene Builds. Hier hat das Team wirklich einen Überblick über den tatsächlichen Status eines Releases. Ist beispielsweise ein Vorgang als erledigt markiert, aber der Pull-Request ist bislang nicht akzeptiert worden und der Branch ist noch nicht gemergt, ist das hier zu sehen.
Natürlich hat jedes Team andere Prozesse und Standards. Wenn in einem Team nicht reviewter Code vielleicht kein Grund zur Sorge ist, kann man den Release-Hub so konfigurieren, dass er nicht reviewten Code eben ignoriert und hierfür keine Meldungen ausgibt.
Letztlich ist die Frage, wann man bereit zum Ausliefern ist, in den meisten Teams eine Sache des menschlichen Urteilsvermögens. Doch die Werkzeuge von Atlassian und die Integrationsmöglichkeiten zwischen diesen Systemen sparen viel Zeit und steigern die Sichtbarkeit hinsichtlich der Releases, sodass Go-/No-go-Entscheidungen mit aktuellen Daten unterfüttert sind und leichter fallen.
Weiterführende Infos
Sie möchten Atlassian-Tools neu einführen oder Lizenzen verlängern? Sie haben Fragen zu technischen oder organisatorischen Punkten? Als offizieller Atlassian-Vertriebspartner und einer der größten Atlassian Experts Partner weltweit mit Erfahrungen aus hunderten Atlassian-Projekten unterstützen wir Sie gerne bei allen Aspekten rund das gesamte Produktportfolio des australischen Software-Herstellers. Sprechen Sie uns einfach unverbindlich an.
Stimmen von führenden Atlassian-Mitarbeitern über //SEIBERT/MEDIA
Unsere Atlassian-Dienstleistungen im Überblick
//SEIBERT/MEDIA ist Atlassian Platinum Expert
Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen: Alle Vorteile
