W tym poście dowiesz się, czym jest podejście Trunk Based Development do wytwarzania kodu. Wyjaśnię, na czym ono polega, jakie ma swoje wady i zalety.
Z pewnością słyszałeś o różnych podejściach do zarządzania kodem w systemach kontroli wersji. Jednym z tych podejść jest Trunk Based Development (TBD). W moim ostatnim poście opisałam inne i zdecydowanie bardziej popularne podejście do wytwarzania kodu oparte o Git Flow. Dziś zatem przyjrzymy się uważnie temu drugiemu podejściu — Trunk Based Development. Choć nazwa brzmi dość technicznie, to podejście samo w sobie jest dość proste i... dla niektórych nawet rewolucyjne!
W TBD cała magia dzieje się wokół jednego głównego brancha w repozytorium – trunka. Jest to gałąź główna kodu, która znajduje się na produkcji. Analogiczną nazwą do trunka jest main lub master z podejścia Git Flow.
Programiści, pracując nad nową funkcjonalnością, tworzą nowe branche i odbijają je od trunka. Nie są to duże i opasane branche, lecz małe i krótkotrwałe gałęzie, które szybko – najczęściej w ciągu jednego dnia – są scalane (merge’owane) z trunkiem.
Tyle i aż tyle.
Czemu tak?
Aż kusi, żeby poszukać dziury w całym. W końcu w Git Flow mamy developa, z niego odbijamy feature branche, aby następnie zebrać pracę w release brancha, by finalnie wrzucić pracę zespołu na produkcję, czyli zmergować zmiany do maina.
A tutaj jedziemy na trunku (tudzież mainie :P), domergowujemy zmiany i koniec. Piekła nie ma, hulaj dusza. No to czemu nie jest to najpopularniejsze podejście, skoro jest takie proste, hę?
Najtrudniejsze w tym, co proste
W TBD zmiany trafiają na produkcję szybko i regularnie. Nie ma długiego czekania na scalenie branchy czy rozwiązywania konfliktów, bo każdy merge odbywa się praktycznie natychmiast. Ponieważ wprowadzane zmiany są małe i regularnie trafiają do trunk’a, unikamy ogromnych konfliktów, takich jak tych doświadczanych przy scalaniu długotrwałych gałęzi (patrz: feature branche w Git Flow). Regularne merge wymuszają na zespole częstsze testowanie i szybkie code review. To oznacza mniej błędów i bardziej stabilny kod w trunku.
Druga strona medalu
TBD nie jest dla każdego. Wymaga wysokiego poziomu dyscypliny od programistów – muszą regularnie commitować i testować swój kod. Jak wspomniałam, każda zmiana musi być szybko przetestowana i wdrożona, a to może wymagać zaawansowanej infrastruktury. Bez dobrych narzędzi do CI/CD i dużej ilości testów automatycznych praca w TBD może być uciążliwa. W TBD lepiej unikać wielkich refaktoryzacji czy rozbudowanych funkcjonalności, bo trudno je zaimplementować w małych krokach. Wymaga to dobrego planowania i podziału zadań.
Komu, komu?
Trunk Based Development najlepiej sprawdza się w dynamicznych zespołach, które stawiają na szybkie dostarczanie wartości. Jeśli Twoja organizacja preferuje regularne, małe zmiany i może zainwestować w CI/CD, TBD może być strzałem w dziesiątkę. Z kolei jeśli pracujesz nad projektem o długim cyklu życia lub wymagającym rygorystycznych testów, Git Flow może być bardziej odpowiedni.
A Ty? Jakie podejście stosujesz w swoim zespole – szybki Trunk Based Development czy bardziej zorganizowany Git Flow? Podziel się swoimi doświadczeniami w komentarzach!
Comments