Der Weg zu stressfreien Releases

Dieses Video zeigt dir, wie du den Stress vor dem nächsten wichtigen Release in Grenzen hältst.

Laura Daly Laura Daly
Themen durchsuchen

Der Erfolg eines Agile-Teams ist dann sicher erreicht, wenn es funktionierende Software für die Kunden veröffentlicht. Doch auch erfahrene Softwareteams stoßen bei der Validierung der abgeschlossenen Vorgänge im Vergleich mit den Artefakten auf Probleme. Code-Reviews wurden übersprungen, Code wurde nicht gemergt, Builds für gemergten Code schlagen fehl … Kommt dir das bekannt vor?

In dieser Präsentation erfährst du Folgendes:

  • Best Practices für das Programmieren, die dir das Ausliefern besserer Produkte ermöglichen: Erfahre, warum Code-Reviews für die Qualität unverzichtbar sind und wie du durch die Überwachung und Korrektur fehlschlagender Builds garantiert schnellere Releases erzielst.
  • Einrichtung und optimale Nutzung des Release Hub in Jira Software: Wir zeigen dir, wie du dir mehrere Stunden Arbeit ersparen kannst, indem du dir mit dem Release Hub einen klaren Überblick über den Fortschritt und den Status eines Release verschaffst.
  • Vollständige Automatisierung vom Build über den Code bis hin zum Release: Rationalisiere deinen Workflow, indem du deine Version direkt aus dem Release Hub heraus veröffentlichst.

Sehen und Lernen

Q&A-Runde

Unsere Hosts Jason Wong und Megan Cook haben ihre Lieblingsfragen und -antworten zu dieser Präsentation ausgewählt. Lies weiter, um zu erfahren, wie du erfolgreiche und stressfreie Releases erzielst.

F1: Welche drei wichtigsten nichttechnischen Vorteile bietet die Nutzung des Release Hub?

A1: (1) Mit Zuversicht ausliefern: Stakeholder im Team und außerhalb des Teams erfahren genau, was an welchem Punkt des Release-Zyklus bereit zum Release ist.

(2) Zeit sparen und die Entscheidungsfindung beschleunigen: Du erfährst automatisch und sofort, welche Features fertiggestellt und bereit zur Auslieferung sind und bei welchen es noch Probleme gibt. Der Release Hub überprüft alle Vorgänge in deiner Version, sodass du die Vorgänge und den Code nicht manuell abgleichen musst.

(3) Aufzeichnung der Releases: Du kannst an den veröffentlichten Versionen ablesen, was genau veröffentlicht wurde (Datum und Bezeichnung des Release). Ein Blick auf die noch nicht veröffentlichten Versionen zeigt dir, was aktuell für die kommenden Releases geplant ist.

F2: Wer übernimmt bei Atlassian in der Regel das Management der Release-Versionen?

A2: Jedes Team bei Atlassian hat seinen eigenen speziellen Ansatz, aber im Allgemeinen versuchen wir, den Prozess so weit wie möglich zu automatisieren. So kann jeder Entwickler im Team ohne großen Aufwand Bugfixes für die Produktion bereitstellen oder eine neue Bugfix-Version eines Produkts veröffentlichen.

Normalerweise haben Teams eine Liste mit zu erledigenden Aufgaben, aber wir versuchen, diese so knapp wie möglich zu halten. Tools wie der Release Hub tragen dazu bei, dass unsere geplanten Releases von höchster Qualität sind und es keine Diskrepanzen zwischen den Status der Jira Software-Vorgänge und ihrem tatsächlichen Entwicklungsstand gibt.

Einige der größeren Teams (z. B. Jira Software und Confluence) haben sogar einen Rotationsplan, der eigens für einen Bug Master/Release-Manager vorgesehen ist, der alle Releases verwaltet.

Bei größeren Haupt- und Nebenversions-Releases ist in der Regel eine bestimmte Person dafür zuständig, das Release im Blick zu behalten. Diese Person achtet darauf, dass der Umfang verwaltet wird und dass bei allen dem Release vorausgehenden Arbeiten die Risiken und der Zeitbedarf berücksichtigt werden. Diese Rolle kann ein Teamleiter oder Entwicklungsmanager übernehmen, aber wir versuchen, sie im Team rotieren zu lassen, damit alle mit dem Prozess vertraut sind und die Voraussetzungen für die Veröffentlichung hochwertiger Software kennen.

