Continuous Delivery-Workflows mit dem Branch-pro-Vorgang-Modell

Produktives Branching in Kombination mit Continuous Delivery? Auch bei SaaS kein Problem.

Sarah Goff-Dupont Sarah Goff-Dupont

Wie in "Superstarke Continuous Delivery mit Git" ausführlich erläutert, ist es eine gute Idee, in deinem Continuous-Delivery-Workflow umfassendes Branching zu nutzen. Es hilft dir dabei, deine wichtigsten Branches in einem sauberen und Release-bereitem Zustand zu halten, ermöglicht Entwickler, neue Dinge auszuprobieren, ohne dass sie ihren Teamkollegen auf die Füße treten, und vereinfacht, wenn du es richtig machst, die Projektverfolgung.

Wir nutzen nun seit mehreren Jahren einen Branch-pro-Vorgang-Workflow, genauso wie viele unserer Kunden. Und wir haben Unterstützung dafür in Jira Software sowie in die Entwicklungstools von Atlassian eingebaut – so ist es nicht nur eine Best Practice, sondern auch eine Easy Practice. Lass uns also tief eintauchen in das Branch-pro-Vorgang-Modell, und wie es zu den drei häufigsten Continuous-Delivery-Workflows passt: SaaS-Produkte, installierte oder mobile Produkte und Gitflow (das für beide Produkttypen funktionieren kann).

Der grundlegende Branch-pro-Vorgang-Workflow

Der Name sagt so ziemlich alles: Erstelle für jeden Vorgang, an dem du arbeitest (oder jede Codeänderung, die du vornimmst, was eigentlich sowieso in Jira Software verfolgt werden sollte), einen Entwicklungs-Branch. Führe dann alle Implementierungs- und Testarbeiten an diesem Branch durch. Wenn du damit fertig bist, übermittle einen Pull-Request, führe den Merge durch und release, wann immer du bereit bist.

Screenshot des grundlegenden Workflows | Atlassian CI/CD

Hier eine Schritt-für-Schritt-Anleitung für die Verwendung von Atlassian-Tools:

Schritt 0: Richte deine Tool-Integrationen ein

Arbeite mit deinem Atlassian-Administrator zusammen, um Jira Software, Bitbucket und Bamboo zu integrieren. Beachte, dass du Cloud- und Server-Optionen miteinander kombinieren kannst. Bei Atlassian verwenden einige Teams beispielsweise Jira Software Server, Bamboo Server und Bitbucket Cloud. Für diejenigen, die mit Git lieber über eine GUI arbeiten anstatt über die Befehlszeile, empfehle ich zudem unbedingt Sourcetree. Es ist kostenlos, deshalb sehe ich keinen Grund, es nicht zumindest auszuprobieren. Verbinde Sourcetree mit deinen Repositorys, sobald du es installiert hast.

Du solltest auch die anderen naheliegenden Dinge erledigen, wie Vorgänge erstellen, um deine Arbeit nachzuverfolgen, ein oder zwei Repositorys einrichten, sowie deine Builds und Deployment-Aufträge konfigurieren.

Schritt 1: Erstelle deinen Branch

Öffne den Vorgang in Jira Software, weise ihn dir selbst zu und setze ihn auf In Arbeit, damit dein Team weiß, was los ist. Auf der rechten Seite befindet sich das Entwicklungs-Panel. Klicke darin auf den Link Branch erstellen. Wenn du mehr als einen Repository-Manager verbunden hast, wirst du aufgefordert, auszuwählen, welcher von ihnen deinen Branch verwalten soll. Ansonsten gelangst du direkt zum nächsten Bildschirm, wo du deinen Branch konfigurierst.

Screenshot: Erstellen von Branch-Workflows | Atlassian CI/CD

