Poprzednie

Następne

Omówienie rozgałęziania

Ukończone

Podczas kompilowania szablonów Bicep i pracy w repozytorium Git wszystkie zmiany zespołu zostaną ostatecznie scalone z gałęzią główną repozytorium. Ważne jest, aby chronić gałąź główną, tak aby żadne niepożądane zmiany nie zostały wdrożone w środowisku produkcyjnym. Chcesz jednak, aby twoi współautorzy mogli elastycznie pracować, współpracować z zespołem i łatwo wypróbować pomysły.

W tej lekcji dowiesz się więcej na temat strategii rozgałęziania i sposobu ochrony głównej gałęzi. Dowiesz się również, jak skonfigurować proces przeglądu dla gałęzi.

Dlaczego chcesz chronić gałąź główną?

Gałąź główna jest źródłem prawdy dla tego, co jest wdrażane w środowiskach platformy Azure. W przypadku wielu rozwiązań będziesz mieć wiele środowisk, takich jak programowanie, kontrola jakości (QA) i produkcja. W innych scenariuszach może istnieć tylko środowisko produkcyjne. Niezależnie od liczby używanych środowisk gałąź główna jest gałęzią, do której współtworzyją członkowie zespołu. Ich zmiany ostatecznie lądują na głównej gałęzi.

Typowy proces może być następujący:

1. Członek zespołu klonuje udostępnione repozytorium.
2. Wprowadzają zmiany lokalne w gałęzi we własnej lokalnej kopii repozytorium.
3. Po zakończeniu wprowadzania zmian scalają te zmiany w gałęzi głównej repozytorium lokalnego.
4. Wypychają te zmiany do głównej gałęzi repozytorium zdalnego.
5. W niektórych scenariuszach wypychanie repozytorium zdalnego wyzwala zautomatyzowany potok w celu weryfikowania, testowania i wdrażania kodu. Więcej informacji na temat potoków znajdziesz w innych modułach platformy Microsoft Learn.

Na poniższym diagramie przedstawiono ten proces:

Załóżmy, że zmiany członka zespołu wprowadziły subtelną usterkę. Po zakończeniu procesu usterka znajduje się teraz w głównej gałęzi projektu i zostanie wdrożona w środowisku produkcyjnym. Możesz go nie odnaleźć, dopóki nie spróbujesz go wdrożyć i wystąpi błąd. Lub w przypadku innych typów usterek wdrożenie może zakończyć się powodzeniem, ale może spowodować drobne problemy później.

W innym scenariuszu załóżmy, że członek zespołu pracuje nad funkcją i wypycha połowę ukończonej pracy funkcji do głównej gałęzi repozytorium udostępnionego. Teraz masz zmiany w gałęzi głównej, które nie zostały ukończone lub przetestowane. Te zmiany prawdopodobnie nie powinny być wdrażane w środowisku produkcyjnym. Wdrożenia w środowisku produkcyjnym mogą być blokowane do momentu zakończenia funkcji. Jeśli nowo ukończone funkcje znajdują się w gałęzi głównej, może nie być możliwe ich wdrożenie u klientów.

Napiwek

Te problemy są szczególnie trudne w przypadku dużych zespołów, w których wiele osób współtworzy ten sam kod, ale wskazówki zawarte w tym module są cenne, gdy tylko współpracujesz z więcej niż jedną osobą. Wskazówki są przydatne nawet wtedy, gdy tylko pracujesz nad projektem i pracujesz nad wieloma funkcjami w tym samym czasie.

Lepszym sposobem pracy jest oddzielenie zmian podczas pracy nad nimi. Następnie możesz przejrzeć wszelkie zmiany przez innego członka zespołu, zanim zostaną one scalone z główną gałęzią udostępnionego repozytorium twojego zespołu. Ten proces ułatwia zespołowi podjęcie świadomej decyzji o zmianie przed zatwierdzeniem jej scalenia.

Gałęzie funkcji

Gałąź funkcji wskazuje nowy element pracy, który rozpoczynasz. Praca może być zmianą konfiguracji na zasób zdefiniowany w pliku Bicep lub nowy zestaw zasobów, które należy wdrożyć. Za każdym razem, gdy rozpoczynasz nową pracę, tworzysz nową gałąź funkcji.

Gałąź funkcji jest tworzona z gałęzi głównej. Podczas tworzenia gałęzi upewnij się, że zaczynasz od bieżącego stanu środowiska platformy Azure. Następnie należy wprowadzić wszystkie niezbędne zmiany.

