Bóle głowy przy użyciu rozproszonej kontroli wersji dla tradycyjnych zespołów?

Chociaż używam i lubię DVCS do moich osobistych projektów i mogę całkowicie zobaczyć, jak to ułatwia zarządzanie wkładami do twojego projektu od innych (np. Twój typowy scenariusz Github), wydaje się, że dla „tradycyjnego” zespołu mogą wystąpić pewne problemy scentralizowane podejście stosowane w rozwiązaniach takich jak TFS, Perforce itp. („tradycyjny” mam na myśli zespół programistów w biurze pracujący nad jednym projektem, którego nikt nie „posiada”, potencjalnie każdy może dotknąć tego samego kodu).

Kilka z tych problemów przewidziałem na własną rękę, ale proszę, zapoznaj się z innymi rozważaniami.

W tradycyjnym systemie, gdy próbujesz sprawdzić swoją zmianę na serwerze, jeśli ktoś wcześniej zarejestrował zmianę będącą w konflikcie, jesteś zmuszony do scalenia, zanim będziesz mógł sprawdzić swoją zmianę. W modelu DVCS każdy programista sprawdza zmienia się lokalnie iw pewnym momencie wypycha do innego repozytorium. To repozytorium ma następnie gałąź tego pliku, którą zmieniły 2 osoby. Wydaje się, że teraz ktoś musi być odpowiedzialny za poradzenie sobie z tą sytuacją. Wyznaczona osoba w zespole może nie mieć wystarczającej wiedzy o całej bazie kodu, aby móc poradzić sobie z scalaniem wszystkich konfliktów. Więc teraz został dodany dodatkowy krok, w którym ktoś musi podejść do jednego z tych programistów, powiedzieć mu, aby pociągnął i wykonał scalenie, a następnie powtórzył (lub musisz zbudować infrastrukturę automatyzującą to zadanie).

Ponadto, ponieważ DVCS sprawia, że ​​praca lokalna jest tak wygodna, jest prawdopodobne, że programiści mogliby zgromadzić kilka zmian w swoich lokalnych repozytoriach przed wypchnięciem, czyniąc takie konflikty bardziej powszechnymi i bardziej skomplikowanymi.

Oczywiście, jeśli wszyscy członkowie zespołu pracują tylko w różnych obszarach kodu, nie stanowi to problemu. Ale ciekawi mnie przypadek, w którym wszyscy pracują nad tym samym kodem. Wydaje się, że model scentralizowany zmusza do szybkiego i częstego rozwiązywania konfliktów, minimalizując potrzebę dokonywania dużych, bolesnych połączeń lub umożliwienia komukolwiek „policyjnego” głównego repozytorium.

Więc dla tych z was, którzy korzystają z DVCS ze swoim zespołem w biurze, jak sobie radzicie z takimi przypadkami? Czy odczuwasz negatywny wpływ na codzienny (lub bardziej prawdopodobny, tygodniowy) przepływ pracy? Czy są jeszcze jakieś względy, o których powinienem wiedzieć przed zaleceniem DVCS w moim miejscu pracy?

Używamy Mercurial od około roku. Chociaż ból głowy, o którym wspominasz, istnieje, największym wyzwaniem dla pełnej adopcji było dla nas podejście DVCS do lokalnych repozytoriów (= częste zatwierdzanie). Stare myślenie „Zatwierdź, gdy już dopracujesz kod” może być trudne do zaakceptowania udać się.

Powiedziałeś:

W modelu DVCS każdy programista sprawdza swoje zmiany lokalnie, a w pewnym momencie przesuwa się do innego repozytorium. To repozytorium ma następnie gałąź tego pliku, którą zmieniły 2 osoby. Wydaje się, że teraz ktoś musi być odpowiedzialny za poradzenie sobie z tą sytuacją.

Domyślna instalacja Mercurial blokuje to zachowanie. Nie pozwoli na push, jeśli więcej niż jedna głowa zostanie utworzona w zdalnym repozytorium, bez dodatkowego potwierdzenia. W codziennych czynnościach tego unikamy. (Git nazwał głowy i każda z nich może zostać zaktualizowana tylko wtedy, gdy całkowicie połączy poprzednią wersję, bez dodatkowego potwierdzenia, więc ponownie nie może się zdarzyć sytuacja. Inne DVCS mają również podobną ochronę.)

Na koniec każdego dnia roboczego należy poświęcić trochę czasu na zatwierdzenie, czyli tak naprawdę te działania:

1. Zatwierdź zmiany lokalne.
2. Wyciągnij z centralnego repozytorium.
3. Scalanie (i zatwierdzanie scalania.)
4. Przejdź do centralnego repozytorium.

Dzięki temu aktywność scalania jest zachowywana przez osobę, która ostatnio pracowała nad tym kodem, i powinna móc integrować swoje zmiany tak szybko, jak wszyscy inni.

