Code, der nur von einer einzigen Person stammt, ist mit größter Vorsicht zu genießen. Heute weiß jeder, welche Vorteile es mit sich bringt, Software im Team zu entwickeln: In einem Team gibt es unterschiedliche Wege zu denken, unterschiedliche Hintergründe, unterschiedliche Erfahrungen, und wenn wir all diese Unterschiede zusammenbringen, um ein Problem zu lösen, laufen wir auf bessere Software hinaus. Sie ist besser zu warten, von höherer Qualität und macht die Nutzer zufriedener.

Aber die Software-Entwicklung im Team ist kein trivialer Prozess. Wir müssen verstehen, wer an welchem Stück Code arbeitet, wir müssen gewährleisten, dass es zwischen Änderungen keine Konflikte gibt, wir müssen Fehler finden, bevor die Kunden darauf stoßen, wir müssen sicherstellen, dass alle Projektbeteiligten auf dem Laufenden sind, was den Projektstand angeht. Und wie sich zeigt, kann jede dieser Herausforderungen entweder mit Git oder dem Continuous-Delivery-Prozess andressiert werden. Dieser zweiteilige Artikel gibt eine Einführung.

Das Potenzial Branch-basierter Workflows

Um es vorweg zu sagen: Es ist nicht so, dass Git per se perfekt zu Continuous Delivery passt. Vielmehr ist es so, dass Branching-Workflows bestens zu CD passen – und was Branching angeht, ist Git exzellent. Ein Branch-und-Merge-Workflow ermöglicht es, schwierige Bugs anzugehen, neue Technologien auszuprobieren oder einfach ein neues Feature von Grund auf zu entwickeln, ohne zu riskieren, dass die Änderungen anderen Leuten im Team und dem Projekt an sich Probleme bereiten.

Ja, auch mit Subversion und anderen traditionellen Versionskontrollen kann man branchen. Aber nutzen wir hier mal die Gelegenheit, einen Blick auf den bösen Zwilling des Branches zu werfen: das Mergen.

Traditionelle Versionskontrollen wie Subversion haben einfach ein Problem damit, Versionen von Dateien zu tracken, die sich in unterschiedlichen Branches befinden, und wenn es ans Mergen geht, muss Subversion das Stoppschild aufstellen und erstmal nach der Richtung fragen nach. Die Tatsache, dass beim Mergen so viel menschliche Interaktion nötig ist, treibt Teams bei jedem Mergen in eine institutionelle Code-Starre, damit derjenige, der mergt, nicht durch neue Änderungen aus einem der anderen Branches unterbrochen wird. Und Code-Starre ist teuer, es ist unproduktive Zeit.

Git dagegen ist sehr gut darin, Änderungen an unterschiedlichen Versionen von Dateien in unterschiedlichen Branches nachzuverfolgen, und Git weiß jederzeit, wie der gemeinsame Vorfahr dieser Datei ausgesehen hat. Das ist sozusagen ein eingebautes GPS, das Git durch die Merges navigieren lässt, ohne dass man anhalten und die Richtung erklären muss.

Mit Git können Teams sich die Macht der Branches auf eine Art und Weise zunutze machen, auf die es mit Subversion unpraktisch wäre. Der Overhead, der mit dem Branchen und dem Mergen einhergeht, ist so trivial, dass Branches, die es nur für ein, zwei Tage gibt, nicht nur machbar sind, sondern vorteilhaft.

Und was macht das Branchen nun überhaupt so wertvoll für Contoinuous Delivery?

Mit Branches bleibt der Master sauber und auslieferbar

Die Etablierung solcher kurzlebigen Branches ist für Entwickler eine exzellente Möglichkeit, mit anderen in einem Projekt zusammenzuarbeiten, ohne dass man sich gegenseitig auf die Füße tritt. Aber noch wichtiger im Hinblick auf CD ist, dass alle in Ausführung befindlichen Arbeiten in Entwicklungs-Branches stattfinden und dass alle Branches mit stabilen Versionen in einem sauberen Zustand bleiben (und somit jederzeit ausgeliefert werden können).

Das bedeutet, die volle Batterie automatisierter Tests gegen Entwicklungs-Branches laufen zu lassen, damit Entwickler starke Signale hinsichtlich der Code-Qualität erhalten und selbstbewusste Entscheidungen dahingehend treffen können, ob ihr Code bereit zum Mergen ist oder nicht.

Das bedeutet auch, Gits Pull-Requests als Form des Code-Reviews zu nutzen, damit das gesamte Team Sicherheit im Hinblick auf die Code-Wartbarkeit und die Interoperabilität mit anderen Code-Bereichen hat. Es gibt im Vergleich zu traditionellen Delivery-Modellen also ein Mehr an Vorarbeit, aber das ist es wert.

Es ist egal, wie viele Tests fehlschlagen. Entwickler können in ihren Entwicklungs-Branches so viel kaputtmachen, wie sie wollen. Der master bleibt in einem Release-bereiten Status, während Entwickler an Details und Features arbeiten können, ohne unausgegorenen Code einzuführen. Das ist sowohl für CD als auch für die Entwicklerproduktivität ein Gewinn.

Branches helfen, Entwickler von außerhalb des Teams zu integrieren

Die Fähigkeit von Git zum Branchen und speziell zum Forken ganzer Repositories erleichtert auch die Beteiligung externer Leute: Auftragnehmer, Entwickler in Partnerunternehmen, Entwickler aus anderen Abteilungen und Standorten usw. Niemand muss sich darum sorgen, dass Leute, die nicht mit der Code-Basis vertraut sind, nach Belieben Änderungen an kritischen Branches vornehmen und die Bereitschaft zum Ausliefern beeinträchtigen.

Auch hier ist rigoroses automatisiertes Testen der Branches oder der geforkten Repos der Schlüssel zur erfolgreichen Zusammenarbeit. Und das Kernteam kann alle Build- und Testergebnisse reviewen, ehe es irgendwelche Merges in die master-Code-Linie freigibt.

Ein Repository-Manager wie Bitbucket ermöglicht dabei die Nutzung von Git-Hooks, um Qualitätsstandards durchzusetzen. Beispielsweise kann ein Team eine Regel festlegen, dass alle Branch-Builds durchlaufen müssen, ehe ein Pull-Request akzeptiert und gemergt werden kann.

Weiter geht es im zweiten Teil dieses Artikels.

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