Im Hinblick auf die Zeitplanung stimmen sich die Teamleiter mit den Produktmanagern und dem Marketing ab. Dabei klären sie, wann ein Release voraussichtlich fertig sein wird und ob der Umfang oder der Zeitbedarf gezielt verwaltet werden muss. Diese Personen treffen auch die Entscheidung, welche Features in welchen Versionen veröffentlicht werden sollen.

F3: Wie stellt man einen Bezug zwischen einem Branch/Commit/Pull-Request/Build/Deployment und dem entsprechenden Vorgang her?

A3:

1. Branch: Nimm den Vorgangsschlüssel in den Branch-Namen auf.
2. Commit: Nimm den Vorgangsschlüssel in die Commit-Nachricht auf.
3. Pull-Request: Nimm den Vorgangsschlüssel in den Quell-Branch-Namen, die enthaltene Commit-Nachricht oder den Pull-Request-Titel auf.
4. Build: Nimm den Vorgangsschlüssel in die enthaltene Commit-Nachricht auf.
5. Deployment: Nimm den Vorgangsschlüssel in die enthaltene Commit-Nachricht auf.

F4: Welche Erfahrungen habt ihr im Umgang mit Konflikten gemacht, die sich bei der Bearbeitung desselben Codes auf isolierten Vorgangs-Branches ergeben?

A4: Unserer Erfahrung nach führt dies selten zu Problemen. Bei den meisten Vorgängen gibt es nur geringe Code-Überschneidungen. Gelegentlich treten allerdings tatsächlich Konflikte auf.

In der Regel begegnen wir folgenden zwei Problemen:

  • Langfristige Feature-Branches, die von der übrigen laufenden Entwicklung isoliert sind
  • Umfangreiche Refactoring-Tasks, die separat bleiben müssen, bis sie abgeschlossen, getestet und zum Release bereit sind

Im ersten Fall besteht die Möglichkeit, bei der Entwicklung häufige Integrationen durchzuführen, dabei aber die Features selbst mit Feature Flags zu versehen, sodass nur unsere internen Tester oder wenige ausgewählte Kunden die laufenden Änderungen zu Gesicht bekommen. So wird konfliktbehafteter Code kontinuierlich integriert, und die Wahrscheinlichkeit von Konflikten wird minimiert. Auch die Risiken und Auswirkungen des Hinzufügens eines großen Features zum Haupt-Entwicklungs-Branch werden so minimiert.

Wenn dies nicht umsetzbar ist und wenn es sich um große Refactorings handelt, achten wir darauf, den Entwicklungs-Branch so oft wie möglich in den Feature-Branch zu integrieren (indem wir die Änderungen am Basis-/Entwicklungs-Branch in den Feature-Branch mergen). So können wir sichergehen, dass alle laufenden Entwicklungsarbeiten abgeschlossen und möglichst oft mit dem langfristigen Feature-Branch getestet werden. Wenn Merge-Konflikte auftreten, ist es wesentlich leichter, die Personen, die die Änderungen vorgenommen haben, zum Beheben dieser Konflikte hinzuzuziehen oder zumindest den Umfang minimal zu halten, um eine einfachere Lösung zu ermöglichen.

Die beste Lösung besteht darin, Aufgaben immer in kleinere Einheiten zu unterteilen, die dann so oft wie möglich in den stabilen oder Enwicklungs-Branch gemergt werden. Dies minimiert die Wahrscheinlichkeit, dass in mehreren Feature-Branches gleichzeitig Änderungen an denselben Dateien vorgenommen werden.

F5: Welche Strategie empfehlt ihr für das Management paralleler Branches für die laufende Entwicklung (Features), Hotfixes und deren Deployment in unterschiedlichen Umgebungen (QS/Staging/Produktion)?

A5: Wir haben eine Reihe von Branch-Strategien auf unserer Git-Website dokumentiert. Besonders relevant ist hier der Abschnitt mit dem Workflow-Vergleich

Ausführlichere Informationen findest du in früheren Aufzeichnungen, Getting Git Right (Git richtig gemacht). Workflows für Continuous Deployment wurden im Webinar Git Workflow for SaaS teams (Git-Workflow für SaaS-Teams) näher behandelt.

