Erkunde das Git-Verzweigungsmodell für kontinuierliche Lieferung

Die erfolgreiche Softwarebereitstellung hängt von einer Verzweigungsstrategie ab, die Geschwindigkeit, Qualität und Risikomanagement ausgleicht. Ziel ist es, Verbesserungen schnell zu versenden und gleichzeitig die Produktionsstabilität aufrechtzuerhalten.

Strategische Balance: Geschwindigkeit und Qualität

Ein effektives Verzweigungsmodell muss das richtige Gleichgewicht haben:

• Minimieren Sie den Prozessaufwand , um den Zeit-zu-Markt zu beschleunigen.
• Stellen Sie sicher, dass Qualitätssicherungspunkte bestehen bleiben, um zu verhindern, dass Fehler in die Produktion gelangen.
• Aktivieren Sie parallele Entwicklung für die Skalierbarkeit des Teams.
• Unterstützen Sie eine schnelle Hotfixbereitstellung für kritische Probleme.

Während zahlreiche Git Branching-Strategien vorhanden sind, kombiniert der effektivste Ansatz bewährte Muster mit den spezifischen Anforderungen Ihres Teams. Moderne Unternehmensteams übernehmen in der Regel ein einfaches, trunkbasiertes Entwicklungsmodell , das sich auf Featurezweigen und Pullanforderungen zentriert.

Kernprinzip: Immer-Bereit Hauptzweig

In dieser Lektion erfahren Sie, wie Sie ein fortlaufendes Bereitstellungsfertiges Verzweigungsmodell mithilfe von Featureverzweigungen und Pullanforderungen implementieren, um eine konsistente bereitstellungsfähige Hauptverzweigung aufrechtzuerhalten.

Rahmen für unternehmensweite Verzweigungsstrategien

Die folgenden Prinzipien legen eine stabile Grundlage für die kontinuierliche Lieferung fest:

Hauptzweigstabilität

• Single Source of Truth: Der Mainbranch ist der exklusive Weg für Produktionsversionen.
• Produktionsbereitschaft: Der Hauptzweig muss sich immer in einem bereitstellungsfähigen Zustand befinden.
• Branch-Schutz: Implementieren Sie umfassende Branchrichtlinien, um direkte Commits zu verhindern.
• Gated-Änderungen: Alle Änderungen fließen ausschließlich durch Pullanforderungen.
• Versionsnachverfolgung: Markieren Sie alle Produktionsversionen mit semantischen Git-Tags.

Featurebranchdisziplin

• Isolierte Entwicklung: Erstellen Sie dedizierte Verzweigungen für alle Features und Fehlerbehebungen.
• Integration von Featurekennzeichnungen: Verwalten Sie lange ausgeführte Features mit Feature-Umschaltern, um die Branchlebenszeit zu reduzieren.
• Strategische Benennung: Verwenden Sie beschreibende Benennungskonventionen, die den Geschäftlichen Wert widerspiegeln.
• Pull Request-Workflow: Zusammenführen im Mainbranch ausschließlich über überprüfte Pull Requests.

Release Branch-Strategie

• Dedizierte Vorbereitung: Erstellen Sie Release-Verzweigungen aus stabilen Featureintegrationspunkten.
• Qualitätssicherung: Führen Sie gründliche Tests und Stabilisierung auf Release-Branches durch.
• Produktionshärtung: Wenden Sie abschließende Fehlerbehebungen und Leistungsoptimierungen an.
• Meilensteinverfolgung: Markieren Sie wichtige Veröffentlichungsmeilensteine zur Rückverfolgbarkeit.

Benennungskonventionen für Skalierung

# Bug fixes
bugfix/[ticket-id]-description
bugfix/AUTH-123-login-timeout

# Feature development
features/[area]/[feature-name]
features/authentication/oauth-integration
features/api/rate-limiting

# Hotfixes
hotfix/[severity]-description
hotfix/critical-payment-gateway

# Personal branches
users/[username]/[description]
users/john-doe/experimental-caching

Pull Request-Verwaltung

• Obligatorische Codeüberprüfung: Keine Ausnahmen für direkte Zusammenführungen zum Hauptteil.
• Automatisierte Validierung: Integration von CI/CD-Pipelines für Qualitätssicherungsgrenzen.
• Leistungsmetriken: Nachverfolgen und Optimieren der Abschlusszeit der Pullanforderung.
• Wissensaustausch: Verwenden Sie Rezensionen für teambasiertes Lernen und die Durchsetzung von Standards.

Voraussetzungen und Einrichtung

Grundlegende Tools für Git-Workflows für Unternehmen

Diese praktische Übung nutzt die umfassende DevOps-Toolkette von Azure:

