Im ersten Artikel zum Continuous-Delivery-Workflow im Rahmen des Branch-per-Issue-Modells haben wir uns den Ablauf in seiner allgemeinen Form angesehen. Nun sollen Besonderheiten diskutiert werden, die bei der Entwicklung von SaaS- und von Installationsprodukten zu berücksichtigen sind.

Continuous Delivery für SaaS-Produkte

Im Hinblick darauf, wie wir mit Branches arbeiten und wie sich Code zwischen ihnen bewegt, ist der SaaS-Workflow identisch mit dem Basis-Workflow.

Schritt 1: Branch erstellen

Beim ersten Schritt soll zusätzlich lediglich erwähnt sein, dass SaaS-Teams ihre Feature-Branches in aller Regel vom master abzweigen.

Schritt 2: Coden, testen, wiederholen

Oft möchten SaaS-Teams dem Continuous Deployment so nahe kommen wie möglich und den Luxus haben, an einem Produkt zu arbeiten, das darauf zugeschnitten ist. In diesem Zusammenhang müssen wir als Teil des zweiten Schritts Deploys in eine Test- oder Staging-Umgebung automatisieren, statt bis nach dem Pull-Requests-Schritt zu warten.

Glücklicherweise sind schlanke Umgebungen dank Technologien wie Puppet, Chef, Docker und Vagrant immer einfacher auf- und wieder abzusetzen. Und Bamboo unterstützt automatische Deployments für jeden Branch. Ob wir mit temporären oder dauerhaften Umgebungen arbeiten – wir können sie so konfigurieren, dass jeder erfolgreiche Build unseres Branchs in eine Umgebung deployt wird, wo er automatisierte Oberflächen- und/oder Lasttests durchlaufen kann.

Nehmen wir an, dass wir bereits ein Deployment-Projekt in Bamboo erstellt haben, das mit diesem Build-Plan verbunden ist. Wir rufen die Konfiguration für die Umgebung auf, in die wir deployen wollen, und erstellen einen Trigger, der jeden erfolgreichen Branch-Build automatisch dorthin deployen wird.

Selbst wenn unser Team keinen Träumen von Continuous Deployment nachhängt und lieber Menschen entscheiden lässt, wann erfolgreiche Branch-Builds ausgeliefert werden, ist das Deployen in eine Test- oder Staging-Umgebung dennoch eine gute Idee, da wir uns so die Möglichkeit verschaffen, vor dem Mergen einiges an explorativem Testing durchzuführen.

Schritt 3: Mergen

Die Anzahl der Pre-Production-Umgebungen, die unser Team nutzt, wird den exakten Punkt bestimmen, an dem wir uns diesem Schritt zuwenden. Normalerweise führen Entwickler In-Process-Tests in ihrem Branch mit jedem Build durch, und wenn diese durchlaufen, deployen sie sie in eine Testumgebung für UI-, Last- und explorative Tests. Ist es alles okay, erstellen sie einen Pull-Request und mergen in den Branch, aus dem heraus releast wird (in der Regel master).

Schritt 4: Ausliefern

An diesem Punkt ist der Kreis geschlossen: Wir haben upstream in den master gemergt, und verifizierte Tests laufen durch. Hier gibt es viele Variationen hinsichtlich der Ansätze, die unterschiedliche Teams verfolgen.

Einige Teams triggern ein automatisches Deployment nach jedem erfolgreichen Build des master (hier sind Feature-Flags sehr wichtig). Einige Teams warten, bis eine kritische Masse an Änderungen im master ist, ehe sie ein Release taggen und ein Deployment anstoßen. Einige Teams deployen direkt in die Produktivumgebung, während andere nochmals eine Staging-Umgebung bevorzugen, in der eine letzte Runde Tests stattfindet. Es gibt also nicht den einen Weg des Codes vom master zum Kunden. Doch solange so viel wie möglich automatisiert ist, sind wir auf dem richtigen Weg.

Continuous Delivery für installierte Produkte

Der CD-Workflow für installierte Produkte hat vor allem die Besonderheit, dass es sehr langlebige Branches gibt, die die Software-Versionen enthalten, die aktuell unterstützt werden.

Schritt 1: Branch erstellen

Von wo aus wir branchen, hängt davon ab, welche Art von Änderung wir vornehmen wollen. Handelt es sich um einen Bugfix für das Release, das letzte Woche ausgeliefert wurde? Oder um eine neue Funktionalität für die nächste Version?

