Warum eignet sich Git für dein Unternehmen?
Der Wechsel von einem zentralisierten Versionskontrollsystem zu Git verändert die Arbeitsweise deines Softwareentwicklerteams. Wenn in deinem Unternehmen erfolgskritische Anwendungen auf diese Software angewiesen sind, wirkt sich eine Änderung des Entwicklungs-Workflows auf das gesamte Unternehmen aus.
Git für Entwickler
Feature Branch Workflow
Einer der größten Vorteile von Git ist die Branching-Funktion. Im Gegensatz zu zentralisierten Versionskontrollsystemen sind Git-Branches günstig und einfach zu mergen. Dies vereinfacht den bei so vielen Git-Benutzern beliebten Feature Branch Workflow.
Feature Branches bieten eine isolierte Umgebung für jede Änderung an deiner Codebasis. Wenn ein Entwickler mit der Arbeit an einer Aufgabe beginnt – egal, wie klein oder groß – erstellt er einen neuen Branch. Dies sorgt dafür, dass der Main-Branch immer nur Code in Produktionsqualität enthält.
Die Verwendung von Feature-Branches ist nicht nur zuverlässiger als die direkte Bearbeitung von Produktionscode, sondern bietet auch organisatorische Vorteile. Mit ihnen kannst du Entwicklungsaufgaben in genauso feine Teilaufgaben aufbrechen, wie in deinem Agile-Backlog. Du könntest zum Beispiel eine Richtlinie implementieren, nach der jedes Jira-Ticket in einem eigenen Feature-Branch behandelt wird.
Zugehöriges Material
Git-Merkzettel
Lösung anzeigen
Git kennenlernen mit Bitbucket Cloud
Verteilte Entwicklung
In SVN erhält jeder Entwickler eine Arbeitskopie, die auf ein einziges zentrales Repository zurückgeht. Git ist dagegen ein verteiltes Versionskontrollsystem. Statt einer Arbeitskopie erhält jeder Entwickler sein eigenes lokales Repository mitsamt einem vollständigen Commit-Verlauf.
Der vollständige lokale Verlauf macht Git schnell, da du keine Netzwerkverbindung benötigst, um einen Commit zu erstellen, ältere Dateiversionen anzusehen oder Diffs zwischen Commit auszuführen.
Verteilte Entwicklung erleichtert außerdem die Skalierung deines Entwicklungsteams. Wenn in SVN jemand den Produktions-Branch beschädigt, können die anderen Entwickler ihre Änderungen erst wieder einchecken, nachdem der Schaden behoben wurde. Bei Git gibt es keine solchen Blockaden. Alle Entwickler können in ihren eigenen lokalen Repositorys wie gewohnt weiterarbeiten.
Darüber hinaus entsteht durch verteilte Entwicklung ähnlich wie mit Feature Branches eine zuverlässigere Umgebung. Selbst wenn ein Entwickler sein eigenes Repository komplett zerstört, kann er einfach das Repository eines Kollegen klonen und neu anfangen.
Pull-Anfragen
Viele Quellcodemanagement-Tools, wie z. B. Bitbucket, erweitern die Kernfunktionalität von Git mit Pull-Anfragen. Eine Pull-Anfrage ist eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in sein Repository durchzuführen. Auf diese Weise können nicht nur die Projektleiter Änderungen leichter verfolgen, sondern die Entwickler können auch über ihre Arbeit diskutieren, bevor sie die Ergebnisse in die übrige Codebasis integrieren.
Da sie im Prinzip ein an einen Feature Branch angehängter Kommentar-Thread sind, sind Pull-Requests extrem vielseitig. Wenn ein Entwickler mit einem schwierigen Problem nicht weiterkommt, kann er einen Pull-Request eröffnen, um das übrige Team um Hilfe zu bitten. Oder noch unerfahrene Entwickler können Pull-Requests als einen formalen Code-Review nutzen, um sicherzustellen, dass sie nicht das gesamte Projekt zerstören.
Community
In weiten Kreisen ist Git zum vorausgesetzten Versionskontrollsystem für neue Projekte geworden. Wenn dein Team Git nutzt, ist die Wahrscheinlichkeit groß, dass neu eingestellte Mitarbeiter euren Workflow bereits kennen, da sie mit der verteilten Entwicklung vertraut sind.
Darüber hinaus ist Git bei Open-Source-Projekten sehr beliebt. Dies bedeutet, dass mühelos Bibliotheken von Drittparteien genutzt werden und andere zum Forken ihres eigenen Open-Source-Codes ermutigt werden können.
Schnellerer Release-Zyklus
Das Ziel von Feature Branches, verteilter Entwicklung, Pull-Requests und einer stabilen Community ist letztendlich ein schnellerer Release-Zyklus. Diese Funktionen kommen einem Agile Workflow entgegen, bei dem die Entwickler ermutigt werden, kleinere Änderungen häufiger zu teilen. Im Gegenzug durchlaufen Änderungen die Deployment Pipeline schneller als die bei zentralisierten Versionskontrollsystemen üblichen monolithischen Releases.
Wie du dir denken kannst, funktioniert Git sehr gut in Umgebungen, in denen Continuous Integration und Continuous Delivery praktiziert wird. Git-Hooks ermöglichen das Ausführen von Skripten, wenn bestimmte Ereignisse in einem Repository auftreten, sodass du das Deployment nach Belieben automatisieren kannst. Du kannst sogar Builds laufen lassen oder Code von bestimmten Branches an verschiedene Server ausrollen.
Es ist z. B. eine gute Idee, Git so zu konfigurieren, dass der neueste Commit vom Develop Branch an einen Testserver deployed wird, sobald jemand einen Pull-Request in ihn mergt. Die Kombination einer derartigen Build-Automatisierung mit gegenseitigem Review sorgt dafür, dass du höchstes Vertrauen in deinen Code setzen kannst, wenn dieser von der Entwicklung in die Staging-Umgebung und die Produktion überführt wird.
Git für das Marketing
Wie wirkt sich der Wechsel zu Git auf die Marketingaktivitäten deines Unternehmens aus? Nehmen wir an, in deinem Entwicklungsteam steht in den nächsten Wochen der Abschluss drei separater Änderungen an:
- Das gesamte Team befindet sich auf der Zielgeraden zur Fertigstellung eines bahnbrechenden Features, an dem es die letzten sechs Monate gearbeitet hat.
- Mary implementiert ein kleineres, nicht zugehöriges Feature, das nur Bestandskunden betrifft.
- Rick nimmt dringend benötigte Updates an der Benutzeroberfläche vor.
In einem herkömmlichen Entwicklungs-Workflow auf Basis eines zentralisierten Versionskontrollsystems würden diese Änderungen alle in einem einzigen Release zusammengefasst. Das Marketingteam macht nur eine Ankündigung, die den Fokus hauptsächlich auf das bahnbrechende Feature setzt. Dabei gehen die beiden anderen beiden Updates nahezu vollkommen unter und ihr Potenzial wird verschenkt.
Der von Git ermöglichte kürzere Entwicklungszyklus erleichtert die Aufteilung in separate Releases. Hierdurch hat das Marketingteam mehr Gesprächsstoff für häufigere Mitteilungen. Im obigen Szenario kann das Marketingteam drei Kampagnen erarbeiten, die jeweils ein Feature behandeln, und dabei zielgerichtet auf das betroffene Marktsegment eingehen.
Beispielsweise kann eine große PR-Aktion für das bahnbrechende Feature, ein offizieller Blogpost und kurzer Newsletter für Marys Feature und ein Gastbeitrag für externe Designblogs zur UX-Theorie, die Ricks Updates zugrunde liegt, vorbereitet werden. Alle diese Aktivitäten können synchron auf die separaten Releases ausgerichtet werden.
Git für das Produktmanagement
Die Vorteile von Git für das Produktmanagement sind im Prinzip dieselben wie für das Marketing. Häufigere Releases führen zu häufigerem Kundenfeedback und schnelleren Updates als Reaktion auf dieses Feedback. Anstatt auf den in acht Wochen angesetzten nächsten Release zu warten, kannst du dem Kunden eine Lösung bieten, so schnell deine Entwickler den Code schreiben können.
Mit dem Feature Branch Workflow bist du auch bei wechselnden Prioritäten flexibel. Wenn du beispielsweise in einem Release-Zyklus auf halber Strecke ein Feature aufschieben möchtest, um ein anderes zeitkritisches vorzuziehen, ist dies kein Problem. Das ursprüngliche Feature wartet auf seinem eigenen Branch bis die Entwickler wieder Zeit haben, daran weiter zu arbeiten.
Diese Funktionalität erleichtert auch das Management von Innovationsprojekten, Betatests und schnellen Prototypen als unabhängige Codebasen.
Git für Designer
Feature Branch sind hervorragend dazu geeignet, schnelle Prototypen zu erstellen. Egal, ob deine UX/UI-Designer einen völlig neuen Benutzer-Workflow implementieren oder nur ein paar Symbole ersetzen möchten, ein neuer Branch stellt eine Sandbox-Umgebung bereit, in der sie sich frei ausprobieren können. Auf diese Weise sehen die Designer ihre Änderungen in einer echten Arbeitskopie des Produkts, ohne dabei die Beeinträchtigung bestehender Funktionen zu riskieren.
Eine solche Einkapselung von Änderungen an der Benutzeroberfläche erleichtert die Präsentation von Updates anderen Stakeholdern gegenüber. Wenn z. B. der Entwicklungsleiter sehen möchte, woran das Designteam gearbeitet hat, muss er nur den entsprechenden Branch auschecken.
Pull-Requests gehen hier einen Schritt weiter und bieten einen formalen Ort für interessierte Parteien, über die neue Oberfläche zu diskutieren. Die Designer können die nötigen Änderungen vornehmen und die daraus resultierenden Commits werden im Pull-Request angezeigt. Auf diese Weise werden alle aufgefordert, sich am Iterationsprozess zu beteiligen.
Das vielleicht Beste am Erstellen von Prototypen auf separaten Branches ist, dass es ebenso einfach ist, die Änderungen in die Produktionsumgebung zu mergen wie sie zu verwerfen. Es gibt keinerlei Druck, eher zu einer der beiden Optionen zu tendieren. So werden Designer und UI-Entwickler zum Experimentieren angeregt und gleichzeitig sichergestellt, dass nur die besten Ideen den Weg bis zum Kunden finden.
Git für den Kundensupport
Der Kundensupport sieht bei Updates oft andere Schwerpunkte als Produktmanager. Wenn ein Kunde sich an den Support wendet, hat er in der Regel ein Problem. Sollte dieses Problem von der Software deines Unternehmens verursacht werden, muss sobald wie möglich eine Fehlerkorrektur ausgeliefert werden.
Der optimierte Entwicklungszyklus von Git sorgt dafür, dass Fehlerkorrekturen nicht erst bis zum nächsten monolithischen Release aufgeschoben werden. Ein Entwickler kann einen Patch für das Problem erstellen und diesen direkt in die Produktion pushen. Schnellere Korrekturen führen zu zufriedeneren Kunden und weniger Supporttickets immer wieder zum gleichen Problem. Dein Kundensupportteam muss Anfragen nicht mehr mit Antworten abspeisen wie "Tut uns leid, wir kümmern uns darum", sondern kann antworten: "Das haben wir schon behoben!".
Git für die Personalabteilung
In gewissem Maße bestimmt dein Softwareentwicklungs-Workflow, welche Mitarbeiter du einstellst. Es ist immer sinnvoll, Entwickler einzustellen, die mit deinen Technologien und Workflows vertraut sind, aber die Verwendung von Git bietet noch andere Vorteile.
Die Bewerber fühlen sich besonders von Unternehmen angezogen, die Karrieremöglichkeiten bieten, und Git-Kenntnisse sind für jeden Programmierer äußerst nützlich, egal ob in großen oder kleinen Abteilungen. Wenn du dich für Git als Versionskontrollsystem entscheidest, ziehst du zukunftsorientierte Entwickler an.
Git für alle, die ein Budget verwalten
Bei Git ist Effizienz zentral. Mit Git vergeuden die Entwickler ihre Zeit weder mit dem Weiterleiten von Commits über eine Netzwerkverbindung noch mit der Integration von Änderungen in ein zentralisiertes Versionskontrollsystem. Selbst noch unerfahrene Entwickler werden besser eingesetzt, da sie in einer sicheren Umgebung arbeiten können. All dies wirkt sich positiv auf die Bilanz deiner Entwicklungsabteilung aus.
Aber vergiss nicht, dass diese Effizienz auch über dein Entwicklerteam hinausgeht. Im Marketingteam wird keine Energie für unpopuläre Features verschwendet. Designer testen neue Oberflächen ohne viel Aufwand im tatsächlichen Produkt. Du reagierst umgehend auf Kundenbeschwerden.
Bei Agile geht es darum, so schnell wie möglich herauszufinden, was funktioniert, erfolgreiche Bemühungen zu intensivieren und weniger erfolgreiche Aktivitäten zu beenden. Git dient als Multiplikator all deiner Unternehmensaktivitäten, da es sicherstellt, dass alle Abteilungen mit maximaler Effizienz arbeiten.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
Bitbucket-Blog
DevOps-Lernpfad