• Azure CLI: Cloudnative Befehlszeilenschnittstelle für Azure-Dienste.
• Azure DevOps CLI: Spezialisierte Erweiterung für nahtlose Git-, CI/CD- und Agile-Toolintegration in Windows, Linux und macOS.

Azure DevOps CLI-Konfiguration

Die Azure DevOps CLI bietet flexible Ausgabeformatierung (JSON, YAML, Tabelle, TSV), um verschiedene Automatisierungsszenarien zu unterstützen. Konfigurieren Sie Ihr bevorzugtes Format mithilfe von:

az devops configure --defaults output=table

Hands-On Implementierung: Enterprise Git Workflow

Diese umfassende Anleitung veranschaulicht das Branching mit Git auf professionellem Niveau für die kontinuierliche Bereitstellung, wobei die Entwicklung von Funktionen, die Hotfix-Deployments und die Konfliktlösung abgedeckt werden.

Schritt 1: Erstellung und Entwicklung von Feature branch

Erstellen Sie einen Feature-Branch gemäß unternehmensspezifischen Namenskonventionen.

myWebApp

git checkout -b feature/myFeature-1

Ausgabe:Switched to a new branch 'feature/myFeature-1'.

Überprüfen des Branchkontexts und des Arbeitsstrukturstatus:

myWebApp

git branch

Ausgabe:✓ feature/myFeature-1

• main*

Schritt 2: Featureimplementierung und Versionssteuerung

Implementieren Sie Ihre Funktionsänderungen.

myWebApp

# Edit your source files
code Program.cs  # Or your preferred editor

Folgen Sie dem vollständigen Commit-Lebenszyklus:

myWebApp

git status

Ausgabe:On branch feature/myFeature-1Changes not staged for commit:

• geändert: Program.cs*

myWebApp

git add .
git commit -m "feat: implement myFeature-1 with enhanced error handling"

Ausgabe:[feature/myFeature-1 70f67b2] feat: implement myFeature-1 with enhanced error handling1 file changed, 1 insertion(+)

Veröffentlichen im Remote-Repository:

myWebApp

git push -u origin feature/myFeature-1

Ausgabe:Zu https://dev.azure.com/organization/teamproject/_git/MyWebApp

• [new branch] feature/myFeature-1 -> feature/myFeature-1Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

Schritt 3: Azure DevOps CLI-Konfiguration und Erstellung von Pull-Anforderungen

Konfigurieren Sie die Azure DevOps CLI für Ihre Organisation und Ihr Projekt. Ersetzen Sie Organisation und Projektname:

az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

Erstellen Sie einen neuen Pull Request (mithilfe der Azure DevOps CLI), um die Änderungen im Branch „feature-1“ zu überprüfen:

az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

Verwenden Sie den --open Schalter beim Auslösen der Pullanforderung, um sie in einem Webbrowser zu öffnen, nachdem sie erstellt wurde. Der --deletesource-branch Schalter kann verwendet werden, um die Verzweigung zu löschen, nachdem die Pullanforderung abgeschlossen ist. Erwägen Sie außerdem, --auto-complete zu verwenden, um automatisch abzuschließen, wenn alle Richtlinien erfüllt sind und der Quellzweig in den Zielzweig zusammengeführt werden kann.

Das Team überprüft gemeinsam die Codeänderungen und genehmigt den Pull Request:

Der Mainbranch kann jetzt freigegeben werden. Das Team markiert den Mainbranch mit der Releasenummer:

Schritt 4: Parallele Featureentwicklung

Beginnen Sie mit der Arbeit an Feature 2. Erstellen Sie einen Branch an einem Remotespeicherort aus dem Mainbranch, und führen Sie das Auschecken lokal durch:

myWebApp

git push origin main:refs/heads/feature/myFeature-2

Ausgabe:Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

Ändern Sie Program.cs, indem Sie die gleiche Kommentarzeile im Code ändern, der in feature-1 geändert wurde:

```
public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
```

Schritt 5: Feature 2 Pull-Request und Hotfix-Szenario

Committen Sie die Änderungen lokal, pushen Sie sie in das Remoterepository, und lösen Sie dann einen Pull Request aus, um die Änderungen von „feature/myFeature-2“ mit dem Mainbranch zu mergen:

az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

Ein kritischer Fehler wird in der Produktion für das Release „feature-1“ mit dem aktiven Pull Request gemeldet. Um das Problem zu untersuchen, müssen Sie die Version des Codes debuggen, die derzeit in der Produktion bereitgestellt ist. Um das Problem zu untersuchen, erstellen Sie einen neuen fof-Branch, indem Sie das Tag „release_feature1“ verwenden:

