Czy DVCSes zniechęcają do ciągłej integracji?

34

Powiedzmy, że jest zespół dziesięciu zwinnych programistów. Każdego dnia wybierają zadanie z planszy, popełniają kilka zmian w stosunku do niego, dopóki (do końca dnia) nie ukończą zadania. Wszyscy programiści meldują się bezpośrednio w stosunku do pnia (w stylu Google, każde zatwierdzenie jest kandydatem do wydania, za pomocą przełączników funkcji itp.).

Jeśli korzystali ze scentralizowanego CVS, takiego jak SVN, za każdym razem, gdy jeden z nich się zgodzi, serwer kompilacji zintegruje się i przetestuje zmiany pod kątem pracy pozostałych dziewięciu programistów. Serwer kompilacji będzie działał nieprzerwanie przez cały dzień.

Ale jeśli używali DCVS, takiego jak git, programista może poczekać, aż ukończą zadanie, zanim przekażą wszystkie swoje lokalne zatwierdzenia do centralnego repozytorium. Ich zmiany nie zostaną zintegrowane do końca dnia.

W tym scenariuszu zespół SVN integruje się coraz częściej i odkrywa problemy z integracją znacznie szybciej niż zespół git.

Czy to oznacza, że ​​DVCS są mniej odpowiednie dla ciągłych zespołów niż starsze scentralizowane narzędzia? Jak radzicie sobie z tym problemem odroczenia wypychania?

Richard Dingwall
źródło
15
Czy ludzie zobowiązują się przynajmniej raz przed wykonaniem zadania przy użyciu SVN? I czy ludzie będą naciskać tylko raz dziennie podczas korzystania z DVCS? Twoje rozumowanie zakłada, że ​​żadne z nich nie jest prawdziwe, ale moje wrażenie wskazuje inaczej.
3
Bardzo dobre pytanie.
Michael Brown
1
@delnan: załóżmy, że obie drużyny popełnią kilka razy dziennie, ale faceci z git popychają te commity tylko po zakończeniu zadania.
Richard Dingwall
2
Myślę, że patrzysz na niewłaściwy koniec potoku, masz problemy, nie jeśli nie pchasz do ukończenia, ale jeśli nie ciągniesz regularnie podczas
programowania
2
Widziałem coś przeciwnego: programiści używający scentralizowanego systemu kontroli źródła, takiego jak TFS, rzadko zatwierdzają, ponieważ ich kod wpływa na wszystkich, gdy to robią. W końcu tymczasowo zapisują swoją pracę na półkach z potworami, a kiedy są skończone, wszystko idzie w jednym potworze.
Kyralessa

Odpowiedzi:

26

Uwaga: Pracuję dla Atlassian

DVCS nie zniechęca do ciągłej integracji, o ile programista regularnie wypycha zdalnie swoje własne oddziały, a serwer CI jest skonfigurowany tak, aby budował znane aktywne gałęzie.

Tradycyjnie istnieją dwa problemy z DVCS i CI:

  • Niepewność stanu integracji - chyba że programista regularnie łączy się z systemem głównym i uruchamia kompilację, nie wiesz, jaki jest stan połączonych zmian. Jeśli programista musi to zrobić ręcznie, są szanse, że nie będzie to wystarczająco częste, aby odpowiednio wcześnie wychwycić problemy.
  • Powielanie i dryfowanie konfiguracji kompilacji - jeśli konfiguracja kompilacji musi zostać skopiowana z kompilacji „master”, aby utworzyć kompilację oddziału, konfiguracja oddziału może szybko przestać być zsynchronizowana z kompilacją, z której została skopiowana.

W Bamboo wprowadziliśmy możliwość wykrywania przez serwer kompilacji nowych gałęzi podczas ich tworzenia przez programistów i automatycznego konfigurowania kompilacji dla gałęzi w oparciu o konfigurację kompilacji dla master (więc jeśli zmienisz konfigurację kompilacji master, zmieni również konfigurację gałęzi aby odzwierciedlić zmianę).

