Kontynuujesz rozwój w oddziale czy w pniu? [Zamknięte]

Załóżmy, że tworzysz oprogramowanie, które ma okresowe wersje. Jakie są najlepsze praktyki dotyczące rozgałęziania i łączenia? Odcinanie okresowych gałęzi wydań dla publiczności (lub kimkolwiek jest twój klient), a następnie kontynuowanie rozwoju na linii głównej lub uznanie linii głównej za stabilną wersję, okresowe oznaczanie jej jako wydania i wykonywanie eksperymentów w gałęziach. Co według ludzi jest uważane za „złoty” lub „piaskownicę”?

Wypróbowałem obie metody w dużej aplikacji komercyjnej.

Odpowiedź na to, która metoda jest lepsza, zależy w dużym stopniu od twojej dokładnej sytuacji, ale napiszę, co pokazało moje ogólne doświadczenie do tej pory.

Ogólnie lepsza metoda (z mojego doświadczenia): Pień powinien być zawsze stabilny.

Oto kilka wskazówek i zalet tej metody:

• Zakoduj każde zadanie (lub powiązany zestaw zadań) w jego własnej gałęzi, a będziesz mieć elastyczność, kiedy chcesz scalić te zadania i wykonać wydanie.
• Kontrola jakości powinna zostać przeprowadzona na każdej gałęzi, zanim zostanie ona połączona z linią główną.
• Wykonując kontrolę jakości w każdej gałęzi, będziesz dokładnie wiedzieć, co spowodowało błąd.
• To rozwiązanie jest dostępne dla dowolnej liczby programistów.
• Ta metoda działa, ponieważ rozgałęzianie jest prawie natychmiastową operacją w SVN.
• Oznacz każde wydanie, które wykonujesz.
• Możesz opracować funkcje, których nie planujesz udostępniać przez jakiś czas, i zdecydować, kiedy dokładnie je scalić.
• W przypadku każdej wykonywanej pracy możesz skorzystać z zatwierdzenia swojego kodu. Jeśli pracujesz tylko z linii głównej, prawdopodobnie będziesz często utrzymywać swój kod niezaangażowany, a zatem niezabezpieczony i bez automatycznej historii.

Jeśli spróbujesz zrobić coś odwrotnego i wykonasz cały swój rozwój w bagażniku, będziesz mieć następujące problemy:

• Ciągłe problemy z kompilacją dla codziennych kompilacji
• Strata produktywności, gdy programista popełni problem dla wszystkich innych osób w projekcie
• Dłuższe cykle wydawnicze, ponieważ musisz wreszcie uzyskać stabilną wersję
• Mniej stabilne wersje

Po prostu nie będziesz mieć takiej elastyczności, jakiej potrzebujesz, jeśli spróbujesz utrzymać gałąź stabilną, a linię główną jako piaskownicę rozwoju. Powodem jest to, że nie możesz wybierać z pnia tego, co chcesz umieścić w tej stabilnej wersji. Wszystko byłoby już zmieszane razem w bagażniku.

W szczególności jeden przypadek, o którym powiedziałbym, aby wykonać wszystkie prace rozwojowe w bagażniku, to rozpoczęcie nowego projektu. W zależności od sytuacji mogą istnieć również inne przypadki.

Nawiasem mówiąc, rozproszone systemy kontroli wersji zapewniają znacznie większą elastyczność i zdecydowanie polecam przejście na hg lub git.

Pracowałem z obiema technikami i powiedziałbym, że programowanie na pniu i rozgałęzianie stabilnych punktów w kolejnych wydaniach jest najlepszym sposobem.

Osoby powyżej, które sprzeciwiają się, mówiąc, że będziesz mieć:

• Ciągłe problemy z kompilacją dla codziennych kompilacji
• Strata produktywności, gdy programista popełni problem dla wszystkich innych osób w projekcie

prawdopodobnie nie stosowali technik ciągłej integracji.

Prawdą jest, że jeśli nie wykonasz kilku kompilacji testowych w ciągu dnia, powiedzmy raz na godzinę, wystawią się na te problemy, które szybko zdławią tempo rozwoju.

Wykonanie kilku kompilacji testowych w ciągu dnia szybko powoduje złożenie aktualizacji do głównej bazy kodu, aby inni mogli z niej korzystać, a także ostrzega w ciągu dnia, jeśli ktoś zepsuł kompilację, aby mogli ją naprawić przed powrotem do domu.