Ponieważ wszystkie zmiany kodu są zatwierdzane w gałęzi funkcji, nie zakłócają one gałęzi głównej repozytorium. Jeśli ktoś inny w twoim zespole musi wprowadzić pilną zmianę w gałęzi głównej, może to zrobić w innej gałęzi funkcji, która jest niezależna od Twoich.

Możesz też współpracować nad gałęziami funkcji. Publikując i wypychając gałąź funkcji do udostępnionego repozytorium, ty i członkowie zespołu mogą współpracować nad zmianą. Możesz również przekazać funkcję innej osobie, aby ukończyć, gdy idziesz na wakacje.

Aktualizowanie gałęzi funkcji

Chociaż gałąź funkcji jest w toku, inne funkcje mogą zostać scalone z gałęzią główną repozytorium. Wynikiem jest to, że gałąź funkcji i główna gałąź projektu odchodzą od siebie. Im dalej odchodzą od siebie, tym trudniej jest ponownie scalić dwie gałęzie w późniejszym momencie, a im więcej konfliktów scalania może wystąpić.

Gałąź funkcji należy regularnie aktualizować tak, aby zawierała wszelkie zmiany wprowadzone w głównej gałęzi repozytorium. Warto również zaktualizować gałąź funkcji przed rozpoczęciem scalania gałęzi funkcji z powrotem z gałęzią główną. W ten sposób upewnij się, że nowe zmiany można łatwo scalić z gałęzią główną.

Napiwek

Scal gałąź główną z gałęzią funkcji często.

Używanie małych, krótkotrwałych gałęzi

Celuj w krótkotrwałe gałęzie cech. Takie podejście pomaga uniknąć konfliktów scalania przez skrócenie czasu, przez jaki gałęzie mogą nie być zsynchronizowane. Takie podejście ułatwia również współpracownikom zrozumienie wprowadzonych zmian, co jest przydatne, gdy potrzebujesz kogoś do przejrzenia zmian.

Podziel duże fragmenty pracy na mniejsze elementy i utwórz gałąź cech dla każdego z nich. Im większa funkcja, tym dłużej ktoś musi nad nią pracować, a im dłużej będzie działać gałąź funkcji. Mniejsze zmiany można wdrożyć w środowisku produkcyjnym podczas scalania każdej gałęzi funkcji i stopniowo kompilować szerszą pracę.

Wyobraź sobie, że wprowadzasz pewne zmiany w zestawie kodu Bicep. Przenosisz niektóre definicje zasobów do modułów. Musisz również dodać nowe zasoby do plików Bicep. Dobrym pomysłem może być najpierw refaktoryzacja wszystkich modułów we własnej gałęzi. Po scaleniu modułów możesz rozpocząć pracę nad dodatkami do plików Bicep. Oddzielając zmiany, należy zachować każdą zmianę — i jej gałąź — małą i łatwą do zrozumienia.

Podczas pracy w ten sposób warto użyć słowa kluczowego if , aby wyłączyć wdrażanie zasobów, dopóki nie będą gotowe. Poniższy przykładowy kod pokazuje, jak za pomocą if słowa kluczowego utworzyć plik Bicep, który definiuje konto magazynu, ale wyłącza wdrożenie konta magazynu do momentu zakończenia wszystkich zmian.

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

Możesz użyć parametrów, aby określić różne wartości dla zmiennej storageAccountReady w różnych środowiskach. Można na przykład ustawić wartość parametru na true wartość dla środowiska testowego i false środowiska produkcyjnego. W ten sposób możesz wypróbować nowe konto magazynu w środowisku testowym.

Uwaga

Po włączeniu funkcji w środowisku produkcyjnym należy pamiętać, że należy wykonać następujące kroki, aby zmiany zaczęły obowiązywać:

1. Zmień wartość parametru.
2. Ponownie wdróż plik Bicep.

Scalanie gałęzi funkcji

Po zakończeniu pracy z gałęzią funkcji należy scalić ją z gałęzią główną repozytorium. Dobrym rozwiązaniem jest przejrzenie zmian wprowadzonych w gałęzi funkcji przed scaleniem. Żądania ściągnięcia umożliwiają przeglądanie kodu. Więcej informacji na temat żądań ściągnięcia znajdziesz w dalszej części tego modułu.

Ochrona gałęzi

W usłudze GitHub można skonfigurować ochronę gałęzi dla głównej gałęzi repozytorium udostępnionego. Ochrona gałęzi wymusza reguły, takie jak:

• Nie można scalić żadnej zmiany z gałęzią główną z wyjątkiem żądania ściągnięcia.
• Zmiany należy przejrzeć przez co najmniej dwie inne osoby.

Jeśli ktoś spróbuje wypchnąć zatwierdzenie bezpośrednio do chronionej gałęzi, wypychanie zakończy się niepowodzeniem. Dowiesz się, jak zastosować ochronę gałęzi w następnej lekcji.

Zasady gałęzi

W usłudze Azure DevOps można skonfigurować zasady gałęzi dla głównej gałęzi repozytorium udostępnionego. Zasady gałęzi wymuszają reguły, takie jak:

• Nie można scalić żadnej zmiany z gałęzią główną z wyjątkiem żądania ściągnięcia.
• Zmiany należy przejrzeć przez co najmniej dwie inne osoby.

Jeśli ktoś spróbuje wypchnąć zatwierdzenie bezpośrednio do chronionej gałęzi, wypychanie zakończy się niepowodzeniem. Dowiesz się, jak zastosować zasady gałęzi w następnej lekcji.

Inne strategie rozgałęziania

Podczas współpracy nad kodem Bicep można użyć różnych strategii rozgałęziania. Każda strategia rozgałęziania ma zalety i wady.

Proces, który znasz do tej pory, to wersja strategii rozwoju opartej na magistrali. W tej strategii rozgałęziania praca jest wykonywana w gałęziach funkcji krótkotrwałych, a następnie jest scalona z pojedynczą gałęzią główną. Możesz automatycznie wdrożyć zawartość głównej gałęzi repozytorium udostępnionego w środowisku produkcyjnym za każdym razem, gdy zmiana zostanie scalona, lub może zostać wsadowa zmiana i zwolnić je zgodnie z harmonogramem, tak jak co tydzień. Programowanie oparte na magistrali jest łatwe do zrozumienia i umożliwia współpracę bez większych obciążeń.

Niektóre zespoły oddzielają pracę, którą wykonali od pracy wdrożonej w środowisku produkcyjnym. Używają one długotrwałej gałęzi programowania jako elementu docelowego do scalania gałęzi funkcji. Scalają gałąź programowania z gałęzią główną po wydaniu zmian w środowisku produkcyjnym.

Niektóre inne strategie rozgałęziania wymagają utworzenia gałęzi wydania. Gdy masz zestaw zmian gotowych do wdrożenia w środowisku produkcyjnym, należy utworzyć gałąź wydania ze zmianami do wdrożenia. Te strategie mogą mieć sens podczas wdrażania infrastruktury platformy Azure w regularnym zakresie lub integrowania zmian z wieloma innymi zespołami.

Inne strategie rozgałęziania obejmują usługi Gitflow, GitHub Flow i GitLab Flow. Niektóre zespoły używają usługi GitHub Flow lub GitLab Flow, ponieważ umożliwia oddzielenie pracy od różnych zespołów oraz oddzielenie pilnych poprawek błędów od innych zmian. Te procesy mogą również umożliwić rozdzielenie zatwierdzeń na różne wersje rozwiązania, co jest nazywane wybieraniem wiśni. Wymagają one jednak większego zarządzania, aby upewnić się, że zmiany są ze sobą zgodne. Sekcja Podsumowanie tego modułu zawiera linki do dodatkowych informacji na temat tych strategii rozgałęziania.

Strategia rozgałęziania, która jest odpowiednia dla Twojego zespołu, zależy od sposobu, w jaki twój zespół pracuje, współpracuje i zwalnia zmiany. Dobrym pomysłem jest rozpoczęcie od prostego procesu, takiego jak programowanie oparte na magistrali. Jeśli okaże się, że zespół nie może efektywnie pracować przy użyciu tego procesu, stopniowo wprowadza inne warstwy rozgałęziania lub przyjmuje strategię rozgałęziania; należy jednak pamiętać, że w miarę dodawania kolejnych gałęzi zarządzanie repozytorium staje się bardziej złożone.

Napiwek

Niezależnie od używanej strategii rozgałęziania warto używać zasad gałęzi do ochrony głównej gałęzi i używania żądań ściągnięcia do przeglądania zmian. Inne strategie rozgałęziania również przedstawiają ważne gałęzie, które należy chronić.

W tym module używamy programowania opartego na magistrali z gałęziami funkcji, ponieważ jest to łatwe w użyciu.

Kontynuuj