Czy moja firma łączy oddziały w niewłaściwy sposób?

Ostatnio natknąłem się na artykuł MSDN na temat rozgałęziania i łączenia oraz SCM: Rozgałęzianie i łączenie podkładu - Chris Birmele .

W artykule mówią, że „połączenie wielkiego wybuchu” to łączący się antypattern:

Big Bang Merge - odroczenie połączenia gałęzi do końca prac rozwojowych i próba scalenia wszystkich gałęzi jednocześnie.

Uświadomiłem sobie, że jest to bardzo podobne do tego, co robi moja firma ze wszystkimi produkowanymi działami rozwoju.

Pracuję w bardzo małej firmie, w której jedna osoba pełni rolę organu kontroli ostatecznego przeglądu + scalania tułowia. Mamy 5 programistów (w tym mnie), każdemu z nas zostanie przypisane oddzielne zadanie / błąd / projekt i każdy z nas odłączy się od bieżącego pnia (subversion), a następnie wykonamy prace programistyczne w naszym oddziale, przetestuje wyniki, napisze dokumentację w razie potrzeby wykonaj wzajemną ocenę i sprzężenie zwrotne z innymi programistami, a następnie prześlij oddział do przeglądu + scalenia w naszym oprogramowaniu do zarządzania projektami.

Mój szef, jedyny autorytet w repozytorium pnia, faktycznie odracza wszystkie recenzje gałęzi, aż do momentu, w którym będzie przeprowadzał recenzje na tyle, na ile będzie mógł, niektóre gałęzie zostaną odrzucone w celu ulepszeń / poprawek, niektóre gałęzie połączą się w pień, niektóre zostaną odrzucone z powodu konfliktów itp.

Nierzadko zdarza się, że 10-20 aktywnych oddziałów siedzi w końcowej kolejce przeglądu, aby połączyć je w pień.

Często musimy również rozwiązywać konflikty w końcowym etapie przeglądu i scalania, ponieważ dwie gałęzie zostały utworzone z tego samego łącza, ale zmodyfikowały ten sam fragment kodu. Zwykle tego unikamy, po prostu odgałęziając pień i ponownie stosując nasze zmiany i rozwiązując konflikty, a następnie przekazując nowy oddział do przeglądu (słaba zmiana bazy).

Oto niektóre bezpośrednie pytania:

• Czy przejawiamy bardzo anty-wzorzec, który został opisany jako „scalenie wielkiego wybuchu”?
• Czy niektóre problemy, które widzimy w wyniku tego procesu scalania?
• Jak możemy ulepszyć ten proces łączenia bez zwiększania wąskiego gardła u mojego szefa?

Edycja: Wątpię, aby mój szef poluzował przyczepność do repozytorium pnia lub pozwolił innym deweloperom połączyć się z pniem. Nie jestem pewien, jakie są tego powody, ale tak naprawdę nie planuję poruszać tematu, ponieważ został on poruszony wcześniej i dość szybko zestrzelony. Myślę, że po prostu nam nie ufają, co nie ma sensu, ponieważ wszystko i tak jest śledzone.

Doceniamy każdy inny wgląd w tę sytuację.

Jakieś sugestie:

• Nie ma nic złego w posiadaniu wielu gałęzi funkcji lub poprawek błędów, o ile zmiany dokonane w każdej gałęzi są na tyle małe, że nadal możesz skutecznie radzić sobie z wynikowymi konfliktami scalania. To powinno być twoje kryterium, jeśli twój sposób pracy jest w porządku, a nie jakiś artykuł MSDN.

• Ilekroć gałąź jest łączona w pień, pień powinien być jak najszybciej łączony ze wszystkimi otwartymi gałęziami programistycznymi. Pozwoliłoby to wszystkim osobom w zespole na równoległe rozwiązywanie konfliktów scalania w ich własnym oddziale, a więc odciąży strażnika bagażnika.

• Działałoby to znacznie lepiej, gdyby strażnik nie czekał, aż 10 gałęzi będzie „gotowych do połączenia w pień” - rozwiązywanie konfliktów scalania z ostatnich integracji pnia zawsze potrzebuje trochę czasu dla zespołu, więc prawdopodobnie lepiej jest pracować w przeplatanych odstępach czasu - jedna integracja przez strażnika, jedno ponowne połączenie przez zespół, następnie integracja przez strażnika, następne ponowne połączenie przez zespół i tak dalej.

