Strategiczna gałąź
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Kod źródłowy jest ważnym elementem w pracy programistycznej. Jednak może to stanowić wyzwanie, aby skutecznie zarządzać plikami źródłowymi i rozwijać je, gdy wielu deweloperów pracuje jednocześnie nad aktualizacjami plików. Za pomocą systemu kontroli wersji można przechowywać kod źródłowy w udostępnionych repozytoriach, odizolować równoległe prace programistyczne, zintegrować zmiany kodu i odzyskać poprzednie wersje plików. Kluczowym elementem kontroli wersji jest rozgałęzianie, które umożliwia jednoczesne programowanie. Jeśli rozgałęzisz strategicznie, możesz zachować kolejność i spójność wielu wersji oprogramowania.
Team Foundation zapewnia elastyczny i niezawodny system kontroli wersji. Za pomocą kontroli wersji programu Team Foundation można zarządzać wieloma poprawkami podczas tworzenia kodu źródłowego, dokumentów, elementów roboczych i innych krytycznych informacji, nad którymi pracuje twój zespół.
Jak zespół zarządza kodem, wprowadzając wiele zmian jednocześnie za pośrednictwem kilku wydań projektu?
Podczas pracy z systemem kontroli wersji należy wziąć pod uwagę sposób konfigurowania struktury gałęzi. Gałąź można utworzyć, dublując plik kodu źródłowego. Następnie możesz zmienić gałąź bez wpływu na źródło. Na przykład, jak pokazano w strukturze gałęzi na poniższej ilustracji, gałąź MAIN zawiera ukończone funkcje, które przeszły testy integracji, a gałąź DEVELOPMENT zawiera kod, który jest w budowie. Po ukończeniu nowej funkcji w gałęzi DEVELOPMENT i przejściu testów integracji można podwyższyć poziom kodu z gałęzi DEVELOPMENT do gałęzi MAIN. Ten proces jest nazywany odwrotną integracją. Z drugiej strony, jeśli scalisz kod z gałęzi MAIN z gałęzią DEVELOPMENT, proces jest określany jako integracja przekazywania dalej.
Aby uzyskać więcej informacji na temat tworzenia i scalania gałęzi kodu, zobacz następującą stronę w witrynie sieci Web CodePlex: Team Foundation Server Branching Guide 2.0 (Przewodnik rozgałęziania serwera Team Foundation Server 2.0).
Rozgałęzianie i scalanie wiąże się z następującymi zasadami:
Każda gałąź musi mieć zdefiniowane zasady dotyczące sposobu integrowania kodu z tą gałęzią. Na przykład w strukturze gałęzi poprzedniej ilustracji można przypisać członka zespołu do własnej gałęzi MAIN i zarządzać nią. Ten element członkowski jest odpowiedzialny za wykonanie operacji początkowej gałęzi, odwrócenie integrowania zmian z gałęzi DEVELOPMENT do gałęzi MAIN i przekazywanie zmian z gałęzi MAIN do gałęzi DEVELOPMENT. Integracja do przodu jest ważna, gdy gałąź MAIN integruje się również ze zmianami z innych gałęzi.
Gałąź MAIN musi zawierać kod, który przeszedł testy integracji, aby był zawsze gotowy do wydania.
Gałąź programowanie (lub praca) stale ewoluuje, ponieważ członkowie zespołu okresowo ewidencjonują zmiany.
Etykiety to migawki plików w gałęzi w określonym czasie.
Aby uzyskać więcej informacji, zobacz Używanie etykiet do tworzenia migawki plików.
Team Foundation Build umożliwia wybór spośród kilku typów kompilacji dla gałęzi: ręczne, ciągłe, bramowane, stopniowe i zaplanowane. Zalecamy, aby gałąź MAIN zawierała typ kompilacji zaewidencjonowanej bramki. Oznacza to, że gałąź DEVELOPMENT musi przekazać wszystkie wymagania dla gałęzi MAIN przed zatwierdzeniem integracji odwrotnej. Gałąź DEVELOPMENT powinna uruchamiać typ ciągłej kompilacji, ponieważ zespół musi wiedzieć, jak najszybciej, gdy nowe zaewidencjonowanie wpływa na gałąź programowania.
Jak często zespół powinien cofnąć integrację i kontynuować integrację?
Jak pokazano na poniższej ilustracji, integracja odwrotna i integracja z usługą forward powinna odbywać się co najmniej po ukończeniu scenariusza użytkownika. Mimo że każdy zespół może definiować kompletność inaczej, ukończenie scenariusza użytkownika zwykle oznacza, że ukończysz zarówno funkcje, jak i odpowiednie testy jednostkowe. Integrację z gałęzią MAIN można cofnąć dopiero po sprawdzeniu stabilności gałęzi DEVELOPMENT.
Jeśli masz więcej niż jedną gałąź pracy (PROGRAMOWANIE), należy przekazać integrację do wszystkich gałęzi roboczych, gdy tylko każda gałąź zostanie zintegrowana z gałęzią MAIN. Ponieważ gałąź MAIN jest stabilna, integracja do przodu jest bezpieczna. Mogą wystąpić konflikty lub błędy w gałęziach roboczych, ponieważ nie można zagwarantować, że gałęzie robocze są stabilne.
Ważne jest, aby jak najszybciej rozwiązać wszystkie konflikty. Korzystając z zaewidencjonowanego zaewidencjonowanego dla gałęzi MAIN, można znacznie ułatwić integrację odwrotną, ponieważ bramy jakości pomagają uniknąć konfliktów lub błędów w gałęzi MAIN. Aby uzyskać więcej informacji, zobacz Ewidencjonowanie w folderze kontrolowanym przez proces kompilacji zaewidencjonowanej bramki.
W jaki sposób zespół zarządza źródłami, które implementują różne scenariusze użytkowników?
Jak pokazano na poniższej ilustracji, można okresowo sprawdzać zmiany w gałęzi roboczej, aby ukończyć historię użytkownika. Można zaimplementować wiele scenariuszy użytkownika w tej samej gałęzi w tym samym czasie. Można jednak cofnąć integrację z gałęzią MAIN tylko wtedy, gdy ukończysz wszystkie prace w toku. Zaleca się grupowanie scenariuszy użytkowników według podobnego rozmiaru, ponieważ nie chcesz, aby duża historia użytkownika blokowała integrację wielu małych scenariuszy. Dwa zestawy scenariuszy użytkownika można podzielić na dwie gałęzie.
Kiedy zespół powinien dodać gałąź?
Należy utworzyć gałęzie w następujących sytuacjach:
Jeśli musisz wydać kod w innym harmonogramie/cyklu niż istniejące gałęzie.
Gdy kod wymaga innych zasad gałęzi. Jeśli tworzysz nową gałąź zawierającą nowe zasady, możesz dodać wartość strategiczną do projektu.
Gdy funkcja zostanie wydana klientowi i zespołowi planuje wprowadzić zmiany, które nie mają wpływu na planowany cykl wydania.
Nie należy tworzyć rozgałęziania dla każdego scenariusza użytkownika, ponieważ tworzy on wysoki koszt integracji. Mimo że funkcja TFVC ułatwia rozgałęzianie, obciążenie związane z zarządzaniem gałęziami może stać się znaczące, jeśli masz wiele gałęzi.
Jak zespół zarządza wydaniami z perspektywy kontroli wersji?
Twój zespół powinien mieć możliwość wydania kodu na końcu dowolnego przebiegu. Za pomocą serwera Team Foundation Server można oznaczyć gałąź, aby utworzyć migawkę kodu w określonym punkcie w czasie. Jak pokazano na poniższej ilustracji, możesz oznaczyć gałąź MAIN jako wydanie. Umożliwia to zwrócenie gałęzi do jej stanu w tym momencie.
Ponieważ należy zaimplementować aktualizacje w wersjach, utworzenie gałęzi dla wydania pomaga zespołowi w dalszym ciągu pracować niezależnie od następnego przebiegu bez tworzenia konfliktów z przyszłymi wersjami. Poniższa ilustracja przedstawia gałąź zawierającą kod aktualizacji i która jest odwrócona zintegrowana z gałęzią MAIN po wydaniu na końcu drugiego przebiegu.
Podczas tworzenia gałęzi dla wydania należy utworzyć gałąź z gałęzi MAIN, która jest najbardziej stabilna. Jeśli gałąź zostanie zwolniona z gałęzi roboczej, może to spowodować problemy z integracją, ponieważ stabilność gałęzi roboczych nie jest gwarantowana.