Mamy również funkcję o nazwie Strategie scalania, której można użyć do zaktualizowania gałęzi ze zmianami od wzorca przed uruchomieniem kompilacji oddziału lub automatycznego wypchnięcia zmian w udanej gałęzi od kompilacji do wzorca, dzięki czemu zmiany między oddziałami są testowane razem jak najszybciej .

W każdym razie, jeśli chcesz dowiedzieć się więcej, zapoznaj się z moim postem na blogu „Zwiększanie skuteczności gałęzi funkcji dzięki ciągłej integracji”

jdumay
źródło
14

Mój mały zespół przeszedł na DVCS rok lub dwa lata temu, a reszta mojej firmy poszła w ich ślady kilka miesięcy temu. Z mojego doświadczenia:

  • Ludzie używający scentralizowanego systemu VCS nadal wstrzymują się od zatwierdzania zleceń, gdy wykonują duży projekt. To nie jest problem unikalny dla DVCSes. Będą mieli zestawy zmian, które czekają kilka dni przed zatwierdzeniem. Duża różnica polega na tym, że jeśli w tym czasie popełnią błąd lub komputer ulegnie awarii, jego naprawienie wymaga znacznie więcej wysiłku.
  • Używamy przepływu pracy zatwierdzania, w którym każdy programista pracuje we własnym, nazwanym oddziale, a tylko osoba, która dokonała przeglądu swojego kodu, może scalić swoje zmiany w głowie. Zmniejsza to prawdopodobieństwo problemów powodujących zatwierdzenie, więc ludzie naprawdę zwracają uwagę, gdy serwer kompilacji wyświetla komunikat o błędzie. Oznacza to również, że inni programiści mogą kontynuować pracę nad własnymi gałęziami, dopóki głowa nie zostanie naprawiona.
  • Na DVCS ludzie spędzają więcej czasu na programowaniu, zanim scalą swój kod z głową. Więc zwykle wprowadza niewielkie opóźnienie w ciągłości kompilacji. Różnica nie jest jednak wystarczająco znacząca, aby zrównoważyć zalety DVCS.
StriplingWarrior
źródło
Serwer kompilacji buduje wszystkie nazwane gałęzie, więc każdy podmiot odpowiedzialny ma własne zadanie budowania serwera?
Czy recenzent kodu nie staje się poważnym wąskim gardłem w tym scenariuszu?
Andres F.,
@ ThorbjørnRavnAndersen: Nie, serwer kompilacji buduje tylko gałąź „head” lub „default”, a gałęzie wydania. Aby każdy użytkownik mógł przypisać swoją własną gałąź bez obawy, że przerwie kompilację. Możliwe, że możemy skonfigurować serwer kompilacji do budowania gałęzi wszystkich, ale w niektórych przypadkach chcę wykonać trochę pracy, którą wykonałem, wiedząc doskonale, że to powoduje, że moja gałąź nie nadaje się do użytku. Przed sprawdzeniem kodu i scaleniem upewnię się, że mój oddział jest stabilny. Obchodzi mnie tylko to, że główne gałęzie, z których wszyscy korzystają, są stabilne.
StriplingWarrior
@AndresF .: Nie, nie stało się to dla nas poważnym wąskim gardłem. Po pierwsze, mamy wiele osób, które mogą dokonywać recenzji kodu, więc każdy programista zwykle może znaleźć co najmniej jednego recenzenta, który jest dostępny do recenzji w danym momencie. Poza tym częścią piękna DVCS jest to, że nawet jeśli nie możesz od razu połączyć, możesz zacząć pracować nad czymś innym, a inni programiści mogą scalić twoje zmiany w swoich gałęziach, jeśli zależą od twoich zmian w ich pracy. Po sprawdzeniu kodu istnieje określony węzeł zestawu zmian, w którym recenzent może się połączyć.
StriplingWarrior
13

Niedawno zauważyłem w około 19 projektach wykorzystujących Mercurial zamiast SubVersion (byłem maniakiem subversion ): programiści zaczęli stawać się naprawdę indywidualistami, pracując nad własnym oddziałem i integrując się dopiero po kilku dniach lub tygodniach. Spowodowało to poważne problemy i obawy związane z integracją.

