Wprowadzenie zasady rozgałęziania kontroli wersji dla małego zespołu

Jestem kontrahentem, który niedawno rozpoczął działalność w firmie.

Zespół składa się z 3 programistów składających się z 2 deweloperów poziomu średniego i średniego, wkrótce inny na tym samym poziomie i ja (6 lat doświadczenia). Dla obu obecnych programistów jest to ich pierwsza praca poza uniwersytetem / uczelnią i nigdy wcześniej nie mieli wyższego programisty nadzorującego ich pracę.

Nie ma wyraźnych zasad kontroli wersji. Programiści wykonują wszystkie prace programistyczne w bagażniku, a następnie wdrażają do produkcji bezpośrednio ze swoich maszyn programistycznych. Istniejący zespół nie zna rozgałęzień.

Zmieniam to wszystko i wprowadzam CI, serwery testowe / testowe / produkcyjne itp., Wraz z polityką kontroli wersji, aby to uzupełnić.

System kontroli źródła to TFS, z którego nigdy wcześniej nie korzystałem. Jest skonfigurowany jako jedno gigantyczne repozytorium.

Zapisałem dla nich kilka wskazówek, ale czy jest coś jeszcze, co powinienem dodać / zmienić, mając na uwadze doświadczenie zespołu?

Polityka kontroli wersji

Rozwój odbywa się na pniu

Jeśli szacuje się, że zmiana potrwa dłużej niż tydzień, należy to zrobić na gałęzi, z regularnymi połączeniami z pnia do gałęzi, aby zatrzymać dwie synchronizacje.

Zwolnij gałęzie utworzone dla kodu produkcyjnego. Ta gałąź powinna zawierać tylko stabilny kod. Możemy mieć jedną gałąź wydania, która jest aktualizowana z pnia raz na sprint, lub możemy utworzyć oddzielną gałąź wydania na każdy tydzień.

Jeśli konieczne jest pilne usunięcie błędu wpływającego na kod produkcyjny, zostanie on wykonany w gałęzi wydania i ponownie włączony do linii głównej.

Jeśli zastosujemy strategię jednej gałęzi wydania, pień zostanie scalony z gałęzią wydania raz na sprint pod koniec sprintu.

Jeśli zastosujemy oddzielną gałąź dla każdej strategii wydania, to bagażnik NIGDY nie zostanie scalony z gałęzią wydania

W niektórych scenariuszach może być konieczne dwukrotne usunięcie błędu w różnych gałęziach, jeśli gałęzie są zbyt rozbieżne. Jeśli wykonujemy krótkie sprinty, nie powinno to zdarzać się zbyt często.

Planuję mieć trzy serwery. Środowisko testowe, w którym zawsze działa najnowszy kod w repozytorium. Środowisko pomostowe, w którym działa najnowszy kandydat do wydania w wersji pomostowej / testowej Kod kandydujący do wydania i cele UAT oraz środowisko produkcyjne.

Powodem, dla którego planuję to zrobić, jest to, że do tej pory klient robił tylko oprogramowanie wewnętrzne. Najnowszy projekt jest dla głośnego klienta medialnego i mam wrażenie, że zespół musi przyjąć bardziej profesjonalny model rozwoju niż to, co robi obecnie.

Na przykład w tej chwili użytkownik może zadzwonić do zespołu z raportem błędu. Deweloperzy lokalizują i naprawiają błąd, wykonują szybki test gałki ocznej na własnych komputerach, a następnie wdrażają bezpośrednio do produkcji. Żadnych automatycznych testów ani nic takiego.

Z perspektywy czasu myślę, że gałąź funkcji jest o krok za daleko i usunę ją.

Zasadniczo sprowadza się to do: a) braku rozgałęzienia w ogóle) b) gałęzi wydania i pnia, oraz c) gałęzi wydania na wydanie i pnia.

Pochylałem się w kierunku tego drugiego. Początkowo myślałem, że będę mieć zarówno kandydata do wydania, jak i wydanie, które będą działały jednocześnie na osobnych serwerach (UAT / Production), ale faktycznie magistrala jest kandydatem do wydania w dowolnym momencie, więc oddział na wydanie skłania się ku szaleństwu. Moją jedyną myślą byłoby, gdybyśmy nie chcieli, aby nasi interesariusze widzieli kod programistyczny, moglibyśmy potrzebować oddzielnej gałęzi kandydatów do wydania, ale YAGNI i tak dalej .....

Dla zespołu 3-4 deweloperów proponujesz ZBYT zbyt wiele oddziałów.

Każda tworzona gałąź ma dodatkowe koszty, które wiążą się z kosztami (czas spędzony na scalaniu, śledzenie, gdzie to jest itp.) Musisz upewnić się, że korzyści wynikające z posiadania oddziału przewyższają koszty.

Należy pamiętać, że jedyną prawdziwą korzyścią dla oddziału jest izolacja kodu. Oznacza to, że potrzebujesz konkretnego powodu, aby chcieć izolować kod.

Posiadanie osobnej gałęzi wydania dla każdego sprintu jest szalone. Dlaczego potrzebujesz kodu z jednego sprintu odizolowanego od kodu na następny? Dlaczego nie mieć tylko jednej gałęzi stabilnego wydania, która jest przenoszona z każdym sprintem?

Jeśli szacuje się, że zmiana potrwa dłużej niż tydzień, należy to zrobić na gałęzi, z regularnymi połączeniami z pnia do gałęzi, aby zatrzymać dwie synchronizacje.

Prawie każda nietrywialna nowa funkcja zajmie co najmniej tydzień w czasie rzeczywistym po uwzględnieniu rozwoju, testowania programistów, codziennych przerw i innych działań itp.

Co to jest „regularne scalanie”? Codziennie? Co tydzień? Każde wykonane scalenie wymaga czasu - musisz upewnić się, że docelowa gałąź scalania buduje się i działa po wprowadzonych zmianach. W małym zespole częste łączenie się wiąże się z dużymi kosztami.

Mamy zespół 4 programistów pracujących na ponad 1 milionowej linii kodu i tak działamy:

• Główny oddział, w którym odbywa się cały rozwój
• Jeden oddział na główne wydanie (wykonywane mniej więcej raz w roku)

Jedną z głównych zasad jest: nie wpisuj kodu, który się nie buduje.

Otóż ​​to. Prosty, łatwy do zrozumienia, zapewnia potrzebną izolację (w dowolnym momencie możemy stworzyć kompilację wydania dla dowolnej wersji).

Zalety wykonania wszystkich prac programistycznych w jednym oddziale:

1. Programiści są zawsze w synchronizacji. Żadnych bolesnych fuzji, ponieważ dwaj programiści byli przez kilka tygodni w swoich oddziałach, tworząc niekompatybilne zmiany.
2. Zepsute kompilacje znajdują się tego samego dnia. Mamy nocną wersję, która uruchamia najnowszy kod na main. Jeśli ktoś wpisze kod, który z jakiegoś powodu się nie buduje, od razu się dowiemy.
3. Ponieważ wszyscy zawsze pracują nad tym samym kodem, zwiększa to prawdopodobieństwo, że błąd zostanie wykryty wcześniej niż później.
4. Żadnych narzutów związanych z scalaniem innych niż ukierunkowane poprawki w celu zwolnienia gałęzi. W małym zespole ten jest duży.

Zapisałeś dla nich kilka wskazówek, ale nie wyjaśniłeś, dlaczego twoje podejście jest lepsze niż to, z którego już korzystają . To może być problematyczne. Jeśli jesteś w duchu „Zrobimy to po swojemu, ponieważ mam sześcioletnie doświadczenie zawodowe, a ty nie” (i czytając twoje pytanie, wygląda dokładnie tak), bądź przygotowany na nienawiść przez członkowie twojego zespołu, którzy spróbują zrobić wszystko, aby nie zastosować twoich koncepcji.

Czy mają problem, który należy rozwiązać? Ważne jest, aby najpierw odpowiedzieć na to pytanie, ponieważ albo rzeczywiście mają problem i chętnie przyjmą twoje sugestie, albo doskonale działają tak, jak obecnie, i po prostu narzucasz im swój sposób pracy , tylko dlatego, że wolisz pracować w ten sposób.

W końcu zmuszenie ich do korzystania z gałęzi może mieć bardzo negatywny wpływ . Praca z pniem jest łatwa, szczególnie w środowisku Agile. Deweloper dokonuje zmian w magistrali, ostatecznie rozwiązując małe konflikty, a te zmiany są natychmiast wykorzystywane przez platformę ciągłej integracji. Z oddziałami:

• Deweloper musi pomyśleć, gdzie powinna się znaleźć zmiana,

• Ktoś musi zarządzać oddziałami i scala się z gałęzi do pnia,

• Połączenia między oddziałami są wykonywane rzadziej niż zatwierdzenia, co oznacza, że ​​ktoś musi radzić sobie z konfliktami, które są większe i trudniejsze do rozwiązania niż konflikt między dwoma zatwierdzeniami,

• Każde zatwierdzenie niekoniecznie musi znaleźć drogę do ciągłej integracji, co opóźnia informacje, które programiści uzyskują na temat efektów, jakie może mieć zatwierdzenie (zwłaszcza regresje).

Fakt, że:

Istniejący zespół nie zna rozgałęzień

jeszcze gorzej. Pracowałem w zespole niedoświadczonych programistów, w których niedoświadczony menedżer postanowił grać z oddziałami. Spowodowało to dużo ( dużo ) zmarnowanego czasu i jest dokładnie tym, czego chcesz uniknąć w przypadku projektu, który ma terminy.

Jak mówi Mainma, uważaj na rozgałęzienia. Mówisz o rozgałęzianiu co kilka tygodni, czy naprawdę trzeba mieć wiele oddziałów?

Alternatywnie, możesz również mieć model „pull” zamiast modelu push. Jeśli korzystasz z Git lub Mercurial, serwer integracji może zweryfikować ich zmiany przed przekazaniem ich do serwera centralnego. W TFS możesz zrobić coś podobnego za pomocą bramkowanych odpraw . W ten sposób można sprawdzić poprawność i uniknąć złożoności gałęzi.