Jak przejść ze złożonej rzeczywistości rozgałęziającej do modelu jednooddziałowego?

W dużych organizacjach stosowanie metodologii wodospadu zwykle skutkuje bardzo złożonymi strukturami rozgałęziającymi (zwanymi także gałęziami spagetti ).

Jakie strategie rozgałęziania można zastosować do przejścia ze złożonej rzeczywistości rozgałęziania do modelu jednooddziałowego, takiego jak programowanie oparte na pniu?

Aktualizacja:

Aby wyjaśnić, pytanie dotyczy samej migracji / przejścia , a nie metodologii przed i po, które są dość jasne.

Tak naprawdę nie może być „na EOB dzisiaj wciąż jesteśmy wodospadem z gazillionem gałęzi, ale jutro pierwszą rzeczą będzie przejście na opartą na pniu, jedno-gałąź CI”.

Ponieważ wspominasz o wodospadzie, rozumiem, że liczne gałęzie, do których nawiązujesz, to gałęzie cech, a nie gałęzie konserwacji.

W tym ustawieniu zakładam również, że te gałęzie są tworzone zgodnie z planem wodospadu, który próbuje zminimalizować konflikty. Oznacza to, że celem rozwoju jest wytworzenie kilku różnych produktów. Podczas korzystania z modelu rozwoju z jednym oddziałem ważne jest, aby pracować również nad jednym produktem. Jeśli jednocześnie opracowywanych jest kilka produktów w jednym modelu rozwoju, to skutecznie „skleja” ze sobą wersje tych produktów, aby w wersji a repozytorium był produkt zdrowy X i produkt wadliwy Y , natomiast w wersji b produkt X ma regresję, a Y błąd, ale nie mamy wersji, w której zarówno X, jak iY są zdrowe. Taka sytuacja zmusiłaby nas do rozważenia X i Y jako opracowanych w odrębnych repozytoriach, co jest wskazówką, że powinny być.

Dlatego pierwsze kroki powinny wykonać podział repozytorium :

1. Ułóż repozytorium w taki sposób, aby łatwo było je podzielić na kilka małych repozytoriów. Na przykład zmień kolejność bieżącego repozytorium, tak aby każdy katalog najwyższego poziomu odpowiadał repozytorium, które chcesz utworzyć w przyszłości. W ten sposób możesz nadal korzystać z dyscypliny spaghetti z gałęziami, którą wszyscy znają.

2. Po zakończeniu kroku 1 dopracuj dyscyplinę spaghetti-gałęzi, wymagając, aby jakakolwiek gałąź mogła dotykać plików tylko w jednym katalogu najwyższego poziomu.

3. Gdy każda gałąź jest zgodna z krokiem 2, wykonaj podział. Programiści mogą łatwo przekonwertować oczekujące zmiany, aby załatać pojedyncze repozytorium, po prostu usuwając pierwszy poziom ścieżki.

Po przeprowadzeniu podziału możesz rozpocząć pracę nad samą dyscypliną branżową.

4. Wprowadzenie technik programowania pomagających w rozwoju krótkotrwałych gałęzi. Oddziały krótkotrwałe są kluczowym aspektem wszystkich metodologii jednego oddziału. Jednym z ich celów jest ograniczenie czasu poświęcanego na łączenie i debugowanie długotrwałych oddziałów. Popularną techniką jest wprowadzenie „flag funkcji”, w których „fabryka” używa flagi konfiguracji do stworzenia historycznej wersji obiektu lub nowej, początkowo częściowo opracowanej wersji tego obiektu.

5. Do tej pory masz zilliony repozytoriów z tylko kilkoma gałęziami w każdej i możesz przekręcić przycisk „globalnie stosujemy dyscyplinę rozwoju opartego na pniu”, nie widząc, jak oryginalna gałąź spaghetti zawala się na pniu.

Rzeczywisty podział repozytoriów może być opcjonalny, ale należy wówczas przyjąć zasady, które wyraźnie określają dozwolony zakres każdej przesłanej łatki (aby ograniczyć ryzyko konfliktów podczas scalania zmian w głównej gałęzi). Zmniejszenie narzutów związanych z konfliktami jest jednym z celów metodologii modeli jednooddziałowych, więc zakładam, że jest to istotne w twoim kontekście.

Podczas migracji z czegoś do czegoś innego, musisz zdefiniować tylko dwie rzeczy:

1. Jaki jest twój cel
2. Jak się tam dostać (plan migracji)

Pierwsza część jest, niestety, często pomijane lub sposób zbyt ogólnikowy. Nie możesz po prostu powiedzieć, że masz bałagan i chcesz go uporządkować. Co to by znaczyło? Każdy będzie miał inną interpretację (aka: każdy dev uważa, że jego lub jej sposób robienia rzeczy jest najlepsza).

Możliwe, że wszystkie gałęzie, które masz, służą lub służyły celowi. Bez jasno określonego procesu docelowego ludzie będą nadal robić to, co im odpowiada, w sposób, który najbardziej im odpowiada (i słusznie).

Na przykład twój cel powinien być zdefiniowany tak jasno, jak Vincent Driessen zdefiniował swój „udany model rozgałęziania Git” . Jeśli spojrzysz na ten model, jest bardzo precyzyjny: mówi, gdzie powinien być stabilny kod i gdzie należy opracować niestabilne funkcje. Mówi także o tym, jak i kiedy rozgałęzić, zaktualizować i połączyć ponownie. Wiesz, do czego służy każda gałąź i co z nimi zrobić. Używamy odmiany tego, co zaproponował Vincent, a nasza odmiana jest zdefiniowana na naszej wiki.

