Można odnieść wrażenie, że współczesne modele branchowania i zasady z nimi związane urosły do ogromnych rozmiarów, często stając się większym problemem niż rozwiązaniem. Poniżej opisujemy, jak uprościliśmy ten proces w NetSparku.
Master
Zawsze utrzymujemy gałąź master (lub main) w stabilnym stanie. To właśnie z niej publikowane są wszystkie oficjalne wersje systemu.
Dev
Na co dzień rozwój nowych funkcjonalności odbywa się na gałęzi dev. Każde zadanie realizowane jest na osobnej gałęzi utworzonej z dev, a następnie wraca do niej za pomocą Pull Requesta po zakończeniu implementacji i przejściu code review.
W trakcie prac regularnie publikujemy wersje testowe oznaczone jako Release Candidate, na przykład:
2.1.0-rc.1
Pozwala to testerom oraz klientom zweryfikować nowe funkcjonalności jeszcze przed oficjalnym wydaniem.
Pod koniec każdego cyklu wydawniczego, gdy dev przejdzie wszystkie testy i osiągnie wymagany poziom stabilności, jest mergowany do mastera, co automatycznie skutkuje wydaniem nowej wersji.
Każde wydanie planujemy z wyprzedzeniem, dzięki czemu od początku wiemy, jakie funkcjonalności powinny znaleźć się w najbliższej wersji.
Naprawianie błędów
Jeżeli podczas prac nad kolejną wersją pojawi się krytyczny błąd w aktualnie opublikowanym wydaniu, tworzymy gałąź hotfix bezpośrednio z mastera.
Po przygotowaniu poprawka trafia jednocześnie do:
- mastera, gdzie publikowana jest nowa wersja poprawkowa,
- deva, aby znalazła się również w kolejnym wydaniu.
Jeżeli błąd nie jest krytyczny i może poczekać do następnej wersji, naprawiamy go wyłącznie na gałęzi dev.
Po opublikowaniu poprawki zwiększamy numer wersji na ostatniej pozycji, np. 2.0.1 → 2.0.2.
Strategia mergowania
Dla aktywnie rozwijanej gałęzi dev stosujemy strategię Squash Merge.
Dzięki temu historia zmian pozostaje czytelna. Programiści często podczas code review wykonują wiele drobnych commitów z podobnymi komunikatami. Pozostawienie ich wszystkich sprawia, że historia bardzo szybko staje się nieczytelna. Zamiast tego cały Pull Request trafia do dev jako jeden logiczny commit z jasnym opisem wykonanej pracy.
Natomiast podczas wydawania nowej wersji i mergowania dev do mastera korzystamy z klasycznego Merge Commit. Dzięki temu zachowujemy informację o zakończonym cyklu wydawniczym oraz możemy w prosty sposób prześledzić historię kolejnych wydań.
Tagowanie wydań
Każde oficjalne wydanie publikowane z gałęzi master otrzymuje tag odpowiadający numerowi wersji.
Dzięki temu w dowolnym momencie możemy wrócić do konkretnego wydania, odtworzyć jego stan lub przygotować poprawkę dla starszej wersji bez wpływu na bieżący rozwój systemu. Jest to szczególnie przydatne w sytuacji, gdy klient korzysta jeszcze z wcześniejszego wydania i wymaga usunięcia krytycznego błędu bez konieczności aktualizacji do najnowszej wersji.
Im prostszy proces, tym mniej czasu zespół poświęca na zarządzanie gałęziami, a więcej na rozwój produktu.
