Ciągła integracja z rozwojem wielu gałęzi w Subversion

Question

W projekcie, nad którym pracuję, używamy SVN ze strategią "Stabilnego pnia". Oznacza to, że dla każdego znalezionego błędu QA otwiera bug ticket i przypisuje go programistom. Następnie deweloper rozwiązuje ten problem i sprawdza go w oddziale (off bagażniku, nazwijmy to, że bug branch) i że oddział będzie zawierać tylko poprawki dla danego bug ticket

Kiedy zdecydowaliśmy się komunikat, dla każdego poprawki błędów, które chcemy udostępnić klientowi, programista połączy wszystkie poprawki od kilku bug branch do trunk i przystąpi do normalnego cyklu kontroli jakości.

Problemem jest to, że używamy trunk w kodzie dla naszej pracy CI (Hudson, specjalnie), a zatem dla wszystkich zobowiązuje się do bug branch, to przegap codziennie build aż robi się połączyły trunk kiedy zdecydowaliśmy się wypuść nową wersję oprogramowania. Oczywiście, to pokonuje cel posiadania CI.

Jaki jest właściwy sposób rozwiązania tego problemu?

Answer 1

Jak sam zauważyłeś Celem korzystania z oddziału jest oddzielenie specyficznych wahań kodu od naprawiania biletów i rozwijania funkcji z dala od pnia. Po ukończeniu funkcji lub biletu należy ją połączyć. W Subversion, gałęzie są lepiej wykorzystywane do śledzenia zestawów powiązanych funkcji (takich jak te do wydania), a nie poszczególnych funkcji. W przeciwnym razie szybko skończysz z niecałkowitą liczbą oddziałów.

Ponadto, dlaczego w ogóle opóźnić integrację? Im dłużej czekasz między wydaniami, tym większe prawdopodobieństwo, że twoja wyizolowana zmiana będzie w konflikcie z kolejną zmianą dokonaną od tego czasu i/lub spowoduje dalszy brak stabilności w twoim systemie po ponownym połączeniu.

Moja ulubioną taktyką jest zrobić coś takiego:

[begin work on 0.4 branch] 
     | 
     | 
     v    
(*)---(*)-------(a)--(b)---(c)-- <-- Trunk is "unstable". 
     \  |   |  Contains all commits. 
    ver \ [merge from trunk]  Developers commit to trunk. 
<-- 0.3 \  v   v 
      +---(a)--------(c)-- <-- Branch is "stable". 
            Contains selected commits from trunk. 
            Know beforehand what's going onto branch. 

Teraz, gdy jesteś gotowy do wydania:

[trunk] 
(*)---(*)---(*)----------------------------[development continues]---> 


[0.4 branch]      No further development on branch unless 
(*)---(*)---(*)---[0.4-release]  spot fixes are needed. Then re-tag (0.4.1) 
         ^  and re-release. 
          |   
          | 
         [make tag on branch; release from stable branch, 
         not unstable trunk] 

Wiem, że pytanie o najlepszy sposób zmuszenia Twój ciągły system integracji, aby to zrobić. Ale z pełnym szacunkiem sugerowałbym, że biorąc pod uwagę fakt, że Hudson jest uznawany za względnie zdolny system CI, fakt, że masz wiele kłopotów z przygotowaniem swojego modelu rozwoju, jest możliwym znakiem, że nie jest to proces, który nadaje się dobrze do CI na pierwszym miejscu.

Naszą typową praktyką jest posiadanie dwóch bazowych buildów na projekt: jeden na pniu i jeden na bieżący oddział wydania. W ten sposób wiesz, że:

• Cokolwiek jest aktualizowany jest zintegrowany poprawnie (trunk)
• Bez względu na cel wydanie jest, jeśli przestał działać teraz będzie jeszcze prawidłowa i pracy (tylko nie w pełni funkcjonalny) budować.

Answer 2

Zamiast tworzyć rozgałęzienia dla poprawek błędów, dlaczego nie spróbujesz utworzyć gałęzi dla wersji przed naprawieniem błędu, a następnie zastosować poprawkę do pnia.

W ten sposób, jeśli chcesz dać klientom poprawki błędów, dajesz im wersję bagażnika. Jeśli nie chcesz nadawać im poprawki błędów, możesz podać im wersję oddziału, zanim zostanie zastosowana poprawka.

W ten sposób możesz zbudować linię Hudson, a Twoje nocne kompilacje będą zawierały wszystkie poprawki.

Answer 3

Wykonuj nocne połączenie do "niestabilnego zła-bliźniaka-pnia", który łączy wszystkie gałęzie z błędami z podwójnym podwójnym pniem.

Lub skonfigurować nocne kompilacje na każdej gałęzi z błędami (która brzmi jak wiele nocnych kompilacji).

Moim zdaniem to brzmi jak strasznie dużo rozgałęzień dla scentralizowanego rozwiązania kontroli źródła stylu. Być może potrzebujesz rozproszonego systemu kontroli wersji i serwera kompilacji na każdej stacji roboczej, która wydaje się, że dokonałaby tego samego (izolowane kontrole dla każdego dewelopera i codzienne kompilacje na to, co sprawdzają programiści)

Answer 4

Brzmi to bolesne i nadmiernie skomplikowane (z punktu widzenia oddziału/scalenia).

Chciałbym rozgałęziać się w wersji i mieć deweloperów sprawdzić w bagażniku. Wszystko, co musi wyjść jako hot fix, może zostać połączone z gałęzią wydania.

Answer 5

mi odpowiedzieć na to dużo, a oto jak IBM zaleca go ClearCase (UCM), a robię to w świecie rzeczywistym:

- Project 
    |- development mainline 
    |- TAG: version-1.0 
     |- version-1.0-bugfix#123 
     |- version-1.0-bugfixes 
    |- TAG: version-1.0-sp1 
     |- version-1.0-sp1-bugfix#234 
     |- version-1.0.sp1-bugfixes 
    |- TAG: version-1.0-sp2 

Nic nie poprzedzone TAG jest oddział.

Answer 6

Oto co robimy (inspirowany z Version Control for Multiple Agile Teams Henrik Kniberg):

• rozwój odbywa się w gałęzi rozwojowej i funkcje są wypychane do pnia kiedy „Gotowe zrobione”
• bagażnik jest „gotowe "oddział
• w momencie wydania, możemy oznaczyć bagażnik
• gdy wada wyjdzie, możemy utworzyć oddział zwalniającą z tagiem
• wady jest poprawione w branży uwalnianiu
• plaster jest połączone z gałęzi uwalniania do bagażnika natychmiast po zwolnieniu (aby uwzględnić go w przyszłych wydaniach)

CI działa na wszystkich oddziałach (gałęzie rozwojowe, pień, gałęzie release).