Bei der Agile- und DevOps-Softwareentwicklung ist Git der De-facto-Standard für Versionskontrollsysteme und ein wichtiger Bestandteil der DevOps-Toolchain. Das Open-Source-Projekt mit umfassendem Support ist so flexibel, dass es eine Reihe von Workflows unterstützt und damit die Anforderungen aller Arten von Softwareteams erfüllt. Dank der verteilten (statt zentralisierten) Struktur sorgt Git für überragende Leistung und lässt Entwicklern die Freiheit, lokal zu experimentieren und Änderungen erst dann zu veröffentlichen, wenn sie zur Verteilung im Team bereit sind.
Neben den Vorteilen, die eine flexible und verteilte Lösung mit sich bringt, verfügt Git über wichtige Funktionen zur Unterstützung und Förderung der Agile- und DevOps-Entwicklung. Du kannst dir Git als eine Komponente der Agile- und DevOps-Entwicklung vorstellen: Änderungen durchlaufen die Deployment-Pipeline schneller als bei monolithischen Releases und zentralisierten Versionskontrollsystemen. Git passt sich an die (tatsächliche und angestrebte) Arbeitsweise deines Agile- und DevOps-Teams an.
Tipp 1: Stelle dir Tasks als Git-Branches vor.
Git kommt ins Spiel, wenn die Features ausgearbeitet und in eine Produkt-Roadmap eingetragen wurden und wenn das Entwicklerteam bereit ist. Zunächst aber noch ein kleiner Crashkurs in Agile-Feature-Entwicklung: Die Zuständigen für Produkt, Design, Qualitätssicherung (QS) und Entwicklung halten ein Feature-Kick-off-Meeting ab, um sich darüber einig zu werden, wie das Feature aussehen soll (Anforderungen), welchen Umfang das Projekt haben soll und in welche Tasks das Feature zur Fertigstellung unterteilt werden muss. Diese auch als "User Storys" bezeichneten Tasks werden dann einzelnen Entwicklern zugewiesen.
An diesem Punkt fügt sich Git in den Agile-Workflow ein. Wir bei Atlassian erstellen für jeden Vorgang einen neuen Branch. Dabei spielt es keine Rolle, ob es sich um ein neues Feature, einen Bugfix oder um eine kleine Verbesserung am bestehenden Code handelt – jede Codeänderung erhält ihren eigenen Branch.
Branching ist unkompliziert und ermöglicht Teams eine mühelose Zusammenarbeit in einer zentralen Codebasis. Wenn ein Entwickler einen Branch erstellt, verfügt er im Endeffekt über eine eigene isolierte Version der Codebasis, in der er Änderungen vornimmt. Für ein Agile-Team bedeutet dies, dass das Entwicklerteam durch das Aufteilen von Features in User Storys Aufgaben unabhängig voneinander bearbeiten kann und effizienter am selben Code (aber in verschiedenen Repositorys) arbeiten kann. Arbeit wird nicht doppelt erledigt, und die einzelnen Mitarbeiter können sich auf kleine Aufgabenteile in vom Haupt-Repository getrennten Repositorys konzentrieren, ohne dass zu viele Abhängigkeiten den Entwicklungsprozess ausbremsen.
Neben dem Aufgaben-Branching gibt es in Git noch weitere Branching-Typen, die sich nicht gegenseitig ausschließen. Du kannst zum Beispiel Branches für einen Release erstellen. Diese ermöglichen den Entwicklern die Stabilisierung und das Härten eines bestimmten Release, ohne anderen Entwicklern in die Quere zu kommen, die an zukünftigen Releases arbeiten.
Nachdem du einen Release-Branch erstellt hast, musst du regelmäßige Merges in deinen Haupt-Branch durchführen, um sicherzustellen, dass deine Arbeit am Feature auch in zukünftigen Releases enthalten ist. Um den Aufwand möglichst gering zu halten, solltest du den Release-Branch am besten nicht zu weit entfernt vom Release-Datum erstellen.
Tipp 2: Mehrere Branches können individuell getestet werden – das solltest du ausnutzen!
Sobald Branches bereit für den Code-Review sind, übernimmt Git eine weitere wichtige Rolle im agilen Entwicklungs-Workflow – das Testen. Erfolgreiche agile Teams führen Code-Reviews durch und richten automatisierte Tests ein (Continuous Integration oder Continuous Development). Zur Unterstützung bei Code-Reviews und Tests können die Entwickler über eine Pull-Anfrage problemlos den Rest des Teams benachrichtigen, dass die Branch-Aufgabe bereit für den Review ist. Einfacher ausgedrückt: Eine Pull-Anfrage ist eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in den Haupt-Branch durchzuführen, und ihm mitzuteilen, dass die Tests gestartet werden können.
Mit den richtigen Tools kann dein Continuous Integration-Server deine Pull-Anfragen erstellen und testen, bevor du einen Merge durchführst. So kannst du sicher sein, dass dein Merge keine Probleme verursachen wird. Diese Sicherheit erleichtert das Retargeting von Bugfixes und Konflikten, da Git die Unterschiede zwischen dem Branch und der Haupt-Codebasis seit der Trennung der Branches kennt.
Ein langfristiger Feature Branch, der nicht in den Haupt-Branch gemergt wird, kann die Agilität und die Iterationsfähigkeit beeinträchtigen. Bedenke bei langfristigen Feature Branches immer, dass du praktisch über zwei voneinander abweichende Versionen deiner Codebasis verfügst, was zu weiteren Bugfixes und Konflikten führt. Die beste Lösung sind kurzfristige Feature Branches. Dazu solltest du User Storys in kleinere Tasks aufteilen, Sprints sorgfältig planen und Code frühzeitig mergen, um ihn als Dark Features auszuliefern.
Tipp 3: Git sorgt in der agilen Entwicklung für Transparenz und Qualität
Bei Git und Agile dreht sich alles um Effizienz, Tests, Automatisierung und Agilität insgesamt. Sobald du einen Branch in den Haupt-Branch gemergt hast, ist dein Agile-Workflow abgeschlossen. Entsprechend bedeutet das Mergen von Code durch Pull-Anfragen, dass du nach Fertigstellung des Codes dokumentieren kannst, dass deine Arbeit geprüft wurde, dass andere Teammitglieder den Code bestätigt haben und dass er bereit zum Release ist. So bleiben Agile-Teams schnell und haben das nötige Vertrauen für häufige Releases – ein Merkmal erfolgreicher Agile-Teams.
Ein regelmäßiger Release-Rhythmus ist in der agilen Entwicklung entscheidend. Damit Git in deinem agilen Workflow funktioniert, musst du dafür sorgen, dass dein Haupt-Branch immer grün ist. Das bedeutet, dass bei Features, die noch nicht fertig sind, auf den nächsten Release gewartet werden muss. Bei kürzeren Release-Zyklen ist dies auch kein Problem.
