Kiedy należy tworzyć gałęzie rozwoju?

Przenosimy zespół naszego projektu z jednej gałęzi Main / Trunk do wielu gałęzi Development / Work, które powinny być regularnie łączone w Main. Opieramy nasz nowy proces na tym artykule i Przewodniku rozgałęziania TFS (korzystamy z TFS i Visual Studio 2010).

Obecnie nad projektem pracuje od 1 do 5 osób. Main musi być stabilny przez cały czas, ponieważ chcemy, aby opcja była dostępna w dowolnym momencie. Nie mamy ustalonych sprintów - przynajmniej jeszcze nie teraz - i obecnie publikujemy je co 1-2 tygodnie.

W tym momencie każda osoba naprawia błędy w aplikacji. Za kilka tygodni rozpoczniemy prace nad nowym dużym komponentem do aplikacji.

Jednym z problemów, który znajdujemy, jest to, kiedy należy tworzyć gałęzie rozwoju . Będziemy wdrażać wiele historii użytkowników równolegle w zależności od zestawu umiejętności programisty. Zastanawialiśmy się nad utworzeniem oddziału dla każdego programisty, ale to nie ma sensu, ponieważ zawsze będzie potrzeba współpracy nad częścią pracy. Nie możemy sobie poradzić z jedną gałęzią programowania, ponieważ będziemy chcieli połączyć się z Main, dopóki inne prace zostaną zakończone.

Czy ktoś ma jakieś wskazówki na ten temat?

Nie przepadam za dowolnymi gałęziami, tj. Poprawkami Freda lub poprawkami Harry'ego. Czuję się bardziej komfortowo z jedną (niezależną) funkcją jednej gałęzi, która pozwala wielu programistom działać na jednej funkcji; ale aby funkcja została scalona dopiero po jej ukończeniu.

Tak więc teraz potrzebujesz tylko gałęzi „bugfix”, ale kiedy zaczniesz programować, powinieneś utworzyć gałąź dla każdej ważnej funkcji. W ten sposób po ich zakończeniu można je połączyć i wydać bez uzależnienia od innych funkcji buggiera.

Nie jestem pewien, jak dobry jest TFS w fuzji, ale na pewno się dowiesz za kilka miesięcy :)

Nie możemy sobie poradzić z jedną gałęzią programowania, ponieważ będziemy chcieli połączyć się z Main, dopóki inne prace zostaną zakończone.

Wygląda na to, że już wiesz, że należy utworzyć wiele gałęzi programistycznych. Przychodzą mi na myśl dwa prawdopodobne scenariusze:

1. Każdy z pięciu programistów pracuje nad niezależnymi częściami projektu (usuwanie błędów) - Upewnij się, że dla każdego programisty jest utworzona osobna gałąź . To nakłada ciężar i odpowiedzialność na każdego programistę, aby upewnić się, że jego zestaw zmian nie koliduje z pracą innej osoby. Jest wysoce prawdopodobne, że jeden z pięciu programistów popełni błąd. Jeśli tak jest, nie ma sensu, aby wszyscy inni byli powstrzymywani.
2. Rozwój wielu funkcji - niezależnie od liczby programistów pracujących nad konkretną funkcją / błędem, należy je rozdzielić. Przykładem tego jest to, że wszystkie zatwierdzenia kodu są częścią opracowywanych funkcji - nie ma potrzeby odgadywania.

Implikowane gałęzie pracy z DVCS

Używamy Mercurial, więc w polu deweloperskim programistów znajduje się domyślna gałąź pracy. Zatwierdzanie jest zawsze wykonywane w lokalnym obszarze roboczym. Po zakończeniu wydawanego utworu jest on wypychany na główny serwer repo, gdzie jest automatycznie budowany i testowany.

Prawie nigdy nie tworzymy wyraźnych oddziałów, ale z drugiej strony nasze sprinty nigdy nie trwają dłużej niż tydzień, a karty nie muszą trwać dłużej niż 1-2 dni.

Ponadto można złagodzić ból związany z scalaniem, łącząc wątki w pracy z innymi częściami kodu lub innymi projektami, aby ludzie nie musieli wykonywać trudnych połączeń przez cały czas.

Użyłem zarówno jednej gałęzi na historię, jak i jednej gałęzi na wydanie (wszyscy programiści zameldują swoje historie do deweloperów i jeśli którykolwiek z nich zepsuje gałąź dewelopera, jest ona zepsuta dla wszystkich). Gorąco polecam jedną gałąź na historię, jeśli nie lubisz konfliktów. Gałąź deweloperów zawsze pozostanie stabilna dla wszystkich deweloperów i nie będzie czasu oczekiwania na programistę pracującego nad fragmentem kodu, który inny programista już złamał. Po zakończeniu historii cały kod znajduje się w oddziale. Scalisz go z programistą, ale nie zameldujesz się i nie przetestujesz, w przypadku konfliktu rozwiążesz go i poprosisz osobę, z którą się konfliktujesz, aby nie usunął swojego kodu. Następnie połącz z dev. Pomaga to wszystkim programistom pracować płynnie. To zależy również od wielkości firmy. Nasza firma ma 200 programistów pracujących jednocześnie na jednej bazie kodu, ale oddzielna gałąź dla ich historii. Po scaleniu kodu z gałęzią programistyczną gałąź historii jest natychmiast usuwana. Mam nadzieję, że to pomoże. Dzięki

Jeśli jest to oparte na git, wystarczy utworzyć gałąź dla każdej poprawki błędu, naprawić błąd w najkrótszym możliwym czasie, połączyć gałąź naprawy błędów z gałęzią programowania, a następnie przesunąć zmianę do gałęzi programowania. Przeglądanie żądań ściągania i scalania powinno mieć najwyższy priorytet, ponieważ im szybciej to zrobisz, tym większe szanse, że scalanie nie spowoduje problemów. Po scaleniu gałęzie te można usunąć.