Strategiczne tworzenie odgałęzień

Kod źródłowy jest istotnym elementem nakładu pracy na tworzenie oprogramowania.Ale efektywne zarządzanie i rozwijanie plików źródłowych, podczas gdy wielu deweloperów pracuje jednocześnie nad aktualizacjami plików może być wyzwaniem.Do przechowywania kodu źródłowego w udostępnionych repozytoriach, izolowania równoległego rozwoju oprogramowania, integracji zmian kodu i przywracania poprzednich wersji pliku można użyć systemu kontroli wersji.Kluczowym elementem kontroli wersji jest tworzenie gałęzi, co pozwala na jednoczesne programowanie.Jeśli tworzysz gałęzie strategicznie, możesz zachować porządek i spójność wielu wersji oprogramowania.

Team Foundation dostarcza elastyczny i niezawodny system kontroli wersji.Możesz użyć Kontrola wersji programu Team Foundation do zarządzania wieloma zmianami podczas wytwarzania kodu źródłowego, dokumentów, elementów roboczych i innych krytycznych informacji, nad którymi pracuje zespół.Aby uzyskać więcej informacji dotyczących kontroli wersji w Visual Studio Team Foundation Server, zobacz Korzystanie z systemu kontroli wersji.

Jak zespół zarządza kodem podczas równoczesnego dodawania wielu zmian poprzez kilka wydań projektu?

Podczas pracy z systemem kontroli wersji, należy rozważyć, jak będzie wyglądać struktura gałęzi.Można stworzyć gałąź poprzez dublowanie pliku kodu źródłowego.Następnie możesz zmienić gałąź bez wpływania na źródło.Na przykład, struktura gałęzi na poniższej ilustracji pokazuje, że gałąź MAIN zawiera kompletną funkcjonalność, która przeszła testy integracji, a gałąź DEVELOPMENT zawiera kod, który jest w trakcie tworzenia.Gdy nowa funkcjonalność w gałęzi DEVELOPMENT jest ukończona i przejdzie testy integracji, możesz przenieść kod z gałęzi DEVELOPMENT do gałęzi MAIN.Ten proces nazywa się integracja odwrotna.I na odwrót, jeśli scalasz kod z gałęzi MAIN do gałęzi DEVELOPMENT, proces ten nazywany jest integracją przednią.

Aby uzyskać więcej informacji dotyczących sposobu tworzenia i scalania gałęzi kodu, zobacz następującą stronę w witrynie CodePlex w sieci Web: Przewodnik rozgałęzień programu Team Foundation Server 2.0.

Tworzenie gałęzi i scalanie pociągają za sobą następujące reguły:

1. Każda gałąź musi mieć zdefiniowaną zasadę dotyczącą sposobu integracji kodu do tej gałęzi.Na przykład, w strukturze gałęzi z poprzedniej ilustracji można przypisać członka zespołu, aby posiadał i zarządzał gałęzią MAIN.Ten członek zespołu jest odpowiedzialny za wykonywanie początkowej operacji gałęzi, odwrócenie zmian integracji z gałęzi DEVELOPMENT do gałęzi MAIN, oraz integrację przednią zmian z gałęzi MAIN do gałęzi DEVELOPMENT.Integracja przednia jest ważna, gdy gałąź MAIN integruje także zmiany z innych gałęzi.

2. Gałąź MAIN musi zawierać kod, który przeszedł testy integracji, żeby być zawsze gotowa do wydania.

3. Gałąź DEVELOPMENT (lub robocza) ciągle ewoluuje, ponieważ członkowie zespołu okresowe ewidencjonują zmiany.

4. Etykiety są migawkami plików w gałęzi w określonym czasie.

   Aby uzyskać więcej informacji, zobacz Korzystanie z etykiet do wykonywania migawek plików.

Team Foundation Build pozwala wybierać spośród wielu typów kompilacji dla gałęzi: manualna, ciągła, bramkowana, stopniowa i zaplanowana.Zaleca się, żeby gałąź MAIN posiadała typ kompilacji bramkowanego zaewidencjonowania.Oznacza to, gałąź DEVELOPMENT musi spełnić wszystkie wymagania dla gałęzi MAIN, przed zatwierdzeniem integracji odwrotnej.Gałąź DEVELOPMENT powinna uruchamiać kompilację typu ciągłego, ponieważ zespół musi jak najszybciej wiedzieć, gdy nowe zaewidencjonowanie wpływa na gałąź DEVELOPMENT.

