Eksploruj model gałęzi Git na potrzeby ciągłego dostarczania

Pomyślne dostarczanie oprogramowania zależy od strategii rozgałęziania, która równoważy szybkość, jakość i zarządzanie ryzykiem. Celem jest szybkie dostarczanie ulepszeń przy zachowaniu stabilności produkcyjnej.

Równowaga strategiczna: szybkość a jakość

Skuteczny model rozgałęziania musi mieć właściwą równowagę:

• Zminimalizuj nakład pracy związany z procesami , aby przyspieszyć czas obrotu.
• Zachowaj bramy jakości , aby zapobiec dotarciu do produkcji wad.
• Włącz programowanie równoległe w celu zapewnienia skalowalności zespołu.
• Obsługa szybkiego wdrażania poprawek w przypadku krytycznych problemów.

Chociaż istnieje wiele strategii rozgałęziania Git, najbardziej efektywne podejście łączy sprawdzone wzorce z konkretnymi potrzebami zespołu. Nowoczesne zespoły przedsiębiorstwa zwykle wdrażają uproszczony model programowania oparty na magistrali skoncentrowany na gałęziach funkcji i żądaniach ściągnięcia.

Podstawowa zasada: Zawsze-gotowa główna gałąź

W tej lekcji nauczysz się implementować model rozgałęziania gotowy do ciągłego dostarczania przy użyciu gałęzi funkcjonalnych i żądań pull request, aby zachować zawsze wdrażalną gałąź główną.

Struktura strategii rozgałęziania przedsiębiorstwa

Następujące zasady stanowią solidną podstawę ciągłego dostarczania:

Stabilność gałęzi głównej

• Jedno źródło prawdy: główna gałąź jest wyłączną ścieżką dla wydań produkcyjnych.
• Gotowość produkcyjna: główna gałąź musi być zawsze gotowa do wdrożenia.
• Ochrona gałęzi: zaimplementuj kompleksowe polityki oddziału, aby zapobiec bezpośrednim zatwierdzeniom.
• Zmiany kontrolowane: wszystkie modyfikacje przepływają wyłącznie przez żądania pull.
• Śledzenie wydania: tagowanie wszystkich wersji produkcyjnych przy użyciu semantycznych tagów usługi Git.

Dyscyplina gałęzi funkcji

• Programowanie izolowane: utwórz dedykowane gałęzie dla wszystkich funkcji i poprawek błędów.
• Integracja flag funkcjonalnych: Zarządzanie długoterminowymi funkcjami za pomocą przełączników funkcji, aby skrócić czas istnienia gałęzi.
• Strategiczne nazewnictwo: użyj opisowych konwencji nazewnictwa, które odzwierciedlają wartość biznesową.
• Przepływ pracy pull requestów: Scalenie do głównego wyłącznie przez zatwierdzone pull requesty.

Strategia gałęzi wydania

• Dedykowane przygotowanie: tworzenie gałęzi wydania na podstawie stabilnych punktów integracji funkcji.
• Kontrola jakości: Przeprowadzanie dokładnych testów i stabilizacji w oddziałach wydań.
• Wzmacnianie zabezpieczeń w środowisku produkcyjnym: stosowanie ostatecznych poprawek usterek i optymalizacji wydajności.
• Śledzenie kamieni milowych: Oznaczanie istotnych etapów wydania dla zapewnienia możliwości śledzenia.

Konwencje nazewnictwa na potrzeby skalowania

# 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

Zarządzanie Pull Requestami

• Obowiązkowy przegląd kodu: brak wyjątków dla bezpośrednich scalania do głównego.
• Automatyczna walidacja: integracja potoków CI/CD dla kontroli jakości.
• Metryki wydajności: śledzenie i optymalizowanie czasu ukończenia żądania pull.
• Udostępnianie wiedzy: używanie przeglądów na potrzeby uczenia zespołowego i wymuszania standardów.

Wymagania wstępne i konfiguracja

Podstawowe narzędzia dla przepływów pracy git dla przedsiębiorstw

To praktyczne ćwiczenie wykorzystuje kompleksowy łańcuch narzędzi DevOps platformy Azure:

• Interfejs wiersza polecenia platformy Azure: natywny dla chmury interfejs wiersza polecenia dla usług platformy Azure.
• Interfejs wiersza polecenia usługi Azure DevOps: wyspecjalizowane rozszerzenie do bezproblemowej integracji narzędzi Git, CI/CD i narzędzi Agile w systemach Windows, Linux i macOS.