• Aby gałęzie były małe, pomocne może być podzielenie większych elementów na kilka mniejszych zadań i rozwinięcie każdego z nich we własną gałąź. Jeśli operacja nie jest gotowa do produkcji, dopóki nie zostaną zaimplementowane wszystkie podzadania, ukryj ją przed produkcją za przełącznikiem operacji, aż wszystkie podzadania zostaną ukończone.

• Wcześniej czy później napotkasz zadania refaktoryzacji, które wpływają na wiele plików w bazie kodu - wiążą się one z dużym ryzykiem spowodowania wielu konfliktów scalania z wieloma gałęziami. Najlepiej sobie z nimi poradzić, komunikując je wyraźnie w zespole, i upewnij się, że postępujesz dokładnie tak, jak napisałem powyżej: integrując je najpierw we wszystkich gałęziach programistów przed reintegracją i dzieląc je na mniejsze subfaktoryzacje.

• Przy obecnym rozmiarze drużyny posiadanie jednego strażnika może nadal działać. Ale jeśli twój zespół powiększy się, nie ma innej możliwości, aby mieć drugiego strażnika (lub więcej). Uwaga: Nie sugeruję, aby pozwolić wszystkim połączyć się w bagażnik, ale to nie znaczy, że tylko twój szef jest w stanie to zrobić. Prawdopodobnie jest też jeden lub dwóch starszych deweloperów, którzy mogą być kandydatami do wykonywania pracy strażnika. I nawet dla obecnej wielkości drużyny drugi strażnik może ułatwić twojej drużynie integrację z bagażnikiem częściej i wcześniej, lub gdy twój szef nie jest dostępny.

Czy przejawiamy bardzo anty-wzorzec, który został opisany jako „scalenie wielkiego wybuchu”?

Brzmi jak to.

Czy niektóre problemy, które widzimy w wyniku tego procesu scalania?

Zdecydowanie

Jak możemy ulepszyć ten proces łączenia bez zwiększania wąskiego gardła u mojego szefa?

W mojej firmie każdy deweloper ma możliwość połączenia. Przypisujemy żądanie scalenia innemu twórcy, przechodzimy przez cykl recenzji / opinii / aktualizacji, aż obie strony będą zadowolone. Następnie recenzent scala kod.

10-20 oddziałów oczekujących na połączenie to znak, że Twój proces jest wadliwy. Gdybyśmy mieli ich tyle, cała praca deweloperów zostałaby zatrzymana, dopóki nie zostanie wyjaśniona.

Zasadniczo tak działa wiele projektów typu open source, w tym zwłaszcza jądro Linuksa, które ma o wiele więcej gałęzi w locie niż ty w danym momencie. Typowym sposobem uniknięcia łączenia Big Bang w tych projektach jest utworzenie kolejnej gałęzi (lub wielu gałęzi) w celu ciągłej integracji. Jest to gałąź, której używasz, aby upewnić się, że zmiany współpracują z kolegami, i co pewien czas zmienia się w bagażnik, gdy strażnik zabiera się do robienia recenzji.

Opcjonalnie możesz użyć tej gałęzi, aby połączyć kilka własnych żądań ściągnięcia w jedną dużą spójną prośbę do sprawdzenia przez szefa. Linus Torvalds zazwyczaj otrzymuje żądania ściągania, które zostały zintegrowane na głębokości dwóch lub więcej poziomów i mogą mieć rozmiar rzędu, na przykład, kompletnego nowego sterownika systemu plików.

Zgadzam się z obydwoma Doktorem Brownem, ale widzę też inny antypattern

Mój szef, jedyny autorytet w repozytorium pnia , faktycznie odracza wszystkie recenzje gałęzi, aż do momentu, w którym będzie przeprowadzał recenzje na tyle, na ile będzie mógł, niektóre gałęzie zostaną odrzucone w celu ulepszeń / poprawek, niektóre gałęzie połączą się w pień, niektóre zostaną odrzucone z powodu konfliktów itp.

W mojej skromności są pewne antypatie zarządcze:

1. Jest on pojedynczym dławikiem ograniczającym prędkość zespołu. Twój współczynnik autobusowy wynosi 1. Teoria ograniczeń mówi, że powinieneś wkładać wysiłek w poprawę najwolniejszej części łańcucha.
2. Twój menedżer spowalnia cykl przekazywania informacji zwrotnych i zmniejsza sprawność zespołu. Czy możesz wypuszczać co tydzień?
3. Złożoność scalania rośnie wykładniczo wraz z ilością kodu. Lepiej jest wykonać 10 połączeń ze 100 liniami niż 1 z 1000 linii. To tylko jeden z powodów, dla których powinieneś to zrobić jak najszybciej
4. Jeśli wykryjesz awarię w bagażniku, zrobisz to później. Która z kilku gałęzi była problematyczna
5. Decyzje powinny podejmować ci, którzy mają więcej wiedzy na ich temat. Kto wie więcej w tym przypadku? Założę się, że programiści, którzy stworzyli kod.
6. Nie możesz naprawić błędu w produkcji, jeśli twój menedżer jest w święta.
7. Ponawiasz pracę i odrzucasz gałęzie. To strata czasu. Czas oczekiwania na produkcję to także marnotrawstwo.

Rekomendacje:

• Twój menedżer musi przekazać odpowiedzialność zespołowi. Musisz pokazać, że zespół jest dojrzały, profesjonalny. Wyjaśnij, że mogą zaufać zespołowi
• Wdróż jakąś metodę przeglądu. Być może potrzebujesz aprobaty dwóch innych członków zespołu.
• Być może używanie SVN utrudnia. Spróbuj Git i sprawdź, czy ci to pomoże. Nawet więcej. Jeśli korzystasz z GitHub, możesz użyć mechanizmu Pull Request, aby scalenie wymagało określonych głosów.
• Czytaj i dziel się informacjami na temat zwinnych praktyk, ciągłej integracji i DevOps.

Podczas pracy nad funkcjami w oddzielnych gałęziach nie można łatwo wykonać żadnych testów integracji, dopóki jedna z gałęzi nie zostanie połączona z pniem i wciągnięta do innych gałęzi funkcji. Z mojego doświadczenia wynika, że ​​jest to główny problem z anty-wzorem Big Bang Merge. Idealnie byłoby wykonać operację elementu, przetestować go w gałęzi funkcji, scalić w pień iw tym momencie operacja jest zakończona. Jeśli nie został scalony, musisz ponownie go odwiedzić za każdym razem, gdy coś innego zostanie scalone w pień przed nim. Ból tego anty-wzorca polega na tym, że pod koniec cyklu programowania pojawia się wiele błędów typu integracyjnego.

Masz więc 20 oddziałów. Oddział 1 został właśnie scalony. Następnie twórca oddziału 2 musi scalić oddział 1 w swój oddział, aby móc połączyć się w główny bez konfliktu, a następnie łączy się. Następnie twórca oddziału 3 musi scalić oddział 1 i oddział 2 w swój oddział, aby móc połączyć się w główny bez konfliktu, a następnie łączy się.

Ćwiczenie dla czytelnika: Napisz program, który wydrukuje mój cały post :-)

To szaleństwo. Spędzisz niesamowitą ilość czasu łącząc się.

Biorąc pod uwagę sposób, w jaki pracujesz i że twój szef jest odpowiedzialnym maniakiem kontroli, sam problem wydaje się stanowić rozgałęzienie. Zamiast tworzyć gałąź dla każdej funkcji, poproś każdego programistę, aby zatwierdził swoją funkcję w częściach, bezpośrednio do linii głównej. Nakłada to ciężar integracji na programistę na wiele mniejszych kroków (win-win). Bramkarz może nadążać za śledzeniem mniejszych zmian w dłuższym okresie wcześniej w cyklu rozwoju i nadal być głównym recenzentem.

Samo rozgałęzienie jest czymś, czego nie chcesz robić, chyba że masz ku temu dobry powód lub nie masz innej możliwości. Jesteś na tyle mały, aby ściślej synchronizować rzeczy, co będzie łatwiejsze i bezpieczniejsze.