Jak już wspomniano, dowiadywanie się o zepsutej kompilacji tylko wtedy, gdy nocna kompilacja do uruchamiania testów regresji nie powiedzie się, jest zwykłym szaleństwem i szybko spowolni działanie.

Przeczytaj artykuł Martina Fowlera na temat ciągłej integracji . Wdrożyliśmy własny taki system dla dużego projektu (3000 kSLOC) w około 2000 liniach Posix sh.

Mam tendencję do przyjmowania podejścia „gałęzi wydania”. Pień jest niestabilny. Gdy nadejdzie czas wydania, stworzyłem gałąź wydania, którą podchodziłbym ostrożniej. Kiedy to się skończy, oznaczyłem / oznaczyłem stan repozytorium etykietą / tagiem, żeby znać „oficjalną” wydaną wersję.

Rozumiem, że istnieją inne sposoby, aby to zrobić - tak właśnie robiłem w przeszłości.

Obie.

Pień jest używany przez większość zabudowy. Oczekuje się jednak, że dołożymy wszelkich starań, aby żadne zgłoszenie do bagażnika go nie uszkodziło. (częściowo zweryfikowany przez automatyczny system kompilacji i testów)

Wydania są utrzymywane w ich własnym katalogu, w którym są wprowadzane tylko poprawki błędów (a następnie łączone w trunk).

Każda nowa funkcja, która ma pozostawić łącze trunk w niestabilnym lub niedziałającym stanie, jest wykonywana w jego własnej oddzielnej gałęzi, a następnie scalana z linią główną po zakończeniu.

Lubię i stosuję podejście opisane przez Henrika Kniberga w sekcji Kontrola wersji dla wielu zespołów zwinnych . Henrik wykonał świetną robotę, wyjaśniając, jak obsługiwać kontrolę wersji w zwinnym środowisku z wieloma zespołami (działa również dla jednego zespołu w tradycyjnych środowiskach) i nie ma sensu go parafrazować, więc po prostu opublikuję „ściągawkę” (która to samo wyjaśnia) poniżej:

Lubię to ponieważ:

• To proste: możesz to uzyskać z obrazka.
• Działa (i skaluje się) dobrze, bez problemów z łączeniem i konfliktami.
• W każdej chwili możesz wypuścić „działające oprogramowanie” (w duchu agile).

I na wypadek, gdyby nie było to wystarczająco jasne: programowanie odbywa się w "gałęziach roboczych", łącze trunk jest używane dla kodu DONE (nadającego się do wydania). Sprawdź kontrolę wersji dla wielu zespołów zwinnych, aby poznać wszystkie szczegóły.

Dobrym odniesieniem do procesu rozwoju, który utrzymuje stabilny bagażnik i wykonuje całą pracę w oddziałach, jest Ultimate Quality Development System Divmod . Krótkie podsumowanie:

• Wszystkie wykonane prace muszą mieć przypisany bilet
• Dla każdego biletu, w którym wykonywana jest praca nad tym biletem, tworzony jest nowy oddział
• Zmiany z tej gałęzi nie są scalane z powrotem do głównej linii głównej bez przeglądu przez innego członka projektu

Używają do tego SVN, ale można to łatwo zrobić za pomocą dowolnego z rozproszonych systemów kontroli wersji.

Myślę, że twoje drugie podejście (np. Oznaczanie wydań i robienie rzeczy eksperymentalnych w gałęziach, biorąc pod uwagę stabilny trunk) jest najlepszym podejściem.

Powinno być jasne, że gałęzie dziedziczą wszystkie błędy systemu w momencie, w którym jest on rozgałęziony: jeśli poprawki zostaną zastosowane do pnia, będziesz musiał przejść jeden po drugim do wszystkich gałęzi, jeśli utrzymujesz gałęzie jako swego rodzaju terminator cyklu wydania. Jeśli masz już 20 wydań i odkryłeś błąd, który sięga aż do pierwszego, będziesz musiał ponownie zastosować poprawkę 20 razy.

Gałęzie mają być prawdziwymi piaskownicami, chociaż bagażnik też będzie musiał pełnić tę rolę: tagi wskażą, czy kod jest w tym momencie „złoty”, nadający się do wydania.