Konfiguracja interfejsu wiersza polecenia usługi Azure DevOps

Interfejs wiersza polecenia usługi Azure DevOps zapewnia elastyczne formatowanie danych wyjściowych (JSON, YAML, table, TSV) w celu obsługi różnych scenariuszy automatyzacji. Skonfiguruj preferowany format przy użyciu:

az devops configure --defaults output=table

Praktyczna implementacja: Przepływ pracy Git dla przedsiębiorstw

Ten wyczerpujący przewodnik przedstawia rozgałęzianie Git na poziomie enterprise w celu ciągłego dostarczania, obejmujące opracowywanie funkcji, wdrażanie poprawek i rozwiązywanie konfliktów.

Krok 1. Tworzenie i programowanie gałęzi funkcji

Utwórz gałąź funkcji zgodnie z konwencjami nazewnictwa przedsiębiorstwa:

myWebApp

git checkout -b feature/myFeature-1

Wynik:Przełączono na nową gałąź 'feature/myFeature-1'.

Sprawdź kontekst gałęzi i stan drzewa roboczego:

myWebApp

git branch

Dane wyjściowe:✓ feature/myFeature-1

• główny*

Krok 2. Implementacja funkcji i kontrola wersji

Zaimplementuj zmiany funkcji:

myWebApp

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

Postępuj zgodnie z pełnym cyklem życia commitowania:

myWebApp

git status

Wynik:Na gałęzi feature/myFeature-1Zmiany nie przygotowane do zatwierdzenia:

• zmodyfikowane: Program.cs*

myWebApp

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

Output:[feature/myFeature-1 70f67b2] feat: wdrożenie myFeature-1 z ulepszoną obsługą błędówZmieniono 1 plik, 1 wstawienie(+)

Publikowanie w repozytorium zdalnym:

myWebApp

git push -u origin feature/myFeature-1

Dane wyjściowe:Do https://dev.azure.com/organization/teamproject/_git/MyWebApp

• [nowa gałąź] feature/myFeature-1 —> feature/myFeature-1Gałąź feature/myFeature-1 została skonfigurowana do śledzenia zdalnej gałęzi feature/myFeature-1 z origin.

Krok 3: Konfiguracja CLI (interfejsu wiersza polecenia) usługi Azure DevOps i tworzenie pull requestu.

Konfigurowanie interfejsu wiersza polecenia usługi Azure DevOps dla organizacji i projektu. Zastąp nazwę organizacji i projektu:

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

Utwórz nowe żądanie ściągnięcia kodu (przy użyciu interfejsu wiersza polecenia usługi Azure DevOps), aby przejrzeć zmiany w gałęzi feature-1.

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

Użyj przełącznika --open podczas tworzenia pull requestu, aby otworzyć go w przeglądarce internetowej po jego utworzeniu. Przełącznik --deletesource-branch może służyć do usuwania gałęzi po zakończeniu pull requestu. Należy również rozważyć użycie polecenia --auto-complete do automatycznego ukończenia, gdy wszystkie zasady zostaną spełnione, a gałąź źródłowa może zostać scalona z gałęzią docelową.

Zespół wspólnie przegląda zmiany kodu i zatwierdza pull request.

Główny element jest gotowy do wydania. Zespół oznaczy gałąź główną numerem wydania:

Krok 4. Programowanie funkcji równoległych

Rozpocznij pracę nad funkcją 2. Utwórz gałąź zdalną z gałęzi głównej i wyewidencjonuj lokalnie:

myWebApp

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

Output:Total 0 (delta 0), ponownie wykorzystano 0 (delta 0) Do https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nowa gałąź] origin/HEAD —> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Wynik:Przełączono na nową gałąź 'feature/myFeature-2'. Gałąź 'feature/myFeature-2' skonfigurowano do śledzenia zdalnej gałęzi 'feature/myFeature-2' z miejsca pochodzenia.