Im Wesentlichen gibt es zwei vorherrschende Workflows: einen Produkt-Release-Workflow für herunterladbare Produkte und einen SaaS-Workflow für Online-Services (Git-Workflows für SaaS-Teams).

Für herunterladbare Produkte nutzen die meisten Teams eine Variante des Git-flow-Workflows, bei dem der Master für die laufende Entwicklung verwendet wird und jede vorherige Nebenversion einen eigenen Branch hat. Von dort aus werden Bugfix-Branches erstellt und zurückgemergt. Bei Bedarf wird ein Bugfix-Release erstellt. Alle Änderungen an vorherigen Release-Branches werden downstream in die nachfolgenden Releases und den Master gemergt, damit alle Folgeversionen die Bugfixes enthalten.

F6: Ist der Release Hub gut für Kanban und häufige Releases geeignet?

A6: Ja, das ist der Fall. Über die Release-Schaltfläche auf dem Kanban Board kannst du eine neue Version mit allen Vorgängen für das jeweilige Release erstellen. Dann kannst du den Release Hub zum Überprüfen auf Warnungen oder für einen Überblick über die Version nutzen.

Auch ohne Kanban Board kannst du jederzeit eine Version erstellen und Vorgänge hinzufügen – auch wenn diese Vorgänge schon abgeschlossen sind. Dann kannst du den Release Hub zum Überprüfen auf Warnungen nutzen, um sicherzugehen, dass das Release bereit ist.

F7: Kann ich im Release Hub Informationen über Vorgänge aus mehreren Jira Software-Projekten anzeigen oder ist der Release Hub projekt- und versionsspezifisch?

A7: Der Release Hub bietet eine detaillierte Ansicht einer Version. Da Versionen derzeit projektspezifisch sind, gilt dies auch für den Release Hub.

F8: Ist es möglich, Warnungen aus dem Release Hub automatisch in einen Hipchat-Raum zu übertragen?

A8: Bisher bestehen keine Integrationen zwischen Release Hub-Warnungen und Hipchat, und es sind auch keine Integrationen geplant. Wir haben aber bereits überlegt, wie der Release Hub die Zusammenarbeit im Team mit Hipchat verbessern könnte. Wir würden uns freuen, von unseren Kunden zu hören, wie sie diese Integration oder andere Integrationen mit unseren übrigen Produkten nutzen würden.

F9: Womit ist die Release-Schaltfläche verbunden? Mit einem Skript zum Bereitstellen auf dem Produktionsserver als Job in Bamboo?

A9: Mit der Release-Schaltfläche sind mehrere Funktionen verbunden:

  • Du kannst damit das Release-Datum festlegen und den Status einer Version in "Veröffentlicht" ändern. Wenn in der Version offene Vorgänge vorhanden sind, besteht auch die Option, diese Vorgänge in eine andere Version zu verschieben. All dies ist sowohl mit als auch ohne Bamboo-Integration verfügbar.
  • Wenn Bamboo in Jira Software integriert ist, kannst du über die Release-Schaltfläche einen neuen Build anstoßen, der in Bamboo konfiguriert werden kann, damit die für das Release deiner Version erforderlichen Schritte unternommen werden (z. B. ein Skript zum Bereitstellen in der Produktion oder zum Erstellen eines neuen Artefakts).
  • Du kannst die Release-Schaltfläche auch nutzen, um eine manuelle Phase eines ausgeführten Bamboo-Builds zu starten. So kann der Build an sich automatisch ausgeführt werden, aber mit einer optionalen, manuell ausgelösten Phase, in der das eigentliche Deployment/Release erfolgt. (Die Phase wäre dem gesamten Build aus Option 2 gleichzusetzen, aber es können die Artefakte verwendet werden, die bei der Ausführung des Builds erstellt werden.)

F10: Sind Integrationen zwischen dem Release Hub und GitHub/GitHub Enterprise geplant?

A10: Der Release Hub ist bereits mit GitHub und GitHub Enterprise kompatibel. Du musst lediglich deine Jira Software-Instanz über "DVCS Accounts" (DVCS-Konten; in Jira Software im Administratormenü mit den Add-ons zu finden) mit deinem GitHub-Konto verbinden. Danach kannst du den Fortschritt aller deiner Versionen mit den zugehörigen Entwicklungsinformationen aus dem Release Hub verfolgen. 

Weiter geht's
Qa at speed