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

28

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ę.

— użytkownik6567423
źródło

2

Dlaczego scalanie jest odroczone? Zwykle istnieje powód, aby nie robić tego natychmiast. czy singiel jest przepracowany, a zaległości stają się tak duże? czy jest jakiś inny powód, dla którego scalanie nie odbywa się na czas?

— Polygnome

1

Kilka razy byłem w podobnej sytuacji jak ty. Mogę powiedzieć z własnego doświadczenia, że wiele firm kontroluje wersje, szczególnie rozgałęzienia, strasznie źle.

— MechMK1

3

Co się dzieje, gdy szef jedzie na wakacje?

— Liath

Jak zdefiniowałbyś strategię rozgałęziania / scalania jądra Linuxa?

— Braiam

Czy zmiany, które zostały odrzucone z powodu konfliktów, ale nie inne wady, muszą przejść ponownie proces zatwierdzania po rozwiązaniu konfliktów, czy też są uważane za „tymczasowo zatwierdzone”?

— Gregory Nisbet

60

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.

— Doktor Brown
źródło

2

Myślę, że masz tutaj najlepszy komentarz, przyznając, że nie możemy po prostu otworzyć pnia dla wszystkich i że nasz stos gałęzi nie zawsze jest problemem (tylko wtedy, gdy są w konflikcie). Myślę, że dobrze wykonałeś pracę, wskazując, w jaki sposób możemy zmniejszyć konflikty i zapewnić płynność cyklu scalania. Myślę również, że masz całkowitą rację, gdy mówisz, że potrzebujemy innego strażnika. Wielkie dzięki za ten wgląd!

— user6567423

@ user6567423 Inną rzeczą, którą warto rozważyć, jest utworzenie gałęzi dla każdej wersji programistycznej (np. 5.2.3 lub innej), którą każdy programista może rozgałęzić w celu pracy nad funkcjami, a następnie scalić, a następnie połączyć z powrotem w główną zwolnij gałąź szefa po zakończeniu programowania.

— nick012000

@ nick012000: czy ta sugestia nie utrudni strażnikowi akceptacji lub odrzucenia poszczególnych gałęzi cech za / przeciw integracji z bagażnikiem? Chodzi mi o to, że jeśli kilka funkcji zostanie pomieszanych w jednej gałęzi programistycznej, ponowne zintegrowanie tych zmian częściowo w pniu byłoby naprawdę trudne. A może coś mi brakuje?

— Doc Brown

10

„ rozwiązuj konflikty scalania równolegle w ich własnej gałęzi, a więc weź trochę obciążenia od strażnika pnia. ” - Czuję, że ta część została niesprawiedliwie zredukowana do nuty bocznej. „Lepiej dla firmy, ALE TAKŻE dla ciebie łatwiej ” wydaje się głównym punktem sprzedaży, gdy sugerujesz to szefowi. To idzie bardziej w kierunku polityki biurowej, o której nie chodzi w SE - ale w tej sytuacji, bez wpisu od szefa, wszystko inne w tej technicznie doskonałej odpowiedzi po prostu się nie wydarzy.

— R. Schmitz

@DocBrown Tak, to by oznaczało, ale oznaczałoby to również, że miałbyś o wiele mniej konfliktów między gałęziami deweloperów i nadal dawałby ci to poziom bezpieczeństwa, jaki nie daje bezpośrednie połączenie z główną gałęzią - i może po prostu nie akceptuj pracy jako Gotowej i wykonaj scalanie, dopóki nie będzie zadowolony ze stanu kodu jako całości.

— nick012000

18

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.

— Mateusz
źródło

1

Nie takiej odpowiedzi szukałem, ponieważ wątpię, by mój szef poluzował przyczepność do repozytorium pnia. Niemniej jednak niezwykle pomocna odpowiedź, dzięki za wgląd!

— user6567423

5

@ user6567423: Jeśli twój szef stanie się wąskim gardłem, które jest teraz zgodnie z twoim opisem, będzie musiał albo zmienić swoje podejście, albo zaakceptować fakt, że jest przyczyną opóźnień (za które jego pracowników nie można winić). Odmowa zmiany podejścia, ignorowanie tworzonych problemów i zrzucanie winy na innych nie jest sposobem na prowadzenie firmy.

— Flater

1