Innym problemem, z jakim się spotkaliśmy, jest serwer ciągłej integracji. Zostaliśmy powiadomieni o problemach (na przykład test zakończony niepowodzeniem) tylko wtedy, gdy dokonano synchronizacji zatwierdzeń na serwerze.

Wygląda na to, że Martin Fowler napisał o tym na swojej stronie.

To powiedziawszy, niektóre z projektów, o których wspomniałem, synchronizowały przynajmniej raz dziennie, zmniejszając problemy. Odpowiadając na twoje pytanie, uważam, że DVCS może zniechęcać do ciągłej integracji i zwiększać indywidualizm. Jednak DVCS nie jest bezpośrednią przyczyną.

Deweloper jest nadal odpowiedzialny, niezależnie od używanego VCS.

Społeczność
źródło
Czy wspomniane projekty kładły nacisk na wspólny cel, czy też programiści musieli pracować nad konkretnymi, niepowiązanymi celami?
Nie możemy generalizować na 19 projektach. Ale gdy napotkaliśmy problemy z integracją, dzieje się tak również dlatego, że nie przestrzegano niektórych zasad, takich jak rozdzielenie obaw. Mówię, że tak, DVCS wydaje się sprzyjać indywidualizmowi i zmniejszać korzyści ciągłej integracji, ale jeśli programiści są dobrze wyszkoleni, możliwe jest zmniejszenie lub wyeliminowanie problemu.
W takim przypadku sugerowałbym również dostawę ciągłą lub przynajmniej częste dostawy dla klientów, więc termin, w którym MUSI się zdarzyć, jest znacznie krótszy. Czy zrobiłeś to w tych projektach?
Oczywiście używamy Scruma
1
Szukałem swojej definicji ciągłej dostawy (wciąż nie może znaleźć coś przyzwoitego, będę wdzięczny, jeśli możesz dać mi jakieś referencje), i znalazłem to: continuousdelivery.com/2011/07/...
10

Pomysł, na którym opierasz swoje rozumowanie, jest bardzo chwiejny, delikatnie mówiąc. Jest to kwestia zespołu / zarządzania / procesu, że programista może poczekać, aż zakończy zadanie .

Robiąc to w ten czy inny sposób, „czekaj” lub „śpiesz się”, wspólny pień lub izolowana gałąź, jest znany jako strategia rozgałęziania , a jeśli przestudiujesz informacje dostępne w Internecie , przekonasz się, że wybór konkretnej strategii nie ma w zasadzie nic wspólnego z VCS jest scentralizowany lub dystrybuowany.

Powiedzmy, że w przypadku rozproszonych VCS, takich jak Mercurial, możesz łatwo znaleźć silną rekomendację do częstych fuzji :

Po pierwsze, łącz często! To sprawia, że ​​scalanie jest łatwiejsze dla wszystkich, a wcześniej dowiadujesz się o konfliktach (które często są zakorzenione w niezgodnych decyzjach projektowych) ...

Studiując powyższe rekomendacje, łatwo można stwierdzić, że odwołują się do rozważań, które nie mają nic wspólnego z dystrybucją Mercurial.

Teraz spójrzmy na sytuację po stronie scentralizowanego VSC, Subversion. Studiując informacje online, można znaleźć wśród najpopularniejszych strategii tzw. Stabilny i niestabilny łącznik - każda z nich ma przeciwny wpływ na częstotliwość łączenia. Widzicie, ludzie wybierają jeden lub inny sposób robienia rzeczy, nawet nie zwracając uwagi na scentralizowanie VCS.

  • Widziałem, jak doszło do poważnie opóźnionych połączeń (nawet zachęcanych przez kiepskie zarządzanie) ze scentralizowanym VCS, a także częstych połączeń wykonywanych za pomocą DVCS, gdy zespół / kierownictwo po prostu uważało, że to właściwa droga. Widziałem, że nikogo nie obchodzi, czy VCS jest dystrybuowane lub scentralizowane w podejmowaniu decyzji w taki czy inny sposób.

