Czy powinieneś zawracać sobie głowę oddziałami SVN, jeśli tylko je masz?

10

Jeśli pracujemy tylko z jednym oddziałem w Subversion, czy powinniśmy się tym przejmować? Czy nie możemy po prostu pracować na bagażniku, aby przyspieszyć?

Oto jak rozwijamy się z Subversion:

  • Jest tu bagażnik
  • Tworzymy nową gałąź rozwoju
  • W tej branży opracowujemy nową funkcję
  • Po zakończeniu tej operacji jest ona łączona w pniu, gałąź jest usuwana, a z pnia tworzona jest nowa gałąź programistyczna

Kiedy chcemy wprowadzić do produkcji, tworzymy etykietę z bagażnika. Poprawki błędów są wprowadzane do gałęzi na podstawie tego znacznika. Ta poprawka jest następnie scalana w pniu.

Dlatego tworzymy nową gałąź programistyczną po zakończeniu funkcji. W ten sposób poprawka zostanie wkrótce uwzględniona w naszym nowym kodzie.

Poniżej znajduje się schemat, który powinien wyjaśnić:

Nasza strategia Subversion

Teraz wydaje się, że nie jest to najbardziej efektywny sposób pracy. Budujemy lokalnie przed zatwierdzeniem, co zajmuje około 5-10 minut. Możesz zrozumieć, że odczuwa się to jako dość długi czas oczekiwania.

Idea gałęzi programistycznej polega na tym, że bagażnik jest zawsze gotowy do wydania. Ale nie jest to już prawdą w naszej sytuacji. Czasami funkcja jest prawie gotowa, a niektórzy programiści już zaczynają kodować następną funkcję (w przeciwnym razie siedzieliby i czekali, aż jeden lub dwóch programistów zakończy i połączy).

Następnie, gdy funkcja 1 jest zakończona, jest scalana w pień, ale zawiera pewne zatwierdzenia funkcji 2.

Czy więc powinniśmy zawracać sobie głowę gałęzią rozwoju, ponieważ mamy tylko jeden oddział? Czytałem o rozwoju opartym na pniu i gałęzi po abstrakcji, ale większość artykułów znalazłem skupienie się na części po gałęzi. Mam wrażenie, że dotyczą dużych zmian, które obejmą kilka wydań. Nie mamy z tym problemu.

Co myślisz? Czy możemy po prostu pracować na bagażniku? Najgorszym scenariuszem jest (myślę), że musielibyśmy zrobić tag z pnia i wybrać niezbędne zmiany, ponieważ niektóre zmiany / funkcje nie są jeszcze gotowe do produkcji.

Piotr
źródło
1
Myślę, że byłoby lepiej, gdybyś miał więcej niż jedną gałąź. Jeden dla każdej funkcji. W ten sposób, jeśli kiedykolwiek zaczniesz pracować nad dużą funkcją, która zajmie trochę czasu, nie będziesz rezygnować z poprawek błędów i takich już dla już wydanych wersji.
Amy Anuszewski,
Gałąź dla każdej funkcji wydaje się komplikować, podczas gdy staramy się zmniejszyć złożoność. Ponadto, jeśli istnieje poprawka błędu (tj. Dla wersji 1.0), można to zrobić na gałęzi wykonanej z tagu. Następnie możemy oznaczyć tę gałąź (tworząc wersję 1.1), zwolnić ją i scalić poprawkę z bagażnikiem. Rozwój dużej funkcji będzie kontynuowany na bagażniku.
Peter

Odpowiedzi:

6

Praca z IMHO bezpośrednio na pniu jest w porządku, jeśli możesz dokonywać małych przyrostów i masz ciągłą integrację, dzięki czemu możesz zapewnić (w rozsądnym zakresie), że twoje zobowiązania nie zepsują istniejącej funkcjonalności. Robimy to również w naszym bieżącym projekcie (w rzeczywistości nie pracowałem w żadnym projekcie, używając domyślnie gałęzi specyficznych dla zadania).