myWebApp

git checkout -b fof/bug-1 release_feature1

Ausgabe:Zu einem neuen Branch gewechselt, 'fof/bug-1'.

Schritt 6: Kritische Hotfix-Implementierung

Ändern Sie die Datei „Program.cs“, indem Sie die gleiche Codezeile ändern, die im „feature-1“-Release geändert wurde:

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Stagen Sie Ihre Änderungen, und führen Sie den Commit lokal durch. Pushen Sie dann die Änderungen zum Remoterepository:

myWebApp

git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

Ausgabe:To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.

Schritt 7: Hotfix-Integration und Konfliktauflösung

Unmittelbar nachdem ein Rollout der Änderungen in die Produktion erfolgt ist, markieren Sie den Branch „fof\bug-1“ mit dem Tag „release_bug-1“ und lösen dann einen Pull Request aus, um die Änderungen von „fof/bug-1“ wieder im Mainbranch zu mergen:

az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

Im Rahmen des Pull Requests wird der Branch gelöscht. Mithilfe des Tags können Sie jedoch weiterhin auf den gesamten Verlauf verweisen.

Nachdem der Fix für den kritischen Fehler aus dem Weg geräumt ist, wechseln Sie zur Überprüfung von Pull Request „feature-2“.

Auf der Seite der Branches ist deutlich zu erkennen, dass der Branch „feature/myFeature-2“ eine Änderung mehr und zwei Änderungen weniger als der Mainbranch aufweist:

Wenn Sie versuchen würden, den Pull Request zu genehmigen, würden Sie eine Fehlermeldung erhalten, die Sie über einen Konflikt beim Zusammenführen informiert:

Merge-Konflikte beheben

Um Zusammenführungskonflikte zu beheben, können Sie die Azure DevOps-Weboberfläche verwenden oder lokal mithilfe von Git-Befehlen beheben. Aktualisieren Sie für die lokale Auflösung zuerst Ihren Featurebranch mit den neuesten Änderungen vom Mainbranch:

```CMD
git checkout feature/myFeature-2
git fetch origin
git merge origin/main
```

Lösen Sie die Konflikte in Ihrem bevorzugten Editor und führen Sie dann den Merge durch:

```CMD
git add .
git commit -m "Resolve merge conflicts between feature-2 and main"
git push origin feature/myFeature-2
```

Nachdem die Konflikte behoben wurden, kann die Pullanforderung erfolgreich abgeschlossen werden.

An diesem Punkt können Sie einen Release-Branch basierend auf der kritischen Fehlerbehebung erstellen, die im fof/bug-1-Branch implementiert und in Main zusammengeführt wurde. Erstellen Sie mithilfe des Befehls "git checkout" einen dedizierten Release-Branch aus der Hauptzweigung.

git checkout -b release/v1.1 main

Dieser Befehl erstellt eine neue Verzweigung namens release/v1.1 basierend auf der Hauptverzweigung.

Da wichtige Meilensteine während des Veröffentlichungsprozesses erreicht werden, sollten Sie Veröffentlichungen im Release-Branch mithilfe von Git-Tags markieren. Tags dienen als Markierungen, um bestimmte Versionen der Software zu kennzeichnen.

git tag -a v1.1 -m "Release version 1.1"

Mit diesem Befehl wird ein Tag mit dem Namen v1.1 erstellt, um die Version 1.1 im Release-Branch zu markieren.

Funktionsweise

Wir haben erfahren, wie das Git-Verzweigungsmodell Ihnen die Flexibilität bietet, parallel an Features zu arbeiten, indem Sie für jedes Feature einen Branch erstellen.

Mit dem Pull Request-Workflow können Sie Codeänderungen mithilfe der Branchrichtlinien überprüfen.

Git-Tags sind eine hervorragende Möglichkeit, Meilensteine aufzuzeichnen, z. B. die Version des freigegebenen Codes. Tags bieten Ihnen die Möglichkeit, Branches aus Tags zu erstellen.

Wir haben einen Branch aus einem früheren Releasetag erstellt, um einen kritischen Fehler in der Produktion zu beheben.

Die Ansicht „Zweige“ im Webportal erleichtert das Erkennen von Zweigen, die dem Hauptzweig voraus sind. Außerdem erzwingt sie einen Zusammenführungskonflikt, wenn aktive Pull Requests versuchen, in den Mainbranch zusammenzuführen, ohne die Zusammenführungskonflikte zu beheben.

Mit einem schlanken Verzweigungsmodell können Sie kurzlebige Branches erstellen und qualitative Änderungen schneller in die Produktionsumgebung übertragen.