Wybieranie efektywnej strategii rozgałęziania

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Tworzenie gałęzi dla repozytoriów Kontrola wersji serwera Team Foundation (TFVC) jest przydatne do izolowania ryzyka. Należy wziąć pod uwagę niektóre wyzwania, z którymi zwykle borykają się członkowie zespołu, gdy pracują nad projektem oprogramowania, który jest obsadzony przez ponad pięć lub dziesięć osób:

• Grupa ma kilka (a może kilku) różnych zespołów funkcji, z których każda pracuje nad zestawem funkcji, które są dość dyskretne. Jednak każdy zespół zależy również od funkcjonalności utworzonej przez inne zespoły. Należy odizolować ryzyko zmian wprowadzonych przez pracę wykonaną w każdym z tych zespołów, a jednak ostatecznie należy scalić wszystkie swoje wysiłki razem w jednym produkcie.

• Zespół testowy potrzebuje stabilnej wersji kodu do testowania, a jednak jednocześnie deweloperzy muszą kontynuować pracę z nowymi funkcjami, które od czasu do czasu zdestabilizować produkt.

• Oprogramowanie ma dwie poprzednie wersje i jedną bieżącą wersję w toku. Mimo że większość wysiłków programistycznych jest inwestowana w bieżącą wersję, poprzednie wersje muszą być nadal obsługiwane z okazjonalnymi wydaniami dodatków Service Pack, krytycznymi poprawkami i poprawkami zabezpieczeń oraz innymi zmianami.

W tym artykule opisano kilka typowych strategii rozgałęziania, które ułatwiają podejmowanie właściwej decyzji.

W przeciwieństwie do gałęzi usługi Git, które są objęte zakresem repozytorium, gałęzie kontroli wersji serwera Team Foundation są ograniczone do zakresu ścieżki, a nie jako uproszczone. Ustaw pasek tworzenia gałęzi wysoki i tylko wtedy, gdy potrzebujesz izolacji kodu lub wydania.

Tylko główne

Strategia Tylko główna może być oparta na folderze lub z folderem głównym przekonwertowanym na gałąź, aby włączyć dodatkowe funkcje widoczności. Zmiany są zatwierdzane w gałęzi głównej i opcjonalnie wskazują punkty kontrolne programowania i wydania z etykietami.

RYZYKO: Niezmienność i brak historii z etykietami TFVC mogą zwiększyć ryzyko zmiany kontroli.

Zacznij od głównej strategii rozgałęziania, strategicznie i zastosować inne strategie, aby w razie potrzeby przekształcić się w bardziej złożone strategie.

Izolacja deweloperów

Jeśli musisz zachować i chronić stabilną gałąź główną , możesz rozgałęzić co najmniej jedną gałąź dewelopera z gałęzi głównej. Umożliwia izolację i współbieżne programowanie. Praca może być izolowana w gałęziach programowania przez funkcję, organizację lub tymczasową współpracę.

Istnieje możliwość, że w gałęzi głównej występują zmiany. Zawsze przekazuj integrowanie główne (FI) z gałęzią deweloperów i rozwiązywanie konfliktów scalania. Następnie odwrotna integracja (RI) zmienia się z powrotem na main. Zachowaj ten sam pasek jakości w różnych gałęziach. Kompiluj i uruchamiaj testy weryfikacji kompilacji (BVTs) na deweloperze w taki sam sposób, jak w przypadku głównych zadań.

UWAGA: Dzięki tej strategii zespoły mogą zachować gałąź deweloperów na zawsze, potencjalnie tworząc dużą historię biletów scalania.

Izolacja funkcji

Izolacja cech jest specjalnym wyprowadzeniem izolacji programowania, co pozwala rozgałęzić jedną lub więcej gałęzi funkcji z gałęzi głównych, jak pokazano, lub z gałęzi deweloperskich .

Jeśli musisz pracować nad określoną funkcją, dobrym pomysłem może być utworzenie gałęzi funkcji.

Zachowaj okres istnienia pracy funkcji i skojarzona gałąź funkcji krótkotrwałe. Często integruj zmiany integracji (FI) z gałęzi nadrzędnej. Odwrotna integracja (RI) z powrotem do elementu nadrzędnego tylko wtedy, gdy są spełnione niektóre uzgodnione kryteria zespołu, na przykład definicja zakończona. Wycofywanie funkcji na głównym serwerze może być kosztowne i może resetować testy.

Izolacja wydania

Izolacja wydania wprowadza co najmniej jedną gałąz wydania z gałęzi głównej. Strategia umożliwia współbieżne zarządzanie wydaniami, wiele i równoległe wydania oraz migawki bazy kodu w czasie wydania.

Gdy wydanie będzie gotowe do zablokowania, nadszedł czas, aby utworzyć nową gałąź dla wydania.

Nigdy nie przekazuj integracji (FI) z głównego. Blokuj gałęzie wydania przy użyciu uprawnień dostępu, aby zapobiec niezamierzonym modyfikacjom wydania. Poprawki i poprawki gorące wprowadzone w gałęzi wydania można odwrócić z powrotem do gałęzi głównej.