Rozwijamy się na pniu, chyba że zmiany są zbyt duże, destabilizujące lub zbliżamy się do głównej wersji jednego z naszych produktów, w takim przypadku tworzymy tymczasową gałąź. Tworzymy również stały oddział dla każdego wydania produktu. Wydaje mi się, że dokument Microsoftu dotyczący wytycznych rozgałęziania jest całkiem pomocny. Samouczek Erica Sinka na temat rozgałęziania jest również interesujący i zwraca uwagę, że to, co działa dla Microsoftu, może być zbyt ciężkie dla niektórych z nas. Tak było w naszym przypadku, używamy podejścia, które Eric mówi jego zespół.

To zależy od twojej sytuacji. Używamy Perforce i zazwyczaj mamy kilka linii rozwoju. Pień jest uważany za „złoty” i cały rozwój zachodzi na gałęziach, które łączą się z powrotem w linię główną, gdy są wystarczająco stabilne, aby się zintegrować. Pozwala to na odrzucenie funkcji, które nie wykonują cięcia i może zapewnić solidną, przyrostową zdolność w czasie, którą mogą uzyskać niezależne projekty / funkcje.

Łączenie i nadrobienie nowych funkcji wprowadzonych do pnia wiąże się z kosztami integracji, ale i tak będziesz cierpieć z powodu tego bólu. Posiadanie wszystkich razem rozwijających się na pniu może prowadzić do sytuacji dzikiego zachodu, podczas gdy rozgałęzianie pozwala skalować i wybierać punkty, w których chcesz wziąć gorzkie tabletki integracyjne. Obecnie jesteśmy skalowani do ponad stu programistów w kilkunastu projektach, z których każdy ma wiele wydań korzystających z tych samych podstawowych komponentów i działa całkiem nieźle.

Piękno tego polega na tym, że można to zrobić rekurencyjnie: duża gałąź funkcji może być własnym pniem, a inne gałęzie odpadają, jeśli tak. Ponadto, ostateczne wydania otrzymają nową gałąź, która da ci miejsce do stabilnej konserwacji.

Próba zarządzania utrzymaniem obecnego kodu produkcyjnego zgodnie z nowym rozwojem jest w najlepszym przypadku problematyczna. Aby złagodzić te problemy, kod powinien przejść do linii konserwacyjnej, gdy testy zakończą się i kod będzie gotowy do dostarczenia. Ponadto główna linia powinna mieć rozgałęzienie, aby pomóc w stabilizacji wydań, ograniczyć eksperymentalne prace rozwojowe lub pomieścić wszelkie wysiłki programistyczne, których cykl życia obejmuje wiele wersji.

Oddział bezobsługowy powinien być tworzony tylko wtedy, gdy istnieje prawdopodobieństwo (lub pewność) kolizji między kodem, którymi trudno byłoby zarządzać w inny sposób. Jeśli oddział nie rozwiąże problemu logistycznego, to go stworzy.

Normalny rozwój wydania ma miejsce w głównej linii. Deweloperzy rejestrują się i wylogowują z głównej linii, aby wykonać normalną pracę. Prace rozwojowe nad poprawkami do bieżącego kodu produkcyjnego powinny znajdować się w gałęzi dla tego wydania, a następnie zostać połączone z główną linią, gdy łatka przejdzie testy i zostanie wdrożona. Praca w oddziałach niezwiązanych z utrzymaniem powinna być koordynowana indywidualnie.

To zależy od rozmiaru twojego wysiłku rozwojowego. Wiele zespołów pracujących równolegle nie będzie w stanie efektywnie pracować nad tym samym kodem (linią główną). Jeśli masz tylko niewielką grupę ludzi, a Twoim głównym zmartwieniem jest wycięcie gałęzi, abyś mógł kontynuować pracę, wracając do gałęzi w celu poprawiania błędów w obecnym kodzie produkcyjnym, które będą działać. Jest to trywialne zastosowanie rozgałęziania i niezbyt uciążliwe.

Jeśli masz dużo równoległego rozwoju, będziesz chciał mieć gałęzie dla każdego z wysiłków, ale będzie to również wymagało większej dyscypliny: upewnienie się, że twoje gałęzie są przetestowane i gotowe do ponownego scalenia. Planowanie fuzji powoduje, że dwie grupy nie próbują się łączyć w tym samym czasie itp.