Ważne jest, aby cały zespół zrozumiał i uzgodnił cel. Warto przypomnieć ludziom, że nie szukasz ich ulubionego modelu rozgałęziania, ale modelu, na który wszyscy członkowie zespołu mogą się zgodzić i z łatwością korzystać.

Po określeniu celu możesz opracować plan migracji. Ten plan może być tak długi lub tak krótki, jak chcesz. Widziałem taki model rozgałęzienia narzucony z dnia na dzień; w innych miejscach odbyło się to na 2 lub 3 sprintach. Nie ma to dla mnie większego znaczenia, dopóki się poprawiamy.

Możesz zacząć od „największych” lub ważniejszych gałęzi. Np .: „odtąd master musi być zawsze w stanie do wdrożenia w prod, a gałąź deweloperów musi się zawsze kompilować” (lub dowolne inne reguły). Następnie wymuś gałęzie wersji (wydania). Następnie wymuszaj gałęzie funkcji. Następnie nałóż zawieszenie kodu na gałąź wersji, jeśli ma to sens.

DevOps to przede wszystkim komunikacja, otwartość i wydajność. Pojęć tych należy pamiętać i przekazywać w trakcie całego procesu.

Proponuję zaprosić osoby spoza zespołu programistów na spotkanie procesowe w charakterze obserwatorów. Operatorzy lub kierownictwo średniego szczebla mogą powiedzieć coś o twoim modelu. Potrzeby programistów powinny być traktowane priorytetowo, ale jeśli model rozgałęzienia nie jest w stanie dostosować się do sposobu zarządzania, lepiej wiedzieć teraz, a nie za miesiąc lub dwa.

Jeśli masz naprawdę duże zespoły, spróbuj jednak uwzględnić wszystkich. W bardzo dużych zespołach i tak skończysz dwa lub trzy spotkania. Zaproś więc kierowników zespołów do pokoju, ale przygotuj webcast i daj o tym wszystkim znać. Jeśli ktoś ma jakieś sugestie lub obawy, będzie w stanie wyrazić je liderowi swojego zespołu, a jeśli będzie ono aktualne, zostanie skierowane na drugim lub trzecim spotkaniu.

W rzeczywistości bardzo proste jest przekształcenie wielozgałęzionego repozytorium hydry w pojedynczy model rozgałęziony.

Po pierwsze, chcesz zacząć od gałęzi, które mają najmniejszą różnicę między sobą a mistrzem lub pniem. Sprawdź ich wiek i znaczenie. Jeśli są nadal aktualne, zacznij je scalać i rozwiązywać konflikty. Jeśli nie są już istotne, usuń je.

Kontynuuj ten proces, aż uda ci się połączyć wszystkie swoje gałęzie, rozwiązać wszystkie konflikty i pozostanie tylko jeden oddział.

Aby rozpocząć, możesz zastosować się do tego prostego schematu:

1. Utwórz kopię gałęzi master / trunk i nazwij ją temp_master
2. Znajdź gałąź o największej dywergencji od mistrza / pnia.
3. Określ, czy gałąź musi być zachowana, zarchiwizowana lub usunięta.
   1. Jeśli trzeba go zachować, przejdź do kroku 4.
   2. Jeśli trzeba go usunąć lub zarchiwizować, usuń go i zarchiwizuj, a następnie wróć do kroku 2.
4. Powtórz krok 2, aby znaleźć następną gałąź o najmniejszej rozbieżności.
5. Scal dwie gałęzie znalezione w kroku 2 i kroku 3, rozwiązując wszystkie konflikty.
6. Połącz te dwie gałęzie w swoją temp_mastergałąź.
7. Przetestuj kod w kodzie temp_master, aby sprawdzić, czy się kompiluje i kompiluje, a także uruchamiaj inne automatyczne testy poprawności.
   1. Jeśli jakiekolwiek testy zakończą się niepowodzeniem, wróć, dowiedz się, dlaczego i napraw je, a następnie powtórz proces.
   2. Jeśli testy nadal się nie udają, wybierz dwie różne gałęzie do pracy.
8. Powtarzaj kroki 2–7, aż będziesz mieć tylko dwie gałęzie: master / trunk i temp_master.
9. Na koniec połącz się temp_masterw master / trunk i żyj ze swoim nowym modelem jednooddziałowym.

W przypadku dużych organizacji z typowymi 4 tygodni wychodzą cyklu Git-Flow jest korzystne podejście, ponieważ można uzyskać korzyści z produkcji Mistrz oddział Feature gotowy oddziale jest zawsze rozmieszczenia Również mistrz oddziału jest czysty od niechcianych zatwierdzeń przez następne dwa popełnić cyklu (z cechą Developi Developoddział opanować).

Co więcej, rozgałęzienie jest również zdeterminowane częstotliwością wydań produkcyjnych. W przypadku częstego wdrażania w produkcji lepiej jest mieć gałąź funkcji lub model scentralizowany. W takim przypadku obciążenie zarządzania oddziałami zostaje przesunięte na solidne testy w niższych środowiskach w celu utrzymania stabilności produkcji.