Jak wskazano w pytaniu, to naprawdę dodaje wysiłku tylko wtedy, gdy dwie osoby pracują nad tym samym obszarem kodu. Jeśli tak jest, oznacza to, że korzystanie z DVCS i tak jest więcej korzyści, więc wypłata jest już widoczna dla tych programistów. (Dodatkowe korzyści obejmują to, że każdy programista może osobno zatwierdzić kod i grać z własnym repozytorium bez przeszkadzania innemu programistowi).

Kolejny problem, o którym wspominasz:

Ponadto, ponieważ DVCS sprawia, że ​​praca lokalna jest tak wygodna, jest prawdopodobne, że programiści mogliby zgromadzić kilka zmian w swoich lokalnych repozytoriach przed wypchnięciem, czyniąc takie konflikty bardziej powszechnymi i bardziej skomplikowanymi.

Nie tworzy to dla nas problemu scalania, ale może stworzyć inny problem:

Elastyczność DVCS oznacza, że ​​możliwych jest wiele różnych przepływów pracy, ale niektóre z nich są nieodpowiedzialne. Dzięki DVCS wzrasta potrzeba przejrzystego procesu lub procedur. Działanie polegające na utrzymywaniu lokalnych zmian może, ale nie musi być odpowiednie, w zależności od wielu rzeczy.

Na przykład: czy programista może pracować nad funkcją zwierzaka w wolnym czasie przez kilka tygodni? W niektórych środowiskach jest to zalecane, w niektórych byłoby to niewłaściwe, a wszystkie zmiany powinny zostać wkrótce scentralizowane. Ale jeśli deweloper przechowuje zmiany lokalnie, z pewnością będą chcieli wprowadzić wszelkie powiązane zmiany, aby upewnić się, że ich praca będzie nadal dobrze się bawić z najnowszą powszechną wersją.

Gdy guma styka się z drogą, wydania oprogramowania lub wdrożenia zwykle pochodzą z centralnego repozytorium, więc programiści muszą uzyskać tam swoje zmiany w celu przetestowania i wdrożenia.

To moja historia i trzymam się jej przez co najmniej kilka minut ...

Wydaje się, że twoje pytanie brzmi: „Połączenia są trudne i należy ich unikać”. Systemy DVCS usuwają tę barierę, w rzeczywistości robią więcej, przyjmują ideę łączenia - nie należy obawiać się połączeń i łączenia konfliktów, ponieważ w przeciwieństwie do narzędzi scentralizowanych narzędzia DVCS obsługują je z założenia.

Jak stwierdza doskonała odpowiedź Jamie F. - Przepływ pracy Commit-Pull-Merge-Push wykonywany regularnie (codziennie) oznacza, że ​​jeśli chodzisz po jakiejś innej pracy, widzisz ją wcześnie - o ile jest widoczna, można nią zarządzać .

Opisane przez ciebie problemy dotyczą bardziej tego, jak wybierasz korzystanie z narzędzi.

6 miesięcy temu przeszliśmy z SVN na GIT, po kilku latach używania SVN i GIT lokalnie. Nikt się nie cofnie, a bolesne konflikty scalania należą już do przeszłości. Kluczem jest mantra „Zaangażuj się często i często”.

Kiedy pracowałem w zespole, który używał git, zasada była następująca: pracuj w prywatnym oddziale, a następnie, gdy będziesz gotowy udostępnić swoją pracę reszcie zespołu, przestaw swoją gałąź na master, zanim zaczniesz pchać. (Następnie sprawdź poprawność swojego oddziału.)

Ta strategia oznaczała, że ​​master był liniową serią zatwierdzeń i że wszystkie problemy z integracją zostały naprawione w oddziałach, zanim zostały upublicznione.

Narzędzie takie jak SVN zdecydowanie zachęca do ściśle zintegrowanego sposobu pracy.

Oznacza to, że często angażuje się we wspólną gałąź (gałąź trunk lub dev).

Jest to w porządku dla większości korporacyjnych środowisk programistycznych, których doświadczyłem, i jest jeszcze ułatwione i wspierane przez zastosowanie ciągłej integracji wspieranej przez obszerne testy integracyjne, testy regresji i testy jednostkowe (Pomaganie poszczególnym programistom w uzyskaniu pewności, że się nie złamali cokolwiek po ich zmianach).

DVCS daje Ci swobodę pracy bardziej niezależnej, co jest potrzebne w niektórych sytuacjach, a (bardzo chwalona) ulepszona obsługa połączeń nie może wyrządzić żadnej szkody.

Niepokój, który zawsze towarzyszy mi w głowie, jest następujący: z wielką swobodą przychodzi pokusa, by z niej skorzystać.

Z pewnością, z mojego (ograniczonego) doświadczenia, spędzam dużo więcej czasu pracując samodzielnie w moim obecnym zespole (używając Mercurial) niż w poprzednich rolach (gdzie korzystaliśmy z SVN, CVS i P4).