Biorąc pod uwagę powyższe, wygląda na to, że odpowiednia odpowiedź na pytanie Czy DVCS zniechęcają do ciągłej integracji? byłby Mu .

Dystrybucja VCS lub nie ma na to znaczącego wpływu.

komar
źródło
1
+1 Zgadzam się z tobą, że zarządzanie jest kluczem do rozwiązania problemu. Musimy jednak przyznać, że w DVCS jest coś, co zniechęca do ciągłej integracji. W rzeczywistości jedna z kluczowych funkcji DCVS zachęca do takiego zachowania.
1
@ Pierre303 może - ja też tak się czuję, ale to właściwie teoria. Jak pisałem, widziałem, jak zespół jak szalenie integruje się z DVCS, az drugiej strony najbardziej „izolacjonistyczny” projekt, w jakim kiedykolwiek pracowałem (i to był koszmar), miał scentralizowany VCS. Tyle o uczuciach, tyle o teorii ...
mam
Przyznaję, że jest to tylko obserwacja empiryczna, ale przy dużej liczbie projektów, i prawdopodobnie wiąże się to z dużym błędem „umiejętności”.
10

Moje doświadczenie jest dokładnie odwrotne : zespoły używające svn nie naciskałyby na wiele dni, ponieważ kod, nad którym pracowali, spowodowałby, że pnia nie skompilowałaby się dla wszystkich innych bez marnowania czasu na ręczne łączenie. Potem, pod koniec sprintu, wszyscy popełniliby, łączące się szaleństwo miałoby miejsce, rzeczy byłyby nadpisywane, gubiły się i musiały zostać odzyskane. System CI przejdzie na CZERWONY i nastąpi wskazanie palcem.

Nigdy nie miałem tego problemu z Git / Gitorious.

Git pozwala ci wyciągać i scalać zmiany innych ludzi dla twojej wygody, nie dlatego, że ktoś inny coś sprawdził i chcesz się zalogować, ale masz 20 minut ręcznego łączenia.

Git pozwala także ściągać zobowiązania wszystkich innych, scalać swój kod, a następnie przekazywać działającą wersję wszystkim innym, aby nie musieli zgadywać, co powinni scalić na podstawie tego, co zmieniliście.

Posiadanie czegoś w rodzaju Gitorious jako mediatora dla przeglądów kodu za pośrednictwem żądań scalania sprawia, że ​​zarządzanie wieloma oddziałami i wieloma współpracownikami jest bardzo bezbolesne.

Konfigurowanie Jenkins / Hudson do śledzenia wszystkich aktywnych gałęzi w repozytorium Git jest również bardzo łatwe. Po przejściu do Git z SVN uzyskaliśmy większą przyczepność dzięki CI i częstsze opinie na temat stanu repozytoriów.


źródło
dlaczego mieliby bezpośrednio zaangażować się w bagażnik? Myślę, że to był twój problem.
gbjbaanb
1
@ gbjbaanb, ponieważ jest to tradycyjny idiomatyczny sposób działania CVS, ponieważ jest to tradycyjny scentralizowany idiom repo. Użytkownicy SVN są zwykle byłymi użytkownikami CVS, a rozgałęzianie i łączenie w SVN jest tylko nieznacznie lepsze niż w CVS; co było bardziej bolesne / prawie niemożliwe do poprawienia. Jest to 99% przypadek przepływu pracy w 99% wszystkich sklepów SVN z powodu narzędzi i opinii grupy.
@JarrodRoberson: nonsens. Moi starzy użytkownicy SVN byli uchodźcami z VSS :) Scalanie w SVN nie jest tak złe, jak myślisz. W tym przypadku skarży się, że jego użytkownicy zepsują kompilację, sprawdzając uszkodzony kod bezpośrednio do pnia - a następnie, mówiąc szczerze, konieczność scalenia kodu z kodem współpracownika nie jest opcjonalna, jeśli wszyscy pracują bezpośrednio ten sam oddział.
gbjbaanb
4