Jak często zespół powinien wykonywać integrację odwrotną i przednią?

Jak pokazano na poniższej ilustracji, integracja odwrotna i przednia powinny występować przynajmniej w momencie ukończenia historii użytkownika.Chociaż każdy zespół może zdefiniować kompletność inaczej, ukończenie historii użytkownika oznacza na ogół zakończenie zarówno funkcjonalności, jak i odpowiadających testów jednostkowych.Możesz wykonać integrację odwrotną do gałęzi MAIN tylko po tym, gdy testy jednostkowe potwierdziły stabilność gałęzi DEVELOPMENT.

Jeśli masz więcej niż jedną gałąź roboczą (DEVELOPMENT), integracja przednia na wszystkich gałęziach powinna wykonywać się jak tylko gałąź zostanie zintegrowana z gałęzią MAIN.Ponieważ gałąź MAIN jest stale stabilna, integracja przednia jest bezpieczna.Konflikty lub błędy w gałęziach roboczych mogą występować, ponieważ nie można zagwarantować, że gałęzie robocze są stabilne.

Bardzo ważne jest, aby rozwiązywać wszystkie konflikty tak szybko jak to tylko możliwe.Za pomocą bramkowanego zaewidencjonowania gałęzi MAIN integracja odwrotna może być o wiele prostsza, ponieważ bramki jakości pomagają unikać konfliktów i błędów w gałęzi MAIN.Aby uzyskać więcej informacji, zobacz Budowanie wyboru w oczekujące zmiany, które są kontrolowane przez Gated Zaewidencjonuj.

Jak zespół zarządza źródłem, które implementuje różne historie użytkownika?

Jak pokazano na poniższej ilustracji, zmiany można ewidencjonować okresowo, aby ukończyć historię użytkownika.Możesz implementować wiele historii użytkownika na tej samej gałęzi w tym samym czasie.Jednakże, możesz wykonać integrację odwrotną do gałęzi MAIN tylko gdy ukończysz całą pracę w toku.Zaleca się grupować historie użytkownika ze względu na podobny rozmiar, ponieważ duża historia użytkownika może zablokować integrację wielu mniejszych.Można podzielić dwa zestawy historii użytkownika na dwie gałęzie.

Kiedy zespół powinien dodać gałąź?

Gałęzie powinno się tworzyć w następujących sytuacjach:

• Kiedy należy wydać kod na podstawie innego harmonogramu/cyklu niż istniejące gałęzie.

• Kiedy kod wymaga innych zasad gałęzi.Jeśli tworzona jest nowa gałąź z nowymi zasadami, można dodać wartość strategiczną do projektu.

• Kiedy funkcjonalność jest wydana do klienta, a zespół planuje dokonanie zmian, które nie wpłyną na zaplanowany cykl wydania.

Nie należy tworzyć nowej gałęzi dla każdej historii użytkownika, ponieważ powoduje to wzrost kosztów integracji.Chociaż sprawia, że tworzenie gałęzi jest łatwe, przyszłościowe zarządzanie gałęziami może być znaczące, gdy istnieje wiele gałęzi.

Jak zespół zarządza wydaniami z perspektywy kontroli wersji?

Zespół powinien móc tworzyć wydanie kodu na koniec każdego sprintu.Za pomocą Team Foundation Server można oznaczyć gałąź, by tworzyła migawkę kodu w określonym punkcie czasu.Jak pokazano na poniższej ilustracji, możesz oznaczyć gałąź MAIN do wydania.Dzięki temu, będzie można przywrócić gałąź do stanu z tego punktu.

Ponieważ musisz implementować aktualizacje na wydaniach, tworzenie gałęzi dla wydania pomaga zespołowi kontynuować pracę niezależnie w kolejnym sprincie, bez tworzenie konfliktów z przyszłymi wydaniami.Na poniższej ilustracji przedstawiono gałąź, która zawiera kod dla aktualizacji i która jest odwrotnie zintegrowana do gałęzi MAIN po wydaniu na koniec drugiego sprintu.

Po utworzeniu gałęzi dla wydania, należy stworzyć gałąź z gałęzi MAIN, która jest najbardziej stabilna.Jeśli tworzysz gałąź dla wydania z gałęzi roboczej, może to spowodować zagrożenia integracji, ponieważ stabilność gałęzi roboczych nie jest gwarantowana.