Zmodyfikuj Program.cs, zmieniając ten sam wiersz komentarza w kodzie zmienionym w funkcji-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();
```

Krok 5. Scenariusz żądania ściągnięcia i poprawki funkcji 2

Zatwierdź zmiany lokalnie, wypchnij je do zdalnego repozytorium, a następnie zgłoś Pull Request, aby scalić zmiany z feature/myFeature-2 z gałęzią główną.

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

Zgłoszono krytyczną usterkę w wersji produkcyjnej feature-1 z pull requestem w toku. Aby zbadać ten problem, należy debugować względem wersji kodu aktualnie wdrożonego w środowisku produkcyjnym. Aby zbadać problem, utwórz nową gałąź fof przy użyciu tagu release_feature1:

myWebApp

git checkout -b fof/bug-1 release_feature1

Wynik:Przełączono na nową gałąź 'fof/bug-1'.

Krok 6. Implementacja poprawek krytycznych

Zmodyfikuj Program.cs, zmieniając ten sam wiersz kodu, który został zmieniony w wersji 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();

Przygotuj i zatwierdź zmiany lokalnie, a następnie wypchnij zmiany do repozytorium zdalnego:

myWebApp

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

Output:Do https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [nowa gałąź] fof/bug-1 - fof/bug-1 Gałąź fof/bug-1 skonfigurowano do śledzenia zdalnej gałęzi fof/bug-1 z origin.

Krok 7. Integracja poprawek i rozwiązywanie konfliktów

Natychmiast po wdrożeniu zmian w środowisku produkcyjnym oznacz gałąź fof/bug-1 tagiem release_bug-1, a następnie utwórz pull request, aby scalić zmiany z fof/bug-1 z powrotem do gałęzi główna.

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

W ramach żądania ściągnięcia gałąź zostanie usunięta. Można jednak nadal odwoływać się do całej historii przy użyciu tagu .

Po usunięciu krytycznej usterki, przejrzyjmy żądanie ściągnięcia feature-2.

Strona gałęzi jasno pokazuje, że gałąź feature/myFeature-2 ma jedną zmianę więcej niż główna i dwie zmiany mniej niż główna.

Jeśli spróbujesz zatwierdzić pull request, zobaczysz komunikat o błędzie, który informuje o konflikcie scalania:

Rozwiązać konflikty scalania

Aby rozwiązać konflikty scalania, możesz użyć interfejsu internetowego usługi Azure DevOps lub rozwiązać je lokalnie przy użyciu poleceń usługi Git. Aby rozwiązać problem lokalny, najpierw zaktualizuj gałąź funkcji przy użyciu najnowszych zmian z gałęzi głównej:

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

Rozwiąż konflikty w preferowanym edytorze, a następnie zakończ scalanie:

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

Po rozwiązaniu konfliktów, można pomyślnie ukończyć pull request.

W tym momencie można utworzyć gałąź wydania na podstawie krytycznej poprawki błędów zaimplementowanej w gałęzi fof/bug-1 i scalić ją z gałęzią main. Za pomocą polecenia git checkout utwórz dedykowaną gałąź release z głównej gałęzi.

git checkout -b release/v1.1 main

To polecenie tworzy nową gałąź o nazwie release/v1.1 na podstawie głównej gałęzi.

W miarę osiągania znaczących kamieni milowych podczas procesu wydawania, oznaczaj wydania w gałęzi wydawniczej za pomocą tagów Git. Tagi służą jako znaczniki, aby oznaczyć określone wersje oprogramowania.

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

To polecenie tworzy tag o nazwie v1.1, aby oznaczyć wersję 1.1 w gałęzi release.

Jak to działa

Dowiedzieliśmy się, jak model rozgałęziania Git zapewnia elastyczność pracy nad funkcjami równolegle przez utworzenie gałęzi dla każdej funkcji.

Przepływ pracy pull requestu umożliwia przeglądanie zmian w kodzie przy użyciu zasad gałęzi.

Tagi usługi Git to doskonały sposób rejestrowania kamieni milowych, takich jak wersja wydanego kodu; tagi umożliwiają tworzenie gałęzi na podstawie tagów.

Utworzyliśmy gałąź z poprzedniego tagu wydania, aby naprawić krytyczną usterkę w środowisku produkcyjnym.

Widok gałęzi w portalu internetowym ułatwia identyfikowanie gałęzi wyprzedzających główną gałąź. Ponadto wymusza konflikt scalania, jeśli jakiekolwiek trwające pull requesty próbują scalić z główną gałęzią bez rozwiązania konfliktów scalania.

"Odchudzony model rozgałęziania pozwala tworzyć krótkotrwałe gałęzie i szybciej wdrażać zmiany jakościowe do produkcji."