Schau dir an, wie Bitbucket den Vorgangsschlüssel (in diesem Fall MKT-15886) aufgenommen und als Teil des Branch-Namens verwendet hat. Dies lässt alle möglichen magischen Dinge geschehen, zum Beispiel das Senden von Commit-, Build- und Pull-Request- und Deployment-Informationen zurück an das Entwicklungs-Panel. Vorgangsschlüssel lösen alle möglichen raffinierten Verknüpfungen und Automatisierungen während deines gesamten Continuous-Delivery-Workflows aus. Stelle deshalb sicher, dass du diese in deine Branch-Namen einfügst, egal, ob du über ein UI oder cmd arbeitest.

Beachte auch die Drop-down-Menüs, aus denen du ein passendes Präfix für den Branch (je nach Art, beispielsweise Fehlerbehebung, Feature oder Release) sowie den übergeordneten Branch oder ein übergeordnetes Tag, anhand dessen der neue Branch erstellt werden soll, auswählen kannst. Sofern der ausgewählte Branch von Bamboo erstellt und getestet wird, zeigt ein Indikator, ob der Branch derzeit sauber ist. Behalte diese Anzeige unbedingt im Blick! Das Letzte, was du brauchst, ist ein brandneuer Branch, der bereits irgendeinen Fehler enthält.

Sobald alle Einstellungen deinen Wünschen entsprechen, klicke auf Branch erstellen und Bitbucket erledigt den Rest.

Schritt 2: Programmiere, teste, wiederhole

Dieser Teil ist dir sicherlich bekannt: Klone das Repository lokal, falls du das nicht schon gemacht hast, schau dir deinen neuen Branch an und starte mit dem Programmieren. Sobald du deinen ersten Push zum neuen Branch vorgenommen hast, hat Bamboo diesen bereits in deinem Repository erkannt und Continuous Integration (CI) mithilfe der Funktion "Branches planen" dafür konfiguriert (vorausgesetzt, du hast das automatische Branch-Management aktiviert). Im Wesentlichen spürt Bamboo neue Branches in deinem Repository auf und wendet alle Builds auf sie an, die du für den Main konfiguriert hast.

Außerdem empfehle ich dir die Aktivierung von automatischem Mergen über Bamboo. Am Anfang jedes Builds kann Bamboo zwei beliebige Branches ausprobieren, sie mergen und dann den Build mit dem zusammengeführten Code ausführen. Für diese Phase des Continuous-Delivery-Workflows mergst du also Änderungen aus dem Main in deinen Feature-Branch. Auf diese Weise löst sich dein Branch nicht weit vom Main und du erhältst frühzeitig Feedback, ob sich deine Änderungen mit den Änderungen am Main gut vertragen.

Screenshot des Branch-Updaters | Atlassian CI/CD

Wenn automatisches Mergen nicht so dein Ding ist, dann merge (oder rebase) den Main unbedingt in deinen Branch und initiiere einen Build, nur um sicherzugehen, dass es keine bösen Überraschungen gibt – oder beseitige sie, wenn sie auftauchen. Sobald du die Implementierung abgeschlossen hast und alle deine Tests bestanden sind, bist du bereit für den nächsten Schritt.

Schritt 3: Mergen

Da wir unsere Teamkollegen schätzen, mergen wir Änderungen nie voreilig in den Main (oder einen anderen wichtigen Branch), ohne zuvor eine Pull-Anfrage durchgeführt zu haben – die einzige nicht nervige Art von Codeüberprüfung weit und breit.

Du kannst Pull-Requests über die Befehlszeile oder mit Sourcetree erstellen, aber die Benutzeroberfläche von Bitbucket bietet dir einige Vorteile. Zunächst hast du die Möglichkeit, deinen Branch mit dem Ziel-Branch zu vergleichen. Ein Blick auf den Vergleich offenbart oft ein oder zwei Dinge, die du direkt ausbessern solltest. Auf der Seite des Branch-Vergleichs klickst du dann auf die Schaltfläche Pull-Request erstellen, wählst deinen Reviewer aus und los geht's.

