Najlepsza praktyka z rozgałęziającym się kodem źródłowym i cyklem życia aplikacji

Jesteśmy małym sklepem niezależnych dostawców oprogramowania i zwykle co miesiąc wysyłamy nową wersję naszych produktów. Używamy Subversion jako naszego repozytorium kodu, a Visual Studio 2010 jako nasze IDE. Wiem, że wiele osób opowiada się za Mercurial i innymi rozproszonymi systemami kontroli źródła, ale w tej chwili nie widzę, jak moglibyśmy z nich skorzystać, ale mogę się mylić.

Naszym głównym problemem jest synchronizacja gałęzi i głównego pnia.

Oto jak dzisiaj robimy rzeczy:

1. Wydaj nową wersję (automatycznie utwórz tag w Subversion)
2. Kontynuuj pracę nad głównym bagażnikiem, który zostanie wydany w przyszłym miesiącu

Cykl powtarza się co miesiąc i działa idealnie. Problem powstaje, gdy konieczne jest zwolnienie pilnej wersji usługi. Nie możemy zwolnić go z głównego pnia (2), ponieważ jest on w fazie intensywnego rozwoju i nie jest wystarczająco stabilny, aby można go było natychmiast zwolnić.

W takim przypadku wykonujemy następujące czynności:

1. Utwórz gałąź z tagu, który utworzyliśmy w kroku (1)
2. Naprawa błędów
3. Przetestuj i wypuść
4. Wciśnij zmianę z powrotem do głównego bagażnika (jeśli dotyczy)

Naszym największym problemem jest połączenie tych dwóch (gałąź z główną). W większości przypadków nie możemy polegać na automatycznym scalaniu, ponieważ np .:

• wprowadzono wiele zmian w głównym bagażniku
• scalanie złożonych plików (takich jak pliki Visual Studio XML itp.) nie działa zbyt dobrze
• inny programista / zespół wprowadził zmiany, których nie rozumiesz i nie możesz ich po prostu scalić

Więc to, co Twoim zdaniem jest najlepszą praktyką, aby zachować synchronizację tych dwóch różnych wersji (gałęzi i głównej). Co robisz?

Myślę, że twoje podejście do rozgałęziania i łączenia jest OK, ale jeśli głównym problemem jest to, że baza kodu jest dość niestabilna, na tym musisz się skupić i zminimalizować.

Najważniejsze, aby upewnić się, że baza kodu ma dobry rozdział problemów . Zależności między różnymi komponentami należy odizolować i zmniejszyć. To powinno rozwiązać większość twoich problemów. Pomocne będzie również przestrzeganie takich praktyk, jak zasada pojedynczej odpowiedzialności.

Jeśli zajdzie poważna zmiana architektoniczna, powinna nastąpić we własnym oddziale, a następnie w pełni przetestowana i „stabilna” (w granicach rozsądku) z powrotem w główną. Może to być bolesne i trudne, ale także rzadkie. Jeśli masz dobre praktyki testowania, ryzyko jest zminimalizowane.

Może także pomóc w przejściu na rozproszony system kontroli wersji. To powinno dać ci stabilny pień, z różnymi funkcjami scalonymi z różnych gałęzi, gdy będą gotowe. Nadal będziesz odczuwać scalanie bólu, jeśli kod będzie zbyt współzależny, ale będziesz mieć większą kontrolę.

Patrząc na to z innej perspektywy, rozważ także zwiększoną komunikację między zespołem. Prowadź regularne spotkania w stylu agile. Zastanów się, gdzie siedzą członkowie zespołu i jak to może pomóc. Jeśli konieczne jest złożone scalenie, może nie być to takie złe - zastosuj podejście programowania w parach, które zapewni zrozumienie obu stronom.

Patrzę na to z odwrotnej strony:

• Trunk powinien zawsze być kodem gotowym do produkcji (to znaczy po pierwszym wydaniu początkowym).
• Powinna istnieć gałąź typu programistycznego, która działa równolegle do linii głównej, w której odbywa się miesięczny rozwój. Co miesiąc, jeśli chodzi o czas wydania, jest on łączony w pień, testowany, a następnie wydawany.
• Poprawki można następnie łatwo wprowadzić w bagażniku i zalogować, i zawsze można je pomyślnie wdrożyć. Następnie zrób łatkę z poprawki i zastosuj ją do swojego działu rozwoju.

Oczywiście ten przepływ pracy jest znacznie lepiej dostosowany do czegoś, co nie jest SVN, ponieważ dobre rozgałęzianie i łączenie jest czymś, co jest dość bolesne w SVN, niezależnie od przepływu pracy. Z mojego doświadczenia wynika, że ​​scalanie w SVN powinno prawie zawsze odbywać się ręcznie, ponieważ po prostu nie działa i nie ma realnego sposobu na obejście tego.

Ostatnio jako ostatni wynik opowiadałem się za filozofią „rozgałęziania i łączenia”. Myślę, że niefortunną prawdą jest, że radzenie sobie z łączeniem się kodu z gałęzi nie jest problemem technicznym, ale jest zadaniem trudnym poznawczo: Myślę, że po prostu ludzki mózg nie śledzi wystarczającej liczby szczegółów, aby to ułatwić. Co więcej, nie widziałem jeszcze, aby rozgałęzianie i łączenie faktycznie działało w praktyce. Kiedy kod zostanie rozgałęziony, doświadczenie mówi mi, że nie jest niczym innym, jak kłopot z ponownym scaleniem go.

Zdyscyplinowane podejście do wydania głównego działa dobrze.

Rozgałęzienie SVN nie zostało zaprojektowane z myślą o elastyczności. Sugerowałbym, że twój pierwszy problem leży w SVN; przejście od tego otworzy nowe opcje.