Wzory dla ciągłej integracji i DVCS

Obecnie używamy Subversion i TeamCity, zamierzamy przejść do używania Mercurial (szczególnie Kiln, ponieważ jesteśmy użytkownikami FogBugz).

Oczywiście spowoduje to zmiany - miejmy nadzieję ulepszeń - w naszych wzorcach programistycznych (wszyscy dwoje!), Ale jedyną kwestią, z którą walczę, jest to, jak ustrukturyzować rzeczy, abyśmy nadal cieszyli się korzyściami płynącymi z ciągłej integracji / naszego serwera CI ( że korzyści są i pozostaną, jest rzeczą oczywistą, której omówienie nie wchodzi w zakres tego pytania).

Dzięki SVN zobowiązujemy się do ograniczonej liczby centralnych repozytoriów - efektywnie po jednym na projekt (mniej więcej jedno rozwiązanie Visual Studio), więc łatwo jest uruchomić kompilację i uzyskać pewność, że wszystkie pliki zostały zatwierdzone i że nie ma zbłąkane zależności itp. Ale jeśli chcemy odpowiednio wykorzystać merkurial, będziemy chcieli mieć więcej instancji repozytorium - w których spodziewam się, że zmiany zasadniczo popłyną w kierunku ostatecznego repozytorium „na żywo”. Problem, z którym się zmagam, polega na tym, że repozytorium na żywo wydaje mi się zbyt „spóźnione”, aby uruchomić moje kompilacje CI OTOH jedna kompilacja CI na projekt na programistę jest prawdopodobnie nadmierna (i powoduje inne problemy).

Trochę łowię, ale to dlatego, że jedną z rzeczy, które daje centralne repozytorium subversion (ja, z naszą konfiguracją!) Jest duża jasność co do tego, co zbudować.

nb Nie pytam o mechanikę używania rtęci z ciągłą integracją - mam tę pracę przy osobistym projekcie, jej wzorce i struktury oraz praktykę / przepływ pracy, które staram się wywrócić.

Po pierwsze, posiadanie wielu kompilacji na projekt w TeamCity jest naprawdę dobrym rozwiązaniem. Charakter platformy sprawia, że ​​jest to naprawdę łatwe - przycisk kopiowania jest z jakiegoś powodu.

W każdym razie, gdy byliśmy w SVN, zwykle uruchamialiśmy 2 kompilacje dla każdego projektu - jeden wskazywał na główną linię rozwojową (w naszym przypadku pień), a drugi wskazywał na naszą gałąź wydania. Przeniesiliśmy tę konfigurację kompilacji do HG, postępując zgodnie z modelem rozgałęzienia podobnym do tego . Jedynym prawdziwym wyzwaniem było znalezienie nowej funkowej wersji o numerach wersji, ponieważ nie mogliśmy już używać aktualnego numeru wersji SVN.

Staramy się zachęcać ludzi do stosunkowo częstego naciskania, szczególnie gdy jest wiele pracy naraz i chcieliśmy szybszych cykli sprzężenia zwrotnego. To, że jest to DCVS, nie oznacza, że ​​musisz naciskać tylko raz dziennie czy coś.

Używamy pieca od około roku i próbowaliśmy kilku różnych rzeczy. Skończyło się na użyciu nazwanych gałęzi (w przeciwieństwie do klonów gałęzi) z następującą strategią rozgałęziania:

• domyślne ścieżki „ukończone” opracowanie
• gałęzie funkcji śledzą trwające prace
• gałęzie wydań śledzą punkty, w których domyślnie wydaliśmy

Tak więc praca zaczyna się od utworzenia gałęzi funkcji z bieżącej wskazówki domyślnej . Po zakończeniu gałęzi funkcji * gałąź jest zamykana i ponownie łączona z domyślną .

W pewnym momencie decydujemy, że jesteśmy gotowi do wydania, więc domyślnie tworzymy nową gałąź wydania z bieżącej wskazówki . To pozwala nam wprowadzać zmiany w kodzie, który jest obecnie produkowany, zobowiązując się do gałęzi wydania, jednocześnie umożliwiając aktywne rozwijanie gałęzi funkcji i domyślnie .

Jeśli chodzi o ciągłą integrację, robimy dwie rzeczy:

• Integracja „zawsze włączona”, która monitoruje stan domyślny
• Nowe integracje dla każdej gałęzi wydania

Domyślne zadanie oddział pozwala nam wiedzieć, że naszym głównym źródłem jest drzewo zawsze stabilny - na oddział uwolnienia pracy daj nam znać, że oddziały te są stabilne i zapewniają nam wyjście kompilacji musimy naciskać uwalnianie do produkcji.

_{* Nasza definicja „zrobione” jest taka, że ​​funkcja jest aktualna z domyślnymi połączeniami i została zatwierdzona podczas przeglądu kodu.}

Jeśli przejdziesz do DVCS, takich jak Hg, nie tylko dostaniesz „część rozproszoną”, ale także pełną moc dobrego rozgałęziania i łączenia.

Biorąc pod uwagę, że teraz będziesz mieć dobry moduł do śledzenia problemów i dobry SCM ... dlaczego nie utworzyć gałęzi dla każdego zadania?

Wzorzec „gałąź na zadanie” nie jest nowy (sprawdź książkę Berczuka), ale zdecydowanie warto spróbować.

Wyjaśniłem to szczegółowo tutaj , a zalety i wady CI kontra „kontrolowane” tutaj .