Im zweiten Fall branchen wir vom master. Im ersten Fall zweigen wir unseren Branch von der frühesten Version ab, für die die Änderung vorgesehen ist (normalerweise die erste Version, in der der Bug festgestellt wurde).

Schritt 2: Coden, testen, wiederholen

Wie bei SaaS-Produkten ist es auch bei der Entwicklung installierter Produkte eine gute Strategie, erfolgreiche Builds von unserem Branch in eine Testumgebung zu deployen, nachdem alle In-Process-Tests erfolgt sind. Die Gründe sind aber andere: Die Aktualisierung einer Version mit Bugfixes ist deutlich schmerzhafter, wenn es um installierte Produkte geht, und zwar für unser Team und für die Kunden. Daher ist das Deployment in eine Testumgebung für UI-, Last- und explorative Tests eher nicht optional, sondern sollte fester Bestandteil des Workflows sein, wenn wir uns die möglichen Folgen vor Augen halten.

Schritt 3: Mergen

Hier wird es interessant. Wenn wir an Dingen für das nächste Release arbeiten, setzen wir einen Pull-Request ab und mergen wie beim Basis-Workflow in den master. Wenn wir aber von einer stabilen Version gebrancht haben, mergen wir zuerst zurück in diesen Branch und stellen sicher, dass alle Tests erfolgreich sind. Dann rückportieren wir auf ältere Versionen, die dasselbe Update brauchen. Schließlich mergen wir in den master, sodass alle künftigen Versionen diese Änderung beinhalten.

Atlassian-Tools können uns in dieser Hinsicht sehr helfen. Bitbucket bietet die Möglichkeit, unsere Merges automatisch runter durch die Branches mit stabilen Versionen zu kaskadieren. Wir sollten sicherstellen, dass alle Branches so konfiguriert sind, dass Builds jedes Mal automatisch erfolgen, wenn neuer Code hinzukommt.

Alternativ können wir uns das automatische Merging von Bamboo zunutze machen, um die Änderungen zwischen den Branches mit stabilen Versionen zu bewegen. In diesem Fall sollten wir allerdings die Gatekeeper-Option anwenden.

Sagen wir beispielsweise, dass wir einen Bugfix in den Branch für v1.2 gemergt haben. Wir gehen in die Plan-Branch-Konfiguration für diesen Branch und konfigurieren ihn so, dass Merges automatisch hinab zum Branch für v1.1 erfolgen und so weiter.

Schritt 3,5: Einen Branch mit der stabilen Version erstellen

Wenn wir an neuen Features für die nächste Version arbeiten, zweigen wir einen neuen Branch für die stabile Version ab, wenn wir eine kritische Menge an Funktionen fertig haben. Das tun wir typischerweise vom master, und wie der master ist auch der Versions-Branch so konfiguriert, dass Builds und Tests automatisch erfolgen, wenn Änderungen hinein gepusht werden.

Wenn wir dann feststellen, dass weitere Arbeit nötig ist, ehe wir die Version ausliefern können, nutzen wir Feature-Branches, die wir von der stabilen Version abzweigen. Haben wir die erforderlichen Änderungen vorgenommen, mergen wir wieder zurück in den Versions-Branch und testen dort. Wenn alles gut geht, kaskadieren wir die Änderungen runter in den master, wie es das Diagramm oben zeigt.

Ob wir Pull-Requests für die cascading Merges nutzen, bleibt uns überlassen. Es ist immer gut, für mehr Sicherheit zu sorgen, aber Pull-Requests und die automatischen Merging-Features, die Bitbucket und Bamboo bieten, passen nicht zusammen. Also müssen wir die Vorteile der Automatisierung und die Vorteile zusätzlicher Code-Reviews gegeneinander abwägen.

Schritt 4: Ausliefern

Sind unsere In-Process-Tests im Branch mit der stabilen Version erfolgreich, ist es Zeit zum Deployen. Auch hier haben wir wieder die Wahl: Die meisten Teams deployen ihre Releases zunächst in eine Staging-Umgebung, andere haben genug Vertrauen in die bislang durchgeführten Tests und liefern das Release direkt aus.

Im demnächst folgenden dritten Artikel zum Thema beschäftigen wir uns dann mit Continuous Delivery auf die Gitflow-Art.

Wir sind Ihr Atlassian-Partner!

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

Weiterführende Infos

99 Argumente für Bitbucket Server (Stash) als Git-Repository-Manager
Branch-basierte Git-Workflows adaptieren
Echte Integration: Das Zusammenspiel von JIRA, Stash und Bamboo
So funktioniert die Lizenzierung von Atlassian-Produkten