Budowanie serwerów jest tanie. Poproś serwer CI o wybranie wszystkich gałęzi, które znasz.

Jenkins ma wsparcie, aby sprawdzić wiele repozytoriów git i uzyskać „najnowsze” od jednego z tych w jednym zadaniu. Jestem pewien, że istnieją podobne rozwiązania z innymi narzędziami.

ptyx
źródło
Co się stanie, jeśli chcesz popełnić coś, co psuje się, headale pomaga współpracownikowi lub jest wymagane, aby kolega mógł Ci pomóc? Możesz utworzyć plik różnicowy i wysłać go e-mailem do swojego kolegi, ale jakoś to nie wydaje się właściwe.
Arjan
1
Zespół / funkcja? A może pobierasz bezpośrednio z repozytorium współpracowników? Jeśli więcej niż jedna osoba pracuje nad czymś, co złamałoby głowę, ale nadal wymaga zatwierdzenia na osi czasu / zatwierdzenia wieloetapowego, i tak zasługuje na swoją funkcję / gałąź pracy. Połącz się, gdy będzie gotowy.
ptyx
Oddział zespołowy gałęzi funkcji nie będzie działał, jeśli narzędzie CI zbierze wszystkie znane gałęzie. A jeśli narzędzie CI przetwarza również wiele repozytoriów, nadal nie chcesz uwzględniać repozytoriów programistów, tylko dlatego, że mogły one nie zostać w pełni przetestowane.
Arjan
1
Serwer CI nie będzie automatycznie wiedział o oddziale prywatnym, dopóki nie zostanie o tym poinformowany. Osoby mogą wybrać, czy chcą mieć swoje oddziały w CI, czy nie. (Nie ma cudownego rozwiązania)
ptyx
Dlatego CI nie powinien odbierać wszystkich gałęzi, o których wiesz, ale tylko te, które chcesz w CI. Dla mnie to różnica. Myślę jednak, że rozumiem, co próbujesz powiedzieć, więc +1
Arjan
4

To stare pytanie właśnie zostało oznaczone jako duplikat nowego, a ponieważ wiele odpowiedzi odnosi się do niektórych przestarzałych pomysłów, pomyślałem, że opublikuję zaktualizowane.

Jedną z rzeczy, która najwyraźniej pięć lat temu nie była zbyt powszechna, było przeprowadzenie testów CI na gałęziach żądania ściągania przed scaleniem ich w master. Myślę, że odzwierciedla to zmieniające się podejście, które choć często się łączy, jest pożądane, dzielenie się każdą zmianą ze wszystkimi , gdy tylko ją wprowadzisz , nie jest optymalne.

DVCS stworzył bardziej hierarchiczny tryb integracji twoich zobowiązań. Na przykład często bardzo ściśle współpracuję z programistą, który siedzi obok mnie. Będziemy wyciągać się ze swoich oddziałów kilka razy dziennie. Dzisiaj współpracowaliśmy z innym programistą za pomocą zmian wprowadzanych do żądania ściągania co kilka godzin.

Wprowadziliśmy rozległe zmiany w skryptach kompilacji. Jenkins lokalnie łączy każdą gałąź PR z master i przeprowadza testy, dzięki czemu otrzymaliśmy w ten sposób zautomatyzowane informacje zwrotne, nie przeszkadzając żadnemu innemu programistowi, który potrzebował czystej wersji. Prawdopodobnie minie jeszcze jakiś dzień, zanim PR będzie gotowy do połączenia w celu opanowania i udostępniania poza naszą grupą trzech programistów.

Jeśli jednak ktoś nie może się doczekać, aż nasze zmiany zostaną scalone, ponieważ ich zmiana zależy od naszej, może lokalnie połączyć naszą gałąź programistów i kontynuować pracę. Tego brakuje wielu osobom przyzwyczajonym do CVCS. W przypadku CVCS jedynym sposobem na udostępnienie zmian jest połączenie ich w centralne repozytorium i dlatego często łączenie jest bardziej krytyczne. Z DVCS masz inne opcje.

Karl Bielefeldt
źródło
3

