DVCS pobłogosławił replikację repozytorium wśród zespołów rozproszonych geograficznie

Moja firma bada przejście od Perforce do DVCS i obecnie używamy wielu serwerów proxy Perforce, ponieważ zespoły programistów są rozmieszczone w Niemczech, Chinach, USA i Meksyku, a czasami przepustowość z jednego miejsca do drugiego nie jest aż tak duża.

Rozmawiając z działem IT, zaczęliśmy szukać sposobu, aby wszystko działało płynnie z geograficznie rozproszonej perspektywy, aby każdy mógł uzyskać najnowsze i najlepsze wyniki bez określania, który serwer repo jest źródłem prawdy (tj. Replikacja w sposób transparentny ).

Pomyślałem, że może moglibyśmy emulować mechanizm DNS za pomocą haków pre-push i pre-pull . Rozważmy na przykład kraje A, B i C. Po wyciągnięciu błogosławionego A, samo A pociągnie za zmiany z B, które z kolei pociągną za zmiany w C. Jeśli B i C wprowadzą nowe zmiany, spadną w kierunku A. I odwrotnie, gdy pojawia się impuls, można go propagować do wszystkich błogosławionych repozytoriów.

Wiem, że generalnie masz tylko jedno błogosławione repozytorium, jednak może to nie być skalowane globalnie, a każde błogosławione repozytorium dotyczyłoby tylko zespołów z jednego kraju.

Moje pytanie brzmi : czy koncepcja replikacji repozytorium DVCS jest stosowana w praktyce ?, czy ktoś zrobił to z powodzeniem ?, jeśli tak, jaki jest właściwy sposób?

To pytanie dotyczy przezroczystej replikacji i podejrzewam, że nie ma jeszcze odpowiedzi, ponieważ ludzie mogą się rozłączać z przejrzystością. Pozwolę sobie na chwilę odłożyć na bok przejrzystość, aby skupić się na replikacji. Później zajmę się (lub finezją) przejrzystością i tak naprawdę nie sądzę, żeby to było tak ważne w DVCS.

Po pierwsze, pozwól mi omówić kilka kluczowych punktów dotyczących sposobu działania repozytoriów w DVCS. (Najbardziej znam Mercurial, więc tego użyję na przykład, ale wierzę, że wszystko, co mówię, dotyczy również git.)

A. W DVCS każdy klon zawiera tę samą zawartość pliku i historię co oryginał.

Pod warunkiem, że repozytoria są odpowiednio zsynchronizowane, oznacza to, że można użyć zwykłych operacji propagacji zmian DVCS (klonowanie, wypychanie, wyciąganie) i zwykłych repozytoriów, aby zbudować system replikacji.

B. Nowe zmiany nie muszą być propagowane tam, skąd pochodzą.

W szczególności, jeśli mam pobrać zmiany z konkretnego repozytorium i dodać własne zmiany, moje zmiany nie muszą wracać do tego konkretnego repozytorium. Mogą iść gdzie indziej. Przydatność tego powinna być jasna z przykładów, które pokażę poniżej.

C. Zmiany można propagować za pomocą push lub pull.

W scentralizowanym systemie nowe zmiany można (jak sądzę) wprowadzić do repozytorium. W DVCS możliwe jest skonfigurowanie różnych topologii propagacji zmian, z których niektóre wymagają jedynie ciągnięcia. Zapewnia to większą elastyczność konfiguracji.

Przykłady

Dla celów dyskusji powiedzmy, że Twoje rozproszone zespoły używają systemów w domenach duke.de, duke.us, duke.cn i duke.mx, a ponadto, że duke.de jest miejscem, w którym chcemy mieć „błogosławione” repozytorium. Biorąc pod uwagę te założenia, pozwól mi przedstawić kilka przykładów różnych topologii, które możesz skonfigurować, mając na uwadze trzy kluczowe punkty DVCS powyżej.

0. Scentralizowany model wypychania

Zrób pojedyncze repo na hg.duke.de, a programiści we wszystkich lokalizacjach będą klonować i pobierać stąd i wprowadzać zmiany tutaj. Może to działać na ludzi w Niemczech, ale prawdopodobnie stanowiłoby problem dla reszty świata. Wszystkie operacje klonowania, ściągania i wypychania przebiegałyby przez powolne połączenia sieciowe dalekiego zasięgu. Wykorzystuje DVCS podobnie jak system scentralizowany. To jest problem, który próbujesz rozwiązać.

1. Scentralizowane wypychanie z replikacją

Miej błogosławione repo na hg.duke.de i repliki na hg.duke.cn, hg.duke.mx i hg.duke.us. Programiści klonują z lokalnej repliki i wypychają zmiany na hg.duke.de. Za każdym razem, gdy pojawiają się nowe zmiany w hg.duke.de, uruchamiany jest hak, który propaguje je do replik. Repliki są w innym przypadku tylko do odczytu, więc nigdy nie będzie żadnych połączeń ani konfliktów.