UWAGA: Żaden ze scenariuszy rozgałęziania nie jest niezmienny, dlatego zauważysz poprawki awaryjne wykonywane w gałęziach wydania. Rozwijaj każdą strategię, aby dopasować się do wymagań, bez utraty wzroku złożoności i powiązanych kosztów.

Izolacja obsługi i wydania

Strategia obsługi i izolacji wydania wprowadza gałęzie obsługi . Ta strategia umożliwia współbieżne zarządzanie pakietami Service Pack oraz migawki bazy kodu w czasie wydania.

Użyj tej strategii, jeśli potrzebujesz modelu obsługi dla klientów w celu uaktualnienia do następnej wersji głównej i dodatkowych dodatków Service Pack na wydanie.

Podobnie jak izolacja wydania, izolacja obsługi i gałęzie wydania są tworzone, gdy wydanie jest gotowe do zablokowania. Nigdy nie przekazuj integracji z głównego do obsługi lub od obsługi do wydania. Zablokuj gałąź wydania, aby zapobiec modyfikacjom. Przyszłe zmiany obsługi można wprowadzić w gałęzi obsługi .

Utwórz nowe gałęzie obsługi i wydania dla kolejnych wydań, jeśli potrzebujesz tego poziomu izolacji.

Obsługa, poprawka, izolacja wydania

Mimo że nie jest to zalecane, można nadal rozwijać strategie, wprowadzając dodatkowe gałęzie poprawek i skojarzone scenariusze wydania.

Na tym etapie pomyślnie zbadano kilka typowych scenariuszy rozgałęziania kontroli wersji serwera Team Foundation. Możesz je rozwijać lub badać inne strategie, takie jak przełączanie funkcji, przełączanie i wyłączanie funkcji, aby określić, czy funkcja jest dostępna w czasie wykonywania.

Q&A

Dlaczego gałęzie powinny być krótkotrwałe?

Utrzymując krótkotrwałe gałęzie, konflikty scalania są przechowywane tak mało, jak to możliwe.

Dlaczego tylko gałąź, jeśli jest to konieczne?

Aby korzystać z metodyki DevOps, musisz polegać na automatyzacji kompilacji, testowania i wdrażania. Zmiany są ciągłe, częste i operacje scalania trudniejsze, ponieważ konflikty scalania często wymagają interwencji ręcznej. Dlatego zaleca się unikanie rozgałęziania i poleganie na innych strategiach, takich jak przełączanie funkcji.

Dlaczego usunąć gałęzie?

Twoim celem powinno być jak najszybsze wprowadzenie zmian do głównych , aby zminimalizować długoterminowe konsekwencje scalania. Tymczasowe, niewykorzystane i obfite gałęzie powodują zamieszanie i obciążenie dla zespołu.

Czy baza kodu może być rozgałęziona między projektami?

Tak. Nie jest to zalecane, chyba że zespoły muszą udostępniać źródło i nie mogą współużytkować wspólnego procesu.

Co z strategią podwyższania poziomu kodu?

Strategia podwyższania poziomu kodu jest podobna do relikwii z epoki rozwoju kaskadowego. Zazwyczaj jest to długie cykle testowania oraz oddzielne zespoły programistyczne i testowe. Strategia nie jest już zalecana. Aby uzyskać więcej informacji na temat tej strategii, zobacz wskazówki dotyczące rozgałęziania.

Dlaczego podczas scalania deweloperów z gałęzią główną nie wykryto żadnych zmian?

Prawdopodobnie zignorowano zmiany w poprzednich scalaniach, na przykład przy użyciu opcji rozwiązywania keep source konfliktów. Aby uzyskać szczegółowe informacje, zobacz scalanie gałęzi programowania z gałęzią główną: nie wprowadzono żadnych zmian w scalaniu .

Czy istnieją podobieństwa między strategiami tfVC i gałęzi git?

Strategia rozgałęziania funkcji tfVC jest podobna do gałęzi tematu usługi Git.

Autorzy: Jesse Houwing, Marcus Fernandez, Mike Fourie i Willy Schaub z ALM | DevOps Rangers. Możesz się z nimi skontaktować tutaj.

c) 2015 Microsoft Corporation. Wszelkie prawa zastrzeżone. Ten dokument jest dostarczany "zgodnie z rzeczywistymi elementami". Informacje i widoki wyrażone w tym dokumencie, w tym adres URL i inne odwołania do witryn internetowych, mogą ulec zmianie bez powiadomienia. Ryzyko korzystania z niniejszego dokumentu ponosi użytkownik.

Na mocy niniejszego dokumentu użytkownik nie uzyskuje jakichkolwiek praw do własności intelektualnej zawartej w jakimkolwiek produkcie firmy Microsoft. Dozwolone jest kopiowanie niniejszego dokumentu i korzystanie z niego do własnych celów pomocniczych.