Screenshot des Pull-Request in Bitbucket-Workflows | Atlassian CI/CD

Bitbucket ist (ganz ehrlich) nahezu unschlagbar, was Pull-Anfragen anbelangt. Abgesehen von den üblichen Funktionen wie Side-by-Side-Diffs und Inline-Kommentaren kannst du auch Regeln festlegen. Manche Entwicklerteams bei Atlassian legen beispielsweise fest, dass Pull-Anfragen erst gemergt werden können, wenn sie von mindestens zwei Personen genehmigt wurden. Andere Teams einigen sich auf einen Hauptverantwortlichen und legen die Zugriffsrechte für den Ziel-Branch so fest, dass nur der Hauptverantwortliche Merges durchführen kann. Außerdem sollten alle Teams die Regel aktivieren, die das Mergen einer Pull-Anfrage verhindert, wenn der jeweilige Branch fehlerhafte Builds aufweist.

Profitipp: Für den Main und jeden Branch, von dem du einen Release durchführst, solltest du definitiv nach jedem Push sofort einen Build erstellen. Konfiguriere für sie in Bamboo einen automatischen Build-Trigger mit einem aggressiven Abfragezeitplan oder einer Push-Benachrichtigung von Bitbucket.

Schritt 4: Zeit für die Auslieferung

(Gibt es da draußen noch mehr Fans der Band Devo? "When some new code comes along, you must ship it." Nein? Na gut ... Ich schätze, ich bleibe bei meinem Hauptberuf.)

Screenshot: Bereitstellen von Builds in Bamboo-Workflows | Atlassian CI/CD

Sobald der Build in deinem Release-Branch grün ist, bist zu potenziell bereit für die Auslieferung. Ich sage "potenziell", denn ob du direkt auslieferst oder nicht, hängt von dir und deinem Team ab. (Sind alle Akzeptanzkriterien erfüllt? Wurden die Artefakte bei Belastungstests ausreichend strapaziert?)

Du kannst Bamboo sicherlich dafür verwenden, den Build in die Staging-Umgebung oder direkt zur Produktion freizugeben, wenn du auf komplettes Continuous Deployment aus bist. Aber das eignet sich nicht für jedes Team und für jedes Produkt – wie wir gleich besprechen werden.

In den nächsten Abschnitten werde ich die Schritte 1 bis 4 noch einmal durchgehen und aufzeigen, inwiefern sie sich (wenn überhaupt) von dem unterscheiden, was im grundlegenden Branch-per-Vorgang-Workflow beschrieben ist.

Continuous-Delivery-Workflow für SaaS-Produkte

Im Hinblick auf die Branches, mit denen du arbeitest, und wie sich der Code zwischen ihnen bewegt, ist der SaaS-Workflow identisch mit dem grundlegenden Workflow.

Screenshot des SaaS-Workflows | Atlassian CI/CD

Schritt 1: Erstelle deinen Branch

In diesem Zusammenhang ist nur anzumerken, dass SaaS-Teams ihre Feature-Branches in der Regel auf Basis des Main erstellen.

Schritt 2: Programmiere, teste, wiederhole

SaaS-Teams möchten oft so nah wie möglich an Continuous Deployment herankommen – und genießen den Luxus, an einem Produkt zu arbeiten, das dafür gut geeignet ist. Damit das umsetzbar ist, musst du im Rahmen dieses Schritts das Deployment in einer Test- oder Staging-Umgebung automatisieren, anstatt bis nach dem Pull-Request zu warten.

Glücklicherweise sind Lightweight-Umgebungen dank Technologien wie Puppet, Chef, Docker und Vagrant immer einfacher auf- und sofort wieder abzubauen. (Ich würde sehr gerne genauer darauf eingehen, aber das ist ein anderer Artikel für einen anderen Tag ...) Und Bamboo unterstützt automatisierte Deployments von jedem Branch. Egal, ob du mit temporären oder beständigen Umgebungen arbeitest, du kannst sie so konfigurieren, dass jeder erfolgreiche Build deines Branches in einer Umgebung bereitgestellt wird, in der er einen Spießrutenlauf von automatisierten UI- bzw. Belastungstests durchlaufen kann.

