Wzory dla ciągłej integracji i DVCS

12

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

Murph
źródło
Jak myślisz, dlaczego jest za późno, aby uruchomić kompilacje z centralnego repozytorium „na żywo”?
c_maker
Jeśli jeszcze tam nie byłeś, sugeruję udanie się na stronę wymiany stosów kiln ( kiln.stackexchange.com ). Mają sporo treści na temat tego, jak to skonfigurować (oto jeden: kiln.stackexchange.com/questions/29 / .... Osobiście używamy gałęzi według funkcji i kierujemy serwer kompilacji na naszą gałąź „master”. )
Chris Phillips
@Chris - Naprawdę nie ma, nie zajmuje się problemem CI ...
Murph

Odpowiedzi:

2

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

Wyatt Barnett
źródło
Wyatt, moim zdaniem wypychanie powinno nastąpić, gdy masz ukończoną jednostkę pracy (ish) - jedną z korzyści DVCS jest to, że możemy zatwierdzić lokalnie uszkodzony kod. Naprawdę nie podoba mi się pomysł robienia czegokolwiek zgodnie z harmonogramem, ponieważ jest to koniec dnia. Istnieje osobna kwestia „tworzenia kopii zapasowych”, która - dla mnie - polega na skonfigurowaniu reguły wypychania na bok - przy zatwierdzaniu - do innego klonu, który istnieje tylko jako kopia zapasowa.
Murph,
2
Sztuczka Czy istnieje definicja jednostki pracy? Czy to „ta funkcja jest kompletna”, czy „ta cegła została pomyślnie ułożona”. Skłaniamy się ku temu drugiemu, szczególnie w tym modelu rozgałęziania, w którym istnieje wyraźnie rozgraniczona gałąź rozwoju. Rozbijanie rzeczy najlepiej pozostawić, aby wyróżnić gałęzie. Długotrwałe z nich mogą również uzyskać kompilacje CI, jeśli to możliwe. Zwłaszcza jeśli w kuchni jest wielu kucharzy.
Wyatt Barnett
Zgadzam się z twoją definicją „jednostki pracy” i dlatego trochę zmagam się z moim ogólnym modelem (który ma już wiele kompilacji na projekt w różny sposób, aby pomieścić zarówno kompilacje „CI”, jak i „wdrożenia”). Masz rację, odpowiedzią jest załatanie wielu kompilacji, więc ostatecznie moim prawdziwym problemem będzie podpisanie czeku! Przywoływany model rozgałęzienia również wygląda właściwie. Wciąż biorąc pod uwagę ogólny wzorzec (i pozwól, że zostanie to jeszcze bardziej dostosowane, aby uwzględnić specyfikę kilnhg)
Murph
2

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.

Chris Phillips
źródło
1

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 .

psantosl
źródło
Powiedziałbym „lepiej” niż „dobrze”, ponieważ z radością, entuzjazmem i sukcesem przeprowadziłem rozgałęzianie funkcji i konserwacji oraz łączenie się z subversion (-:
Murph,