Niektóre gałęzie są rozwijane tak długo, że musisz zezwolić na łączenie się z pnia do gałęzi, aby zmniejszyć liczbę niespodzianek podczas ostatecznego scalania z powrotem do pnia.

Będziesz musiał poeksperymentować, jeśli masz dużą grupę programistów i poczuć, co działa w Twojej sytuacji. Oto strona firmy Microsoft, która może być nieco przydatna: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Używamy pnia do głównego rozwoju i gałęzi do prac związanych z konserwacją wydań. Działa fajnie. Ale wtedy gałęzie powinny być używane tylko do naprawiania błędów, bez większych zmian, szczególnie po stronie bazy danych, mamy regułę, że tylko zmiana schematu może nastąpić na głównym pniu, a nigdy w gałęzi.

Jeśli masz zamiar przejść przez cykl wydawniczy, dużą funkcję, zostaniesz uwięziony w gałęzi. W przeciwnym razie pracujemy w bagażniku i gałęzi dla każdego wydania produkcyjnego w chwili, gdy tworzymy.

Poprzednie wersje produkcyjne są przenoszone w tym czasie do old_production_, a bieżąca wersja produktu jest zawsze tylko produkcją. Cały nasz serwer kompilacji wie o produkcji, to o tym, jak wdrożyć gałąź produkcyjną, a uruchamiamy ją za pomocą wyzwalacza siły.

Podążamy za podejściem trunk = bieżący strumień rozwoju, gałąź = wydanie (y). Po wydaniu klientowi rozgałęziamy pień i po prostu przesuwamy go do przodu. Musisz zdecydować, ile wersji chcesz obsłużyć. Im więcej wspierasz, tym więcej będziesz robić scalania poprawek błędów. Staramy się, aby nasi klienci mieli nie więcej niż 2 wydania za bagażnikiem. (Np. Dev = 1.3, obsługiwane wersje 1.2 i 1.1).

Główną linią rozwoju jest zazwyczaj pień.

Wydania są rozgałęzione i często eksperymentalne lub poważne prace są wykonywane na gałęziach, a następnie łączone z powrotem do pnia, gdy jest gotowe do integracji z główną linią rozwojową.

Pień powinien być generalnie głównym źródłem rozwoju. W przeciwnym razie spędzisz dużo czasu na wprowadzaniu nowych funkcji. Widziałem, jak robi się to w inny sposób i zwykle prowadzi to do wielu problemów z integracją w ostatniej chwili.

Oznaczamy nasze wydania, abyśmy mogli szybko reagować na awarie produkcyjne bez dystrybucji aktywnego rozwoju.

Dla mnie to zależy od używanego oprogramowania.

W CVS po prostu pracowałbym w "trunk" i nigdy nie tagowałbym / rozgałęzienia, ponieważ zrobienie inaczej było naprawdę bolesne.

W SVN robiłbym swoje "krwawe ostrza" w trunk, ale kiedy był czas na wykonanie push serwera, zostałbym odpowiednio oznaczony.

Niedawno przeszedłem na git. Teraz stwierdzam, że nigdy nie pracuję w bagażniku. Zamiast tego używam nazwanej gałęzi piaskownicy „nazwa nowej funkcji”, a następnie łączę się w ustaloną gałąź „bieżącej produkcji”. Teraz, kiedy o tym myślę, naprawdę powinienem utworzyć gałęzie „release-VERSIONNUMBER” przed połączeniem z powrotem w „bieżącą produkcję”, abym mógł wrócić do starszych stabilnych wersji ...

To naprawdę zależy od tego, jak dobrze Twoja organizacja / zespół zarządza wersjami i jakiego SCM używasz.