Tworzymy gałąź tylko przed wydaniem lub jeśli implementacja zajmuje dużo czasu (tzn. Obejmuje wiele iteracji / wydań). Szorstki rozmiar zadania można prawie zawsze oszacować wystarczająco dobrze, abyśmy z góry wiedzieli, czy potrzebujemy do tego osobnej gałęzi. Wiemy także, ile czasu pozostało do następnej wersji (publikujemy wersje co około 2 miesiące), więc łatwo jest sprawdzić, czy zadanie pasuje do czasu dostępnego przed następną wersją. W razie wątpliwości odraczamy go do momentu utworzenia gałęzi wydania, więc można rozpocząć pracę nad nim na linii głównej. Do tej pory musieliśmy utworzyć oddział specyficzny dla zadania tylko raz (za około 3 lata). Oczywiście twój projekt może być inny.

Péter Török
źródło
1
Jestem z Peterem. Mamy gałąź dla każdej obsługiwanej wersji, ale poza tym działamy w pniu. Używamy również ciągłej integracji, ale należy pamiętać, że oznacza to tylko, że będzie się kompilować, a nie że nie zepsuła istniejącej funkcjonalności, nawet podczas testów jednostkowych.
Ian
@Ian, oczywiście żaden test nie może zapewnić w rzeczywistości, że kod jest w 100% wolny od błędów ... mając ograniczone zasoby, dążymy do rozsądnego poziomu bezpieczeństwa (którego definicja jest specyficzna dla domeny i projektu). Należy również pamiętać, że CI może również uruchamiać testy integracji itp., Nie tylko testy jednostkowe.
Péter Török,
Działa, dopóki nie zawiedzie. Jeśli musisz zaimplementować poprawkę, zanim nowa funkcja będzie gotowa ... Lub jeśli nowe wydanie funkcji nie było tak gotowe na pierwotny czas, jak myślałeś, znacznie trudniej jest wycofać tę zmianę z kodu, jeśli nie używasz rozgałęzienia.
SoylentGray
@Chad, łatki do najnowszej wersji są wykonywane w odpowiedniej gałęzi wydania, bez ingerencji ze strony głównej. Nowe funkcje testujemy dość obszernie, więc wiemy, kiedy będą gotowe na najwyższy czas. To prawda, że ​​w naszym projekcie mamy stosunkowo niewiele dużych funkcji. A ponieważ jest to aplikacja internetowa po stronie serwera, dość łatwo jest nawet dodać flagę DB, aby selektywnie włączać / wyłączać funkcje. YMMV.
Péter Török,
LOL ok Źle zrozumiałem i pomyślałem, że właśnie masz bagażnik (z jednym wyjątkiem) Użyłem tej metody, a także w porządku dla małej grupy i częstych małych wydań, nie działało to dobrze w przypadku regularnych dużych wydań (3-6 miesięcy ) przedziały czasowe.
SoylentGray
1

To, co opisujesz wraz z rozwojem funkcji, to równoległe opracowywanie (jednoczesne opracowywanie ukierunkowane na różne wersje produktów) i wymaga to odpowiednich gałęzi. Możesz mieć jedną gałąź dla każdej wersji lub dla każdej funkcji, jeśli często będziesz musiał ponownie skomponować funkcje, które utworzą określoną wersję.

Innym sposobem, aby to zrobić, byłoby domyślnie pracować z pnia, ale utworzyć gałąź, jeśli spodziewasz się, że twoje zadanie wykroczy poza kolejną wersję. Oczywiście zawsze oznaczasz wydanie.

To, jakie podejście wybierzesz, zależy od tego, ile zarządzania możesz zrobić z góry. Jeśli typowa wersja nie ma tak naprawdę równoległego rozwoju, wybrałbym drugie podejście.

Jeremy
źródło
Zgadzam się i OP potwierdziło to: „Czasami funkcja jest prawie gotowa, a niektórzy programiści już zaczynają kodować następną funkcję ...”
Chris
Tak, ale nigdy nie musimy się ponownie komponować. Funkcje są zaimplementowane chronologicznie, a na przykład funkcje 1-4 muszą znajdować się w następnej wersji (powiedzmy 1.0). Może to być problematyczne tylko wtedy, gdy rozpoczęto prace nad wersją 5, która będzie później dostępna w wersji 2.0. Następnie musimy upewnić się, że zmiany te nie zostaną uwzględnione w tagu / wydaniu (1.0). Utworzenie oddziału przed wydaniem może rzeczywiście to naprawić.
Peter