Na przykład, jeśli jestem programistą w Meksyku, sklonuję plik z hg.duke.mx, ale przekażę zmiany do hg.duke.de. Jeśli inne zmiany zostaną wprowadzone do hg.duke.de, zanim będę mógł je wypchnąć, moje push zostanie zablokowane. Pozostałe zmiany zostaną zreplikowane do hg.duke.mx, więc ściągnę te zmiany lokalnie, scalę, a następnie spróbuję ponownie pchnąć na hg.duke.de.

Powinno to zapewnić pewne korzyści, ponieważ wszystkie operacje dużego klonowania są wykonywane lokalnie. Przesuwanie do centralnego repozytorium w innym miejscu może nie być takie złe, ponieważ zmiany są wypychane stosunkowo rzadko, zmiany przyrostowe są na ogół dość niewielkie. (W szczególności Mercurial zasadniczo wysyła skompresowane pliki różnic, a nie całe pliki i ich historie).

W Mercurial możesz skonfigurować lokalne repozytorium, aby pobierało dane z jednej lokalizacji i wypychało do innej, umieszczając w .hg/hgrcpliku coś takiego :

[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de

2. Prosty model ciągnienia

Kontynuując z hg.duke.de jako błogosławionym repozytorium i innymi jako repliki, możemy propagować zmiany poprzez pull zamiast push. Programiści klonują i pobierają ze swojej lokalnej repliki jak zwykle. Gdy zmiana jest gotowa, programista wysyła żądanie ściągnięcia do jakiejś centralnej usługi, która pobiera z repozytorium dewelopera do hg.duke.de. Konieczne będzie ustanowienie polityki dotyczącej fuzji. Na przykład, jeśli występują konflikty scalania, żądanie może zostać odrzucone, wymagając od dewelopera pobrania (z lokalnej repliki), scalenia i ponownego przesłania żądania ściągnięcia.

Takie podejście ma tę zaletę, że nie każe deweloperowi czekać na propagowanie zmian. Oczywiście deweloper musi jeszcze poczekać, aż zostanie zrealizowane żądanie ściągnięcia, ale przynajmniej w tym czasie może popracować nad dodatkowymi zmianami.

Wariacje

Istnieje wiele odmian, które można zastosować.

Złożenie żądania ściągnięcia jest idealnym czasem na sprawdzenie kodu. Zmiany są publikowane w tym sensie, że są dostępne dla wszystkich, ale nie zostały jeszcze zintegrowane z błogosławionym repozytorium.

Żądania ściągania mogą być przetwarzane ręcznie lub przez zautomatyzowany system. Przetwarzanie żądania ściągnięcia może nie łączyć zmian bezpośrednio w błogosławione repozytorium, ale zamiast tego w tymczasowy obszar przejściowy, w którym wykonywany jest cykl kompilacji i testowania. Dopiero po przejściu wszystkich testów zestaw zmian został zintegrowany z błogosławionym repozytorium.

Ci, którzy są bardziej komfortowi w modelu wypychania, mogą chcieć skonfigurować lokalne repozytorium przemieszczania w każdej lokalizacji obok repliki, np. Hg-stage.duke.mx, hg-stage.duke.cn itp. To wymaga nieco więcej pracy, jednak, ponieważ programiści muszą nie tylko łączyć się z innymi lokalnymi zmianami, ale ktoś musi być odpowiedzialny za scalanie zmian z repozytoriów przemieszczania w repozytorium błogosławione. Może to jednak działać w odpowiednich okolicznościach i może być wspomagane przez automatyzację.

"Przezroczystość"

Teraz kwestia przezroczystej replikacji.

Biorąc pod uwagę powyższe scenariusze, tak naprawdę nie widzę potrzeby przezroczystej replikacji. Wszystkie repo są widoczne dla wszystkich i istnieją konwencje pobierania i klonowania z lokalnej repliki i wypychania do błogosławionego repo lub lokalnego obszaru testowego.

Jeśli chcesz mieć przejrzystość, możesz skonfigurować domeny wyszukiwania DNS według ich lokalizacji. Lokalna replika i repozytorium pomostowe byłyby po prostu określane jako „hg” i „hg-stage”, a konfiguracja DNS rozwiązałaby je jako hg.duke.cn i hg-stage.duke.cn dla programistów w Chinach i odpowiednio dla programiści w innych lokalizacjach. Ale to jest trochę magii i może być mylące, i naprawdę nie sądzę, żeby to wiele dodawało.

Mam nadzieję, że to odpowiada na twoje pytanie. Odpowiedziałem na wiele swobód, ale wydaje mi się, że twojej sytuacji można zaradzić za pomocą technik opisanych powyżej.