• Jeśli co dalej (w następnym wydaniu) można łatwo zaplanować, lepiej będzie rozwijać się w bagażniku. Zarządzanie oddziałami zajmuje więcej czasu i zasobów. Ale jeśli następnego nie da się łatwo zaplanować (zdarza się to cały czas w większych organizacjach), prawdopodobnie skończyłoby się na wybieraniu rewelacyjnych zatwierdzeń (setki / tysiące) zamiast gałęzi (kilka lub dziesiątek).
• Dzięki Git lub Mercurial zarządzanie oddziałami jest znacznie łatwiejsze niż cvs i subversion. Wybrałbym stabilną metodologię gałęzi trunk / topic. Tego właśnie używa zespół git.git. przeczytaj: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• W Subversion po raz pierwszy zastosowałem metodologię programowania w bagażniku. Było sporo pracy, jeśli chodzi o datę premiery, ponieważ za każdym razem musiałem wybierać najlepsze zmiany (moja firma nie jest dobra w planowaniu). Teraz jestem swego rodzaju ekspertem w Subversion i wiem całkiem dobrze o zarządzaniu gałęziami w Subversion, więc przechodzę w kierunku stabilnej metodologii gałęzi głównej / gałęziowej. Działa znacznie lepiej niż wcześniej. Teraz próbuję jak działa zespół git.git, chociaż prawdopodobnie pozostaniemy przy Subversion.

Oto projekt SVN, który preferuję:

• korzeń
  • rozwój
    • gałęzie
      • feature1
      • feature2
      • ...
    • bagażnik samochodowy
  • beta
    • tagi
    • bagażnik samochodowy
  • wydanie
    • tagi
    • bagażnik samochodowy

Cała praca jest wykonywana z poziomu rozwoju / linii głównej, z wyjątkiem głównych funkcji, które wymagają własnej gałęzi. Po przetestowaniu pracy pod kątem development / trunk, łączymy przetestowane problemy w wersję beta / trunk. W razie potrzeby kod jest testowany na serwerze beta. Kiedy jesteśmy gotowi do wprowadzenia pewnych zmian, po prostu scalamy odpowiednie wersje w wydanie / trunk i wdrażamy.

Tagi można tworzyć w gałęzi beta lub gałęzi wydania, dzięki czemu możemy śledzić konkretne wydanie zarówno dla wersji beta, jak i wydania.

Taka konstrukcja zapewnia dużą elastyczność. Ułatwia nam również pozostawienie wersji w wersji beta / trunk podczas łączenia innych w wydanie / trunk, jeśli niektóre wersje nie przeszły testów w wersji beta.

Metodą, której używamy, jest podejście Perforce, które jest szczegółowo omówione w świetnej książce Laury Wingerd:

http://oreilly.com/catalog/9780596101855/index.html

Chociaż książka jest z konieczności skoncentrowana (Wingerd jest menedżerem produktu Perforce), koncepcje można zastosować do dowolnego lub wszystkich VCS.

Podejście (i platforma) siłowe bardzo nam służyło. Jest używany w wielu firmach (Google, Intuit i, jak słyszałem, sam Microsoft Windows).

Książkę warto przeczytać.

Przeczytaj to: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Nie ma jednej uniwersalnej odpowiedzi na pytanie IMHO dotyczące konwencji wywrotowej.

To naprawdę zależy od dynamiki projektu i firmy z niego korzystającej. W bardzo szybko zmieniającym się środowisku, kiedy wydanie może się zdarzać nawet co kilka dni, jeśli spróbujesz religijnie otagować i rozgałęzić, otrzymasz niezarządzalne repozytorium. W takim środowisku podejście rozgałęziające się w razie potrzeby stworzyłoby środowisko znacznie łatwiejsze w utrzymaniu.

Ponadto - z mojego doświadczenia wynika, że ​​z czysto administracyjnego punktu widzenia niezwykle łatwo jest przełączać się między metodologiami svn, kiedy się zdecydujesz.

Dwa podejścia, które najlepiej sprawdzają się, to rozgałęzienie w razie potrzeby i rozgałęzienie każdego zadania. Są to oczywiście dokładne przeciwieństwa. Jak mówiłem - chodzi o dynamikę projektu.

@Brian R. Bondy: Należy pamiętać, że nie jest to rozwiązanie, gdy Twój zespół osiągnie pewną liczbę ppl / zadań wykonywanych równolegle w projekcie.

Gdy dział kontroli jakości jest zaangażowany w qa, wysiłki potrzebne do zapewnienia jednej instalacji na oddział w toku są po prostu zbyt duże. Pomyśl o SOA / klientach / serwerach / usługach internetowych / bazach danych, z których wszystkie muszą być dostarczane dla każdego oddziału .

W rozwiązaniu tym brakuje również etapu integracji.