Powiedziałbym, że DVCS bardziej sprzyja ciągłej integracji. Połączenia nie są tak irytujące. Wymaga to jednak większej dyscypliny. Powinieneś podążać za lokalnym zatwierdzeniem z pociągnięciem od bazy, aby połączyć, a następnie pchnąć, gdy zadanie jest ukończone (przed przejściem do następnego).

Michael Brown
źródło
2

Kiedy mój zespół przeszedł na Git, wyraźnie ustaliliśmy, że wypychanie powinno być traktowane dokładnie jak zatwierdzenie w starszym VCS, a lokalne zatwierdzenia mogą być wykonywane tak często / rzadko, jak każdy z osobna. Dzięki temu nie ma różnicy w systemie CI, czy korzystamy z DVCS czy scentralizowanego VCS.

Dan Lyons
źródło
1

Odpowiedź brzmi: tak i nie.

Różnica polega na tym, czy zatwierdzić bezpośrednio centralne repozytorium CI i pchnąć zmiany do centralnego repozytorium CI. „Problem”, jaki możesz znaleźć, polega na tym, że użytkownicy DVCS mogą nie wykonywać tego pushu regularnie.

Powiedziałbym, że jest to nieodłączna cecha DVCS, nie ma na celu ciągłego przekazywania zmian do serwera centralnego - gdyby tak było, równie dobrze można użyć CVCS. Odpowiedzią jest więc wymuszenie lepszego przepływu pracy między programistami. Powiedz im, aby wprowadzali zmiany każdej nocy. Simples!

(a jeśli Twoi użytkownicy SVN nie zobowiązują się co noc, powiedz im, że to dokładnie ten sam problem).

gbjbaanb
źródło
0

Git nie zapobiega ciągłej integracji. Twój przepływ pracy oparty na tułowiu to.

Może się to wydawać sprzeczne z intuicją, ale: jeśli programiści pracują nad gałęziami funkcji, można ich zachęcić do częstej integracji na własnych komputerach (i jest to wymagane przed przesłaniem funkcji do scalenia). Z kolei przepływ pracy oparty na magistrali faworyzuje większe zatwierdzenia, a zatem rzadszą integrację.

Twierdzę, że oparty na Google przepływ pracy jest nieproduktywny w przypadku VCS, takich jak Git, w którym scalanie jest łatwe. Oto, co radziłbym zamiast tego:

  • Rozbij funkcje na tyle małe, że ich opracowanie nie zajmie więcej niż dzień lub dwa.
  • Każda funkcja jest rozwijana w oddziale prywatnym.
  • Deweloper często integruje się z oddziałem prywatnym ( git fetch origin; git merge master). Zwykle robię to wiele razy dziennie, kiedy pracuję w ten sposób.
  • Gdy programista przesyła oddział do scalenia i przeglądu, serwer CI wykonuje automatyczną kompilację. Scalanie odbywa się tylko wtedy, gdy to minie.

A więc masz: małe zmiany, częsta integracja i identyfikowalna historia tego, które zmiany należą do której funkcji. Gałęzie, właściwie użyte, są kluczem do wszystkiego, co jest warte w Git, więc unikanie ich jest dużym błędem.

Marnen Laibow-Koser
źródło
-1

Wspominamy o świetnych rozwiązaniach technicznych, takich jak @jdunay, ale dla nas jest to problem ludzi - podobnie jak sprzyjanie środowisku, w którym ludzie często angażują się w svn, jest problemem ludzi.

Pracowało dla nas: (zastąp „master” aktualnie aktywną gałęzią programistów)

  1. Częste łączenia / rebases z mastera
  2. Wystarczająco często popycha do opanowania
  3. Świadomość rzeczy, które powodują scalanie piekła, takich jak pewne refaktoryzacje i łagodzenie tego poprzez komunikację. Na przykład:

    • Upewnij się, że wszyscy pchają przed obiadem
    • Wykonaj i popchnij refaktoryzację podczas lunchu
    • Upewnij się, że wszyscy ciągną po obiedzie
orip
źródło