Im ersten Teil dieses einführenden Artikels wurde diskutiert, dass Git insbesondere durch seine Fähigkeiten im Hinblick auf das Branchen und das Mergen sehr gut zum Coninuous-Delivery-Konzept passt: Branches bieten Entwicklern isolierte Umgebungen, um an bestmöglichen Lösungen zu arbeiten, ohne Risiken einzugehen. Währenddessen bleibt der master stets sauber und auslieferbar. Branches helfen zudem, externe Entwickler sicher in Projekte einzubinden. Dieser zweite Teil knüpft nahtlos daran an.

Gut gemachtes Branching bedeutet gutes Projekt-Tracking

Inzwischen sind viele Teams dazu übergegangen, für jede zu implementierende User-Story, jeden Bugfix und jede JIRA-Aufgabe Entwicklungs-Branches zu erstellen.

Das macht es einfach auszuwählen, welche Änderungen in die Produktion ausgeliefert oder zu einem Release gebündelt werden sollen. Das Team kann bestimmen, was in den master kommt und wann. Es kann das MVP eines Epics plus ein Nice-to-have ausliefern, statt zu warten, bis alle Nice-to-haves voll ausgereift sind. Oder es kann einen einzelnen Bugfix ausliefern und dies innerhalb des Rahmens eines regulären Releases tun. Und es muss sich nicht gedulden, weil andere Änderungen noch nicht soweit sind, sondern kann die Änderung direkt nach draußen geben.

Dieses einfache Ausliefern einer einzelnen Code-Änderung ist die Essenz von Continuous Delivery. Der Ansatz hält nicht nur unfertigen Code vom master fern. Wenn die Entwickler den zugehörigen JIRA-Vorgangsschlüssel und vielleicht auch noch den Namen des Entwicklers in den Branch-Namen einbinden, ist auch jederzeit sofort klar, wie der Entwicklungsstatus eines jeden in Bearbeitung befindlichen Vorgangs ist.

Ein Hinweis zur Namensgebung im Screen oben: Hier wird das unikale Kürzel des JIRA-Vorgangs zusammen mit einer kurzen, für Menschen verständlichen Beschreibung, worum es in dem Ticket geht, genutzt. So kann ein Release-Manager oder Stakeholder sich das Repository ansehen und auf den ersten Block erkennen, dass eine User-Story mit dem zugehörigen Ticket AMKT-13952 auslieferungsbereit ist, da sie in den master gemergt wurde. Das ist maximale Sichtbarkeit ohne manuellen Aufwand.

Wie funktioniert der Workflow mit Git und CD?

Dieser Prozess soll an dieser Stelle aus einer höheren Perspektive betrachtet werden:

• Ein Entwickler erstellt einen Branch für den Vorgang, den er bearbeiten will. Er inkludiert den Vorgangsschlüssel in den Branch-Namen, sodass der Zweck des Branchs klar ist. Wenn er mit Atlassian-Tools wie Bitbucket oder Bamboo arbeitet, stellt er fest, dass mithilfe des Vorgangsschlüssels Verknüpfungen zwischen dem Ticket, dem Branch, allen Commits, den Builds, den Pull-Requests und den Deploys, die zum Vorgang gehören, erzeugt werden.
• Der Entwickler nimmt seine Änderungen vor. In seinem Branch arbeitet er isoliert. Er kann experimentieren und neue Technologien testen, um zur besten Lösung zu kommen, ohne sich Sorgen darüber machen zu müssen, im Zweifel das Projekt als Ganzes zu beeinträchtigen.
• Er nutzt Continuous Integration, beispielsweise mit Bamboo. Es liegt in seinen Händen und in denen seines Teams, ob er spezialisierte Tests wie Lasttests oder UI-basierte End-to-end-Tests durchlaufen lässt und ob automatisch Testläufe angestoßen werden, wenn Änderungen in den Branch gepusht werden. So kann es praktisch sein, dass Teams generell Unit- und Integrationstests in Entwicklungs-Branches durchführen, wobei es – im Hinblick auf die Schonung von Build-Ressourcen – den Entwicklern überlassen bleibt, wie oft dies geschieht.
• Der Entwickler aktualisiert seinen Branch häufig um die neuesten Änderungen des master-Branchs, indem er Rebasing oder branch-commit nutzt. So erkennt er Integrationskonflikte, bevor er mergt; der master bleibt sauber.
• Wenn er bereit zum Mergen ist, erstellt der Entwickler einen Pull-Request. Das bedeutet, dass die Implementierung komplett ist, dass er alle Änderungen der Teammitglieder integriert hat, dass alle daraus resultierenden Konflikte aufgelöst wurden und dass alle Tests durchgelaufen sind.
• Dann mergt der Entwickler und deployt gegebenenfalls. Einige Teams bevorzugen es, jede Änderung automatisiert auszuliefern, sobald sie in den master gelangt ist und dort alle Tests durchgelaufen sind – das Continuous-Deployment-Modell. Andere Teams entscheiden lieber selbst, was wann ausgeliefert wird.

Das ist es im Grunde. Branching-Workflows machen Continuous Delivery zu einem einfacheren Prozess und Git nimmt Teams die Kopfschmerzen im Hinblick aufs Branchen und Mergen. Zum Weiterlesen sei auf unsere kommenden Beiträge zum CD-freundlichen Aufsetzen von Git-Repositories mithilfe von Atlassian-Tools verwiesen.

Kennen Sie Codeyard?

Das ist unsere neue Atlassian-basierte Tool-Suite für Software-Entwicklungsteams, eine professionelle Lösung für das schnelle Aufsetzen einer passgenauen Infrastruktur als Grundlage für einen effektiven und effizienten Software-Entwicklungsprozesses – von der Idee bis zum auslieferbaren Produkt. Hier gibt es weitere Infos zu Codeyard.

Weiterführende Infos

Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Der Continuous-Delivery-Workflow für SaaS- und für installierte Software-Produkte
Der Continuous-Delivery-Workflow für Gitflow-Projekte