Git-vertakkingsmodel verkennen voor continue levering

Succesvolle softwarelevering is afhankelijk van een vertakkingsstrategie die snelheid, kwaliteit en risicobeheer in balans brengt. Het doel is om verbeteringen snel te verzenden terwijl de productiestabiliteit behouden blijft.

Strategische balans: snelheid versus kwaliteit

Een effectief vertakkingsmodel moet het juiste evenwicht vinden:

• Minimaliseer procesoverhead om de marktintroductietijd te versnellen.
• Onderhoud kwaliteitspoorten om te voorkomen dat defecten productie bereiken.
• Schakel parallelle ontwikkeling in voor de schaalbaarheid van het team.
• Ondersteuning voor snelle hotfix-implementatie voor kritieke problemen.

Hoewel er talloze Git-vertakkingsstrategieën bestaan, combineert de meest effectieve benadering bewezen patronen met de specifieke behoeften van uw team. Moderne bedrijfsteams gebruiken doorgaans een lichtgewicht, op trunk gebaseerd ontwikkelingsmodel dat is gericht op functievertakkingen en pull-aanvragen.

Kernprincipe: Altijd-Klare Hoofdbranch

In deze les leert u hoe u een doorlopend vertakkingsmodel implementeert dat gereed is voor levering met behulp van functievertakkingen en pull-aanvragen om een consistent te implementeren hoofdvertakking te onderhouden.

Framework voor Enterprise Branchingsstrategie

De volgende principes vormen een robuuste basis voor continue levering:

Stabiliteit van Hoofdtak

• Eén bron van waarheid: de hoofdbranch is het exclusieve pad voor productiereleases.
• Productiegereedheid: de hoofdbranch moet altijd een implementeerbare status hebben.
• Vertakkingsbeveiliging: implementeer uitgebreid vertakkingsbeleid om directe doorvoeringen te voorkomen.
• Gated changes: alle wijzigingen stromen uitsluitend via pull-aanvragen.
• Releasetracking: Tag alle productiereleases met semantische Git-tags.

Functiebranch-discipline

• Geïsoleerde ontwikkeling: Maak specifieke vertakkingen voor alle functies en bugfixes.
• Functievlag-integratie: Langlopende functies beheren met functieknoppen om de levensduur van vertakkingen te verminderen.
• Strategische naamgeving: gebruik beschrijvende naamconventies die bedrijfswaarde weerspiegelen.
• Werkstroom voor pull-aanvragen: samenvoegen tot het hoofd uitsluitend via gecontroleerde pull-aanvragen.

Release Branch Strategie

• Toegewijde voorbereiding: Maak release branches van stabiele functie-integratiepunten.
• Kwaliteitsborging: Voer grondige tests en stabilisatie uit op releasebranches.
• Productie-opharding: Laatste bugfixes en prestatieoptimalisaties toepassen.
• Mijlpalen bijhouden: belangrijke releasemijlpalen taggen voor traceerbaarheid.

Naamconventies voor schaal

# 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

Beheer van pull-aanvragen

• Verplichte codebeoordeling: geen uitzonderingen voor directe samenvoegingen naar het hoofd.
• Geautomatiseerde validatie: CI/CD-pijplijnen integreren voor kwaliteitspoorten.
• Metrische gegevens over prestaties: voltooiingstijd van pull-aanvragen bijhouden en optimaliseren.
• Kennis delen: gebruik beoordelingen voor het afdwingen van teamleer en standaarden.

Vereisten en installatie

Essentiële hulpprogramma's voor Git-werkstromen voor ondernemingen

In deze praktische oefening wordt gebruikgemaakt van de uitgebreide DevOps-hulpprogrammaketen van Azure:

• Azure CLI: Cloudeigen opdrachtregelinterface voor Azure-services.
• Azure DevOps CLI: Gespecialiseerde extensie voor naadloze integratie van Git-, CI/CD- en Agile-hulpprogramma's in Windows, Linux en macOS.

Azure DevOps CLI-configuratie

De Azure DevOps CLI biedt flexibele uitvoeropmaak (JSON, YAML, table, TSV) ter ondersteuning van verschillende automatiseringsscenario's. Configureer de gewenste indeling met behulp van:

az devops configure --defaults output=table

Praktische Implementatie: Enterprise-Git-werkstroom

In dit uitgebreide overzicht ziet u git-vertakkingen op bedrijfsniveau voor continue levering, met informatie over de ontwikkeling van functies, hotfiximplementatie en conflictoplossing.

Stap 1: Functiebranch maken en ontwikkelen

Maak een feature branch volgens bedrijfsnaamgevingsconventies.

myWebApp

git checkout -b feature/myFeature-1

Uitvoer:Overgeschakeld naar een nieuwe branche 'feature/myFeature-1'.

Vertakkingscontext en werkstructuurstatus controleren:

myWebApp

git branch

Uitvoer:✓ feature/myFeature-1

• voornaamste*

Stap 2: Functie-implementatie en versiebeheer

Uw functiewijzigingen implementeren:

myWebApp

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

Volg de volledige doorvoerlevenscyclus:

myWebApp

git status

Uitvoer:Bij vertakkingsfunctie/myFeature-1wijzigingen die niet zijn gefaseerd voor doorvoer:

• gewijzigd: Program.cs*

myWebApp

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

Uitvoer:[feature/myFeature-1 70f67b2] feat: implementeer myFeature-1 met verbeterde foutafhandeling1 bestand gewijzigd, 1 insertion(+)

Publiceren naar externe opslagplaats:

myWebApp

git push -u origin feature/myFeature-1

Uitvoer:Aan https://dev.azure.com/organization/teamproject/_git/MyWebApp

• [nieuwe vertakking] functie/myFeature-1 -> functie/myFeature-1Branch-functie/myFeature-1 ingesteld voor het bijhouden van externe vertakkingsfunctie/myFeature-1 van oorsprong.

Stap 3: Azure DevOps CLI-configuratie en het maken van pull-aanvragen

Azure DevOps CLI configureren voor uw organisatie en project. Organisatie- en projectnaam vervangen:

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

Maak een nieuwe pull-aanvraag (met behulp van de Azure DevOps CLI) om de wijzigingen in de functie-1-vertakking te controleren:

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

Gebruik de --open schakeloptie bij het ophalen van de pull-aanvraag om deze te openen in een webbrowser nadat deze is gemaakt. De --deletesource-branch switch kan worden gebruikt om de vertakking te verwijderen nadat de pull-aanvraag is voltooid. Overweeg --auto-complete ook om automatisch te voltooien wanneer alle beleidsregels zijn doorgegeven en de bronbranch kan worden samengevoegd in de doelbranch.

Het team controleert gezamenlijk de codewijzigingen en keurt de pull-aanvraag goed:

De belangrijkste is klaar om vrij te geven. Team tagt de hoofdbranch met het releasenummer:

Stap 4: Parallelle functieontwikkeling

Begin met werken aan functie 2. Maak een vertakking op afstand vanuit de hoofdbranch en voer de betaling lokaal uit:

myWebApp

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

Uitvoer:Totaal 0 (delta 0), hergebruikt 0 (delta 0) Tot https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nieuwe vertakking] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Uitvoer:Overgeschakeld naar een nieuwe branch 'feature/myFeature-2'. Branch 'feature/myFeature-2' ingesteld om de remote branch 'feature/myFeature-2' van origin te volgen.

Wijzig Program.cs door dezelfde opmerkingsregel in de code te wijzigen die is gewijzigd in functie-1:

```
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();
```

Stap 5: Pull-aanvraag en hotfixscenario voor functie 2

Voer de wijzigingen lokaal door, push ze naar de externe opslagplaats en dien vervolgens een pull-aanvraag in om de wijzigingen van functie/myFeature-2 samen te voegen aan de hoofdvertakking:

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

Er wordt een kritieke fout gerapporteerd in productie tegen de release van feature-1 met de pull-aanvraag tijdens de vlucht. Als u het probleem wilt onderzoeken, moet u fouten opsporen in de versie van de code die momenteel in productie is geïmplementeerd. Als u het probleem wilt onderzoeken, maakt u een nieuwe fof-vertakking met behulp van de release_feature1-tag:

myWebApp

git checkout -b fof/bug-1 release_feature1

Uitvoer:Overgeschakeld naar een nieuwe vertakking, 'fof/bug-1'.

Stap 6: Kritieke hotfix-implementatie

Wijzig Program.cs door dezelfde regel code te wijzigen die is gewijzigd in de release van feature-1:

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();

Faseer en voer de wijzigingen lokaal door en push vervolgens wijzigingen naar de externe opslagplaats:

myWebApp

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

Uitvoer:Naar https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nieuwe vertakking] fof/bug-1 - fof/bug-1 Branch fof/bug-1 ingesteld voor het bijhouden van externe vertakking fof/bug-1 van oorsprong.

Stap 7: Hotfix-integratie en conflictoplossing

Onmiddellijk nadat de wijzigingen zijn geïmplementeerd in productie, tagt u de vertakking fof\bug-1 met de tag release_bug-1 en genereert u vervolgens een pull-aanvraag om de wijzigingen van fof/bug-1 weer samen te voegen in de hoofdmap:

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

Als onderdeel van de pull-aanvraag wordt de vertakking verwijderd. U kunt echter nog steeds verwijzen naar de volledige geschiedenis met behulp van de tag.

Nu de kritieke foutoplossing uit de weg is gegaan, gaan we de pull-aanvraag voor functie 2 bekijken.

Op de pagina vertakkingen wordt duidelijk dat de functie/myFeature-2-vertakking één wijziging voor de hoofd- en twee wijzigingen achter de hoofdvertakking is:

Als u de pull-aanvraag goedkeurt, ziet u een foutbericht met de melding dat er een samenvoegingsconflict is opgetreden:

Samenvoegingsconflicten oplossen

Als u samenvoegingsconflicten wilt oplossen, kunt u de Azure DevOps-webinterface gebruiken of deze lokaal oplossen met behulp van Git-opdrachten. Voor lokale oplossing moet u eerst uw feature-branch bijwerken met de meest recente wijzigingen van de main-branch.

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

Los de conflicten in de gewenste editor op en voltooi de samenvoegbewerking:

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

Als de conflicten zijn opgelost, kan de pull-aanvraag worden voltooid.

Op dit moment kunt u een releasebranch maken op basis van de kritieke foutoplossing die is geïmplementeerd in de vertakking fof/bug-1 en samengevoegd in de hoofdvertakking. Maak met behulp van de git-uitcheckopdracht een toegewezen releasebranch vanuit de hoofdbranch.

git checkout -b release/v1.1 main

Met deze opdracht maakt u een nieuwe vertakking met de naam release/v1.1 op basis van de hoofdbranch.

Aangezien belangrijke mijlpalen tijdens het releaseproces worden bereikt, worden tagreleases in de releasebranch met behulp van Git-tags gebruikt. Tags fungeren als markeringen om specifieke versies van de software aan te geven.

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

Met deze opdracht maakt u een tag met de naam v1.1 om de releaseversie 1.1 in de releasebranch te markeren.

Hoe het werkt

We hebben geleerd hoe het Git-vertakkingsmodel u de flexibiliteit biedt om parallel aan functies te werken door voor elke functie een vertakking te maken.

Met de werkstroom voor pull-aanvragen kunt u codewijzigingen controleren met behulp van het vertakkingsbeleid.

Git-tags zijn een uitstekende manier om mijlpalen vast te leggen, zoals de versie van code die is vrijgegeven; tags bieden u een manier om vertakkingen van tags te maken.

We hebben een vertakking gemaakt van een vorige releasetag om een kritieke fout in productie op te lossen.

De vertakkingenweergave in de webportal maakt het eenvoudig om vertakkingen vóór de hoofdsite te identificeren. Het dwingt ook een samenvoegingsconflict af als lopende pull-aanvragen proberen samen te voegen naar de hoofdmap zonder de samenvoegingsconflicten op te lossen.

Met een lean vertakkingsmodel kunt u kortstondige vertakkingen maken en kwaliteitswijzigingen sneller naar productie pushen.