Jest to tylko częściowo związane z tym narzędziem, ale myślę, że rozsądnym spostrzeżeniem jest uczynienie, że bez ważnego powodu do poświęcenia wysiłku na komunikację i koordynację ludzie będą mieli tendencję do pracy osobno i osobno.

Niekoniecznie jest to zła rzecz, ale uważam, że należy to wziąć pod uwagę.

Rzeczą w kontroli wersji typu git / mercurial jest częste zatwierdzanie i wypychanie do scentralizowanego serwera, gdy kod jest dobry. Dużym plusem jest to, że tworzy małe łatki, które można łatwo zastosować w przypadku konfliktu. Ponadto przepływ pracy powinien być następujący:

1. Wiele lokalnych zatwierdzeń
2. Wyciągnij z serwera
3. Przekaż na serwer

To pobieranie z serwera może powodować konflikty, ale aby rozwiązać ten problem, wszystko, czego potrzeba wiele razy, to zwykły rebase zamiast scalenia. To, moim zdaniem, utrzyma czystą historię głównej linii i usunie sporo konfliktów.

Dzieje się tak również w przypadku wycofania się z lokalnego repozytorium współpracownika, ponieważ mogą się zdarzyć dwie rzeczy. Albo najpierw naciska na serwer, co jest w porządku, ponieważ masz już jego łatki i nie powinny wystąpić żadne konflikty, albo naciskasz pierwszy, co oznacza, że ​​dostanie twoje łaty tylko wtedy, gdy pociągnie.

Oczywiście czasem scalanie jest lepszym rozwiązaniem, na przykład jeśli pracujesz nad gałęzią funkcji, która powinna zostać scalona w master.

W swoim przepływie pracy mówisz o ludziach, którzy muszą wyraźnie udać się do innego programisty i poprosić go o naprawienie konfliktu, ale nie powinno to być konieczne. Serwer centralny jest „szefem” i przeciw temu powinieneś przede wszystkim pracować. Jeśli zmiany dotyczą centralnego repozytorium, oznacza to, że wszystko jest w porządku. Jeśli nie, to TWOJA zadanie rozwiązać ten konflikt, który może żądać, ty konfliktu z pomóc zrozumieć jego / jej zmiany. Jest to coś, co widzisz, gdy próbujesz ściągnąć / rebase z serwera. Więc bądź szczęśliwy, angażując się i radząc sobie z konfliktami, kiedy powinieneś wyciągać z serwera.

Zasada pracy ze scentralizowanym repozytorium jest taka sama podczas pracy z nieblokującym się systemem scentralizowanym lub rozproszonym:

• W systemie scentralizowanym:
  1. Pobierz najnowszą wersję z mainline („trunk” w subversion, „master” w git, ...)
  2. Zmodyfikuj pliki
  3. Scal zmiany z najnowszą wersją z głównej linii za pomocą polecenia „update”
  4. Zobowiązanie do głównej linii
• W systemie rozproszonym:
  1. Pobierz najnowszą wersję z głównej linii
  2. Zmodyfikuj pliki
  3. Zatwierdź lokalnie
  4. Scal modyfikacje z najnowszą wersją z linii głównej i zatwierdź wynik lokalnie
  5. Naciśnij do głównej linii.

Żadna wersja rozproszona nie umożliwi ci wypchnięcia wersji, która nie w pełni scala poprzedniej wersji głównej (bez specjalnego zastąpienia; czasami jest to przydatne), więc nie przejdzie bez wykonania kroku scalania (więc nie będzie dwóch wersji musiałbyś skonsolidować, jak się martwisz).

Teraz zauważ, że cztery kroki są takie same, z wyjątkiem terminologii, ale systemy rozproszone dodają dodatkowy krok „3. Zatwierdź lokalnie”. Dużą zaletą tego kroku jest to, że gdy aktualizacja / ściąganie powoduje konflikty i nie masz pewności, jak je rozwiązać lub popełnisz błąd, możesz je cofnąć, sprawdzić, co zrobiłeś i ponownie wykonać scalenie. Subversion nie zapamięta żadnego z nich, więc jeśli popełnisz błąd przy aktualizacji aktualizacji, to jesteś skończony.

Jeśli chodzi o gromadzenie zmian, ludzie robią to również w przypadku systemu scentralizowanego. Zwłaszcza jeśli musisz często przełączać się między funkcjami (np. Przerwać dłuższą pracę, aby naprawić błąd lub zrobić kilka drobnych poprawek, których klient pilnie potrzebuje), ludzie często będą musieli zachować zmiany lokalnie, ponieważ nie są skończone. Więc lepiej, jeśli system przynajmniej obsługuje zrozumienie tego.

W obu przypadkach problemy te należy rozwiązać za pomocą odpowiednich wytycznych i komunikacji w zespole, a nie narzędzi. W przypadku bardziej elastycznych narzędzi wytyczne są ważniejsze, ale bardziej elastyczne narzędzia pozwalają lepiej rozwiązywać różne przypadki narożne.