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

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?

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”

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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