Angenommen, du hast bereits ein Deployment-Projekt in Bamboo erstellt, das mit diesem Build-Plan verknüpft ist. Rufe (oder erstelle) die Konfigurationen von Bamboo für die Umgebung auf, in der du bereitstellen möchtest, und erstelle einen Trigger, der automatisch jeden erfolgreichen Branch-Build dort bereitstellt.

Screenshot der Testumgebung | Atlassian CI/CD

Auch wenn dein Team nicht von Continuous Deployment träumt und lieber Menschen über den richtigen Zeitpunkt für die Auslieferung entscheiden lässt, ist es empfehlenswert, erfolgreiche Branch-Builds in einer Umgebung zu bereitszustellen. So können du und deine Teamkollegen zunächst explorative Tests durchführen, bevor ihr nach oben mergt.

Schritt 3: Mergen

Wann genau du zu diesem Schritt übergehst, wird durch die Anzahl der Vorproduktionsumgebungen beeinflusst, die dein Team verwendet. Normalerweise führen Entwickler mit jedem Build in den Prozess integrierte Tests für ihren Branch aus und, wenn diese bestanden werden, stellen sie in einer Testumgebung für UI-, Belastungs- und/oder exploratives Testen bereit. Sobald beim Testen alles bereit zur Auslieferung ist, erstellen die Entwickler den Pull-Request und mergen zu dem Branch, aus dem du auch releast (normalerweise der Main).

Schritt 4: Zeit zum Ausliefern

An diesem Punkt schließt sich der Kreis: Du hast den Merge am Main durchgeführt und sichergestellt, dass die Tests dort bestanden werden. An diesem Punkt sehen wir auch viele Unterschiede bei den Ansätzen verschiedener Teams.

Einige Teams lösen nach jedem erfolgreichen Build vom Main ein automatisches Deployment aus (in diesem Fall ist das Taggen von Features unerlässlich). Andere Teams wiederum warten, bis sich eine kritische Anzahl von Änderungen auf dem Main befindet, bevor ein Release getaggt und eine Bereitstellung ausgelöst wird. In ähnlicher Weise stellen einige Teams direkt in der Produktion bereit, andere schieben den Build für eine letzte Runde Sicherheits-Checks in eine Staging-Umgebung, bevor sie ihn live schalten.

Es gibt keine perfekte Lösung, um Code vom Main zu den Kunden zu bringen. Solange du so viel automatisierst, wie du kannst, bist du auf dem richtigen Weg.

Continuous-Delivery-Workflow für installierte Produkte

Der Hauptunterschied zum grundlegenden Branch-per-Vorgang-Workflow ist die Existenz langlebiger Branches, die jede Version beherbergen, die du gerade unterstützt. Bei B2B-Unternehmensprodukten wie denen von Atlassian hast du es vermutlich mit einem halben Dutzend dieser Branches zu tun (oder mehr). Bei mobilen Apps sind es möglicherweise nur zwei oder drei (oder weniger).

Screenshot des Workflows in mehreren Versionen | Atlassian CI/CD

Schritt 1: Erstelle deinen Branch

An welcher Stelle der Branch ansetzen soll, hängt von der Art der jeweiligen Änderung ab. Handelt es sich um eine Fehlerbehebung für das gerade letzte Woche ausgelieferte Release? Oder um neue Funktionen für das kommende Release?

In letzterem Fall erstellst du die Branches vom Main aus. Wenn es Ersteres ist, erstellst du deinen Branch aus dem Branch für die früheste Version, für die die Änderung bestimmt ist (d. h. die erste Version, in der der Fehler aufgetreten ist).

Schritt 2: Programmiere, teste, wiederhole

Wie bei SaaS-Produkten ist es sinnvoll, erfolgreiche Builds aus deinem Branch in einer Testumgebung bereitzustellen, sobald die in den Prozess integrierten Tests laufen. Die Gründe dafür sind jedoch etwas anders gelagert.

Mit installierten Produkten ist das Updaten einer Version mit Bugfixes ein weitaus größeres Problem als mit SaaS-Produkten – für dein Team und deine Kunden. Mit anderen Worten: Es steht mehr auf dem Spiel, wenn es um das Entdecken von Fehlern geht.

Deshalb solltest du in diesem Workflow die Bereitstellung in einer Testumgebung für UI-, Belastungs- und/oder exploratives Testen als "wirklich nicht optional" ansehen. In diesem Zusammenhang würde ich sagen, dass exploratives Testen auch nicht optional ist, wenn man bedenkt, was auf dem Spiel steht. Aber ich schweife ab ...

Schritt 3: Nach oben (und/oder unten) mergen

Hier wird es jetzt interessant.

Wenn du für einen bevorstehenden Release an etwas arbeitest, führe einen Pull-Request durch und merge deinen Branch im Main, genau wie beim grundlegenden Workflow. Aber wenn du deinen Branch auf einem stabilen Versions-Branch basierst, wirst du den Merge zuerst zurück in diesen Branch durchführen und sicherstellen, dass alle deine Tests dort bestehen. Dann portierst du zurück zu älteren Versionen, die das gleiche Update benötigen, und testest dabei jede einzelne. Abschließend wirst du den Merge mit dem Main durchführen, sodass alle zukünftigen Versionen dieselben Änderungen enthalten.

Screenshot des Workflows in mehreren Versionen | Atlassian CI/CD

Deine Atlassian-Tools können dich dabei auf verschiedene Art unterstützen. Zum einen ermöglicht Bitbucket eine automatische Übertragung deiner Merges nach unten durch die stabilen Versions-Branches. Achte darauf, dass jeder Branch so konfiguriert ist, dass er nach dem Erhalt von neuem Code immer automatisch neu erstellt wird.

Alternativ kannst du das automatische Mergen von Bamboo (oben beschrieben) nutzen, um die Änderungen zwischen den stabilen Versions-Branches zu verschieben. Verwende in diesem Fall aber die Gatekeeper-Option.

Gatekeeper-Screenshot | Atlassian CI/CD

Lass uns zum Beispiel annehmen, du hast einen Bugfix mit dem Branch für v1.2 zusammengeführt. Geh zu den Konfigurationen "Branch planen" für diesen Branch und richte ihn so ein, dass automatisch zum Branch für v1.1 der Merge durchgeführt wird, und so weiter.

Schritt 3.5: Erstelle einen stabilen Versions-Branch

Wenn du an neuen Inhalten für die nächste Version arbeitest, wirst du natürlich einen stabilen Versions-Branch erstellen, sobald du eine gewisse Anzahl an Funktionen zur Verfügung hast. (Zur Verfügung = implementiert, getestet, abgesegnet usw.) Dies wird in der Regel vom Main abgeschnitten und ist, wie der Main, so konfiguriert, dass jedes Mal automatisch ein Build erstellt und ein Test ausgeführt werden, wenn Änderungen zu ihm gepusht werden.

Falls (okay: wenn) du feststellst, dass vor der Auslieferung der Version weitere Änderungen erforderlich sind, schneidest du die Feature-Branches vom stabilen Versions-Branch ab. Sobald die Änderungen bereit sind, merge sie zum stabilen Versions-Branch und führe dort Tests durch. Falls das gut läuft, kaskadierst du deine Änderung zum Main, wie im Diagramm oben.

Es liegt ganz bei dir, ob dein Team Pull-Requests für die kaskadierenden Merges verwendet. Sie sind zwar eine gute Sicherheitsmaßnahme, aber Pull-Requests und die automatisierten Merge-Funktionen von Bitbucket und Bamboo passen nicht zusammen. Also solltest du die Vorteile der Automatisierung gegenüber den Vorteilen von zusätzlichen Code-Reviews abwägen.

Schritt 4: Zeit zum Ausliefern

Sobald deine in den Prozess integrierten Tests im stabilen Versions-Branch bestehen, ist es Zeit für das Deployment. Es liegt ganz bei dir und deinem Team, wo bereitgestellt wird – die meisten Teams bringen ihren Release zuerst in eine Staging-Umgebung, aber andere sind von den bis zu diesem Zeitpunkt durchgeführten Tests so überzeugt, dass sie direkt in die Produktion ausliefern.

Continuous Delivery nach Git-flow-Art

Anstelle eines einzelnen Main-Branch verwendet dieser Ansatz zwei Branches, um den Verlauf des Projekts nachzuverfolgen. Während der Main-Branch Tags und/oder Commits enthält, die den offiziellen Release-Verlauf des Projekts aufzeichnen, bietet ein gemeinsamer Integrations-Branch (normalerweise "Entwicklungs-Branch" genannt) deinem Team einen Ort, um Fehler und inkompatible Änderungen aufzuspüren.

Gitflow-Screenshot | Atlassian CI/CD

Schritt 1: Erstelle deinen Branch

Auch hier besteht der Unterschied zum grundlegenden Workflow ganz einfach darin, von wo aus du die Branches erstellst. Für neue Entwicklungsarbeiten wird dein Feature-Branch auf einem Entwicklungs-Branch basieren (stelle sicher, dass du ein sauberes Commit auswählst, von dem aus Branches erstellt werden sollen!). Bei Bugfixes für eine bereits ausgelieferte Version basiert er auf einem stabilen Versions-Branch – nicht oben abgebildet, aber du weißt, was gemeint ist. Weitere Informationen zu den Varianten von Gitflow und deren Branch-Strukturen findest du in unserem Tutorial. Bitbucket unterstützt alle Varianten sowie Branch-Berechtigungen, mit denen du den Zugriff auf Main- oder Versions-Branches steuern kannst.

Egal, von wo aus du Branches erstellst, nutze die Funktion von Bamboo zum Updaten von Branches (oben erwähnt), um mit jedem Build Änderungen aus dem übergeordneten Branch in deinen Feature-Branch zu ziehen. Du wirst Integrationsprobleme sofort erkennen und in deinem Feature-Branch beheben können, anstatt sie erst nach dem Merge zum Entwicklungs-Branch zu entdecken – zu diesem Zeitpunkt hast du ihn bereits verunreinigt.

Mit dem Gitflow-Modell ist es möglich, von Main- oder stabilen Versions-Branches zu releasen. Als Faustregel gilt, dass du deinen Release zum primären Branch für deine Bamboo-Builds machst – das kommt ins Spiel, wenn es Zeit für die Bereitstellung ist – und Plan-Branches aktivierst, sodass alle Branches genau getestet werden.

Schritt 2: Programmiere, teste, wiederhole

Der Schritt des Testens wird mit Gitflow interessant. Verwende Plan-Branches in Bamboo, um deinen Feature-Branch zu testen (wie bei allen Continuous-Delivery-Workflows), aber hier ist der Unterschied: Wenn die Implementierung abgeschlossen ist und alle deine Tests bestanden werden, führst du den Merge zum Entwicklungs-Branch durch, anstatt zum Main.

Bei der Entwicklung kommen die Änderungen aus dem gesamten Team zusammen. Du benötigst Feedback aus jedem Commit, um Testfehler leichter beheben zu können (weniger Änderungen zwischen den Builds, die beachtet werden müssen). Dies ist am einfachsten zu erreichen, wenn du die Entwicklung so konfigurierst, dass Builds anhand von Push-Benachrichtigungen aus Bitbucket ausgelöst werden. Wenn du das Repository regelmäßig abfragst, werden gelegentlich Änderungen aus mehreren Commits im selben Build erfasst, weil die Entwickler sehr häufig Änderungen erhalten. Diese Methode eignet sich besser für Branches, deren Änderungen zeitlich weiter auseinanderliegen.

Trigger-Typ Screenshot | Atlassian CI/CD

Profitipp: Ein weiterer Vorteil von Repository-ausgelösten Builds für die Entwicklung ist, dass die CPU von Bamboo effizient verwendet wird, wie ich in CI-freundliche Git-Repositorys erwähnt habe. Für Teams, die kontinuierlich in großem Umfang liefern, macht das wirklich einen Unterschied.

Stelle wie beim grundlegenden Workflow sicher, den Entwicklungs-Branch zu deinem Feature-Branch zu mergen (oder rebasen) und ein letztes Mal Tests durchzuführen, bevor du zum Entwicklungs-Branch übergehst.

Schritt 3: Mergen

Es ist üblich, einen Pull-Request zu erstellen, wenn du deinen Feature-Branch zum Entwicklungs-Branch mergst. Es ist viel einfacher, in diesem Stadium die Peer-Code-Überprüfungen durchzuführen, anstatt sie hinauszuzögern, bis du zur Auslieferung bereit bist. In diesem Fall müsstest du alle Änderungen seit dem letzten Release auf einmal überprüfen. Nein danke.

Zwangsläufig wirst du deinen Feature-Branch mit dem Entwicklungs-Branch mergen, nur um dort auf Testfehler zu stoßen. Überprüfe deinen Branch erneut und erledige die Arbeit dort, anstatt die Änderungen direkt im Entwicklungs-Branch vorzunehmen. (Die meisten Teams bei Atlassian haben per Handschlag vereinbart, niemals direkt auf dem Main Commits durchzuführen, sondern Commits nur zu mergen.)

Schritt 4: Zeit zum Ausliefern

Wenn du deinen Release-Branch als primären Branch für deinen Build-Plan in Bamboo festlegst, dann bist du für ziemlich unkomplizierte Deployment-Projekte gerüstet. Was auch immer dein primärer Branch für den Build-Plan ist, ist automatisch der primäre Branch für deine Deployment-Aufträge. Aber du kannst das Deployment-Projekt auch so einrichten, dass du Builds ebenfalls aus Feature-Branches bereitstellen kannst.

Ähnlich wie beim SaaS-Workflow kannst du automatisch Tags auf dem Main erstellen, basierend auf jedem erfolgreichen Build von Entwicklungs-Branches, und von diesen Tags aus sofort bereitstellen. Oder du kannst warten, bis mehrere Funktionen erfolgreich zu Entwicklungs-Branches hinzugefügt wurden, und das Tag von Hand erstellen. Es hängt ganz einfach davon ab, ob du dich auf das Continuous Deployment zubewegst, oder bei der Continuous Delivery bleibst. Gitflow bietet Platz für beide.

Vier Workflows, fünf Diagramme und etwa 3.200 Wörter später sind wir hier. (Wenn du das noch liest, herzlichen Glückwunsch!)

Du hast hoffentlich ein grundlegendes Verständnis dafür bekommen, wie Jira Software, Bitbucket und Bamboo zusammenarbeiten, um das Modell "Branch-pro-Vorgang" bei der Continuous Delivery zu unterstützen. Wenn nicht, kontaktiere mich auf Twitter und lass mich wissen, wie ich diesen Artikel verbessern kann – er ist wichtig.

Wir haben zumindest gesehen, wie bedeutsam es ist, dass du für jeden Vorgang, an dem du arbeitest, einen Branch erstellst. Du wirst deinen Teamkollegen nicht in die Quere kommen und deine wichtigsten Branches bleiben jederzeit sauber und Release-bereit. Also:

Häufiges Branching ist immer sinnvoll.

Viel Spaß beim Branching!