Strategia tworzenia gałęzi: droga do sukcesu

Obecnie niemal wszystkie systemy kontroli wersji obsługują gałęzie, czyli niezależne linie prac wyprowadzone z jednej centralnej bazy kodu. W zależności od systemu kontroli wersji, gałąź główna może być nazywana główną lub domyślną. Programiści mogą tworzyć własne gałęzie wyprowadzone z głównej gałęzi kodu i pracować niezależnie, równolegle do tej gałęzi.

Tworzenie gałęzi umożliwia zespołom programistów łatwą współpracę w obrębie jednej centralnej bazy kodu. Gdy programista tworzy gałąź, system kontroli wersji tworzy kopię bazy kodu z tego punktu w czasie. Zmiany wprowadzone w gałęzi nie wpływają na pracę innych programistów w zespole. To oczywiście dobrze, ponieważ funkcje, nad którymi jeszcze trwają prace, mogą powodować niestabilność, co w przypadku prowadzenia wszystkich prac w obrębie głównej gałęzi kodu powodowałoby znaczne zakłócenia. Jednak gałęzie nie muszą pozostawać w całkowitej izolacji. Programiści mogą z łatwością ściągać zmiany od innych programistów, aby współpracować nad funkcjami i mieć pewność, że ich gałąź prywatna nie zacznie zbyt mocno odbiegać od gałęzi głównej.

Często modele tworzenia gałęzi różnią się między zespołami i są przedmiotem zażartych dyskusji prowadzonych w społeczności programistycznej. Jednym z kluczowych tematów jest ilość prac, jaka powinna pozostać w gałęzi, zanim gałąź zostanie z powrotem scalona z gałęzią główną.

Tworzenie gałęzi wydań odnosi się do koncepcji, która zakłada, że wydanie jest w całości zamknięte w obrębie gałęzi. Oznacza to, że na późnym etapie cyklu tworzenia oprogramowania menedżer wydania tworzy gałąź z gałęzi głównej (na przykład o nazwie „Gałąź programistyczna 1.1”). Wszystkie zmiany wprowadzone w wydaniu 1.1 muszą zostać zastosowane dwukrotnie: po pierwsze do gałęzi 1.1, a po drugie do głównej linii kodu. Praca z dwoma gałęziami oznacza dodatkową pracę dla zespołu, a przez to łatwo zapomnieć o scaleniu obydwu gałęzi. Gałęzie wydań bywają nieporęczne i trudne w zarządzaniu, ponieważ wiele osób pracuje na tej samej gałęzi. Każdy z nas poczuł kiedyś na własnej skórze, co oznacza konieczność scalenia wielu różnych zmian w jedną gałąź. Jeśli musisz utworzyć gałąź wydania, utwórz ją możliwie jak najbliżej rzeczywistej daty wydania.

Gałęzie funkcji często są połączone z flagami funkcji — „przełącznikami”, które umożliwiają włączanie lub wyłączanie funkcji w obrębie produktu. To ułatwia wdrażanie kodu w gałęzi głównej i kontrolowanie momentu aktywowania funkcji, co z kolei pozwala w prosty sposób przeprowadzić wstępne wdrożenie kodu, zanim jeszcze funkcja zostanie ujawniona użytkownikom końcowym.

W Atlassian koncentrujemy się na przepływie pracy, w którym gałąź jest tworzona dla każdego zadania. W każdej organizacji funkcjonuje naturalny sposób podziału pracy na pojedyncze zadania w systemie śledzenia zgłoszeń, takim jak Jira. Wówczas zgłoszenia zaczynają pełnić dla zespołu funkcję centralnego punktu kontaktu w sprawie danej jednostki pracy. Tworzenie gałęzi zadań nazywanych również gałęziami zgłoszeń umożliwia bezpośrednie połączenie tych zgłoszeń z kodem źródłowym. Każde zgłoszenie jest wdrażane we własnej gałęzi z uwzględnieniem klucza zgłoszenia zawartego w nazwie gałęzi. Dzięki temu od razu widać, który kod odpowiada za wdrożenie którego zgłoszenia: wystarczy spojrzeć na klucz zgłoszenia w nazwie gałęzi. Taki poziom przejrzystości ułatwia stosowanie konkretnych zmian do gałęzi głównej lub dowolnej innej starszej gałęzi wydania, przy której prace trwają od dłuższego czasu.

Metodyka Agile koncentruje się na historyjkach użytkowników, dlatego gałęzie zadań dobrze sprawdzają się procesie programistycznym Agile. Każda historyjka użytkownika (lub poprawka błędu) funkcjonuje we własnej gałęzi, co ułatwia ustalenie, które zgłoszenia są aktualnie w toku, a które są gotowe do wydania.

Wszyscy znamy trudności towarzyszące próbom zintegrowania wielu gałęzi w jedno sensowne rozwiązanie. W tradycyjnych, scentralizowanych systemach kontroli wersji, takich jak Subversion, scalanie było niezwykle uciążliwą operacją. Jednak nowsze systemy kontroli wersji, takie jak Git i Mercurial, przyjmują inne podejście do monitorowania wersji plików funkcjonujących w różnych gałęziach.

Prace nad gałęziami trwają zazwyczaj krótko, co ułatwia ich scalanie i sprawia, że są bardziej elastyczne w całej bazie kodu. Dzięki połączeniu możliwości częstego i automatycznego scalania gałęzi w ramach ciągłej integracji (CI) oraz krótkotrwałych gałęzi, które zawierają mniej zmian, zespoły korzystające z systemów Git i Mercurial mogą zapomnieć o trudnościach, jakie dotychczas wiązały się ze scalaniem.

To właśnie sprawia, że tworzenie gałęzi zadań tak dobrze się sprawdza.

System kontroli wersji tylko w pewnym stopniu wpływa na wynik scalania. Automatyczne testowanie i ciągła integracja mają również krytyczne znaczenie. Większość serwerów CI może automatycznie przeprowadzać testy nowych gałęzi, drastycznie zmniejszając liczbę „niespodzianek” przy końcowym scalaniu z gałęzią nadrzędną i ułatwiając tym samym zapewnianie stabilności głównej linii kodu.