Zgadza się, że jest wąskim gardłem i z pewnością nie obwinia za to innych. Ale tak, szukałem wskazówek, które mogą nie być oczywiste, które mogłyby zmniejszyć nasze wąskie gardło. Dzięki za wgląd

— użytkownik6567423

1

@ user6567423 Jestem ciekawy, czy kiedykolwiek wyjaśnił, dlaczego jest jedynym, który może połączyć się z pniem.

— Matthew

13

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.

— Karl Bielefeldt
źródło

Dzięki, myślę, że porady dotyczące łączenia gałęzi i zapobiegania konfliktom będą prawdopodobnie naszym najlepszym sposobem działania.

— user6567423

8

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:

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.
Twój menedżer spowalnia cykl przekazywania informacji zwrotnych i zmniejsza sprawność zespołu. Czy możesz wypuszczać co tydzień?
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
Jeśli wykryjesz awarię w bagażniku, zrobisz to później. Która z kilku gałęzi była problematyczna
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.
Nie możesz naprawić błędu w produkcji, jeśli twój menedżer jest w święta.
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.

— Borjab
źródło

7

Pracowałem profesjonalnie zarówno z SVN, jak i git, i powiedziałbym, że SVN jest zdecydowanie częścią problemu: wymusza politykę pojedynczego łączenia z powrotem zatwierdzania dla oddziałów, które nie są obecne w git. W git wszystkie połączenia są równe, w SVN niektóre są bardziej równe niż inne. Brak lokalnych zatwierdzeń znacznie utrudnia eksperymentowanie z SVN niż z git, a brak strefy przejściowej tylko zwiększa sztywność SVN. Jest powód, dla którego Torvalds nie używał SVN zamiast rozwijać git ...

— cmaster

Git jest o wiele lepszy niż svn moim zdaniem z powodów określonych w @cmaster i więcej

— reggaeguitar

Zgadzam się, że git prawdopodobnie rozwiązałby niektóre z naszych problemów łączących się, a mój Boże, chciałbym mieć dostęp do bazy. Ale nie sądzę, że w najbliższym czasie

— dokonamy

1

@ user6567423, w ubiegłym roku przeprowadziłem konsultację, w której pomogłem niewielkiemu zespołowi przejść z svn na Git i zmienić ich przepływ pracy, w tym przeszkolić ich w Git i skonfigurować je w wersji GitLab Community (która jest open source) do recenzji kodu i współpracy . Byli bardzo entuzjastycznie nastawieni; to była różnica dnia i nocy. (Również zajęło to tylko trzy dni.)

— Wildcard

2

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.

— bmm6o
źródło

1

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ę.

— gnasher729
źródło

Cóż, niekoniecznie, chyba że gałęzie są w konflikcie, może po prostu bez problemu połączyć je wszystkie w pień. Zwykle staramy się zapobiegać konfliktom, przeprowadzając scalenie testowe przed przesłaniem gałęzi do przeglądu, ale konflikty pojawiają się nieuchronnie wraz ze wzrostem liczby gałęzi w kolejce. Zgadzam się, że to brzmi jak szaleństwo.

— user6567423

2

Normalne zachowanie scalania SVN, o ile mogę powiedzieć ...

— cmaster

0

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.

— Martin Maat
źródło

1

Jak poradzisz sobie z wydaniem, jeśli tylko jedna z tych funkcji zawiera błąd lub nie zostanie ukończona na czas? „Samo rozgałęzianie jest czymś, czego nie chcesz robić, chyba że masz bardzo dobry powód” - Gdy masz już 5 osób pracujących nad wieloma funkcjami, musisz skorzystać z rozgałęziania, chyba że masz bardzo dobry powód, aby tego nie robić.

— Ivo van der Veeken

Chodziło o dwie rzeczy: szef chce pozostać jedynym strażnikiem bramy i rzeczy nie powinny się zbytnio różnić. Tak, nadejdzie chwila, w której coś zostało popchnięte, co jeszcze nie zostało zbadane przez szefa. Powinien być w stanie to zrobić szybko, a w mało prawdopodobnym przypadku, gdy musi natychmiast dostarczyć, może cofnąć ostatnie zatwierdzenia. Dzięki temu wszystko będzie zsynchronizowane, a jeśli cokolwiek zawiedzie, z pewnością szybko zawiedzie. Dla mnie wygląda to na dobry kompromis.

— Martin Maat

1

— Uznałbym