Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Trunk Based Development w pracy zespołowej

Tylor Borgeson Software Engeneer / REWE digital
Poznaj kontrowersyjny model Trunk Based Development i zobacz, w jaki sposób mógłby usprawnić pracę Twojego zespołu.
Trunk Based Development w pracy zespołowej

Będę tutaj omawiał różne sposoby, na które inżynierowie mogą ulepszać swoje oprogramowanie przez doskonalenie procesów i praktyk. Wszystko, co zamierzam przekazać w tym artykule, przeżywałem jako konsultant oprogramowania w ThoughtWorks oraz w mojej obecnej pracy w dużej firmie z Niemiec. Jako ktoś, kto lubi opowiadać się za rzeczami, które są korzystne dla wydajności zespołu deweloperskiego, wiele czasu spędziłem na przełamywaniu oporu przed praktykami, które moim zdaniem takie są. 

Jednym z moich ulubionych tematów jest Trunk Based Development (TBD). Tak się składa, że temat ten jest również mocno hejtowany przez innych programistów. Uwielbiam ten temat, ponieważ nie lubię stereotypów. TBD zwalcza właśnie wiele z nich, których ofiarą pada z resztą wielu programistów. 

Kiedy ludzie spoza naszej branży słyszą zwrot „programista”, myślą o całej mitologii, która się z tym terminem kojarzy. Programista to dla nich mityczne stworzenie, które zakłada słuchawki, pracuje na 3 lub 4 monitorach i rozmawia z zielonymi postaciami na czarnych ekranach. To ktoś, kto otrzymuje zadanie, idzie pracować do swojej jaskini, i siedzi tam, dopóki go nie ukończy. 

Doskonałym tego przykładem jest twórca gry 2048. Plotka głosi, że 19-latek zbudował tę grę w jeden weekend, a po 2,5 tygodniach od premiery zagrano w nią 100 milionów razy. Jest to doskonale spersonifikowany stereotyp twórcy oprogramowania. Chociaż czasami jest to fajne, to ogólnie uważam, że stereotyp ten negatywnie wpływa na postrzeganie pracy zespołowej... a Trunk Based Development to forma pracy, której nie da się wdrożyć, gdy mamy w zespole tego stereotypowego programistę. 

TBD wymaga pracy zespołowej, empatii i otwartości, a takie rzeczy najbardziej uwidaczniają się podczas pracy zespołowej, a nie indywidualnej. 


Czym jest Trunk Based Development?

Trunk Based Development to proces tworzenia oprogramowania zdefiniowany przez trunkbaseddevelopment.com (doskonałe źródło wiedzy o TBD) jako:

Model, w którym programiści razem pracują nad kodem, tworząc jedną gałąź, którą nazywamy „trunk”. Opierają się presji tworzenia innych gałęzi przez wdrażanie sprawdzonych technik. Unikają oni w ten sposób piekła związanego ze scalaniem kodu, zepsutych buildów i żyją długo i szczęśliwie.

Zamiast tworzenia feature brancha i scalania go z gałęzią główną, każda funkcja jest dostarczana w małych kawałkach, z których każdy trafia do mastera, gdy jest gotowy. Innymi słowy, zespół tworzy produkt bez użycia gałęzi. 

Zdaję sobie sprawę, że większość programistów, którzy już mają doświadczenie, odrzuca TBD, gdy tylko widzi „pushed onto master”. Spróbuję jednak zaadresować najczęstsze obawy.


Dlaczego to takie ważne?

Jeszcze raz powrócę do czterech kluczowych metryk zdefiniowanych w Accelerate. Oto bezpośredni cytat z książki:

Nasze badania podkreślają praktyki niezbędne do udanej transformacji technologicznej. Należą do nich kontrola wersji, automatyzacja wdrażania, ciągła integracja, Trunk Based Development oraz architektura oparta na luźnych powiązaniach.

Praktyki te nie tylko są istotne, ale również niezbędne. A na powyższej liście znajduje się również Trunk Based Development. Poza faktem, że niewielkie zmiany kodu wprowadzone w formule Trunk Based Development powodują znacznie mniej konfliktów przy scalaniu (co oznacza szczęśliwszych programistów), taka forma pracy pomaga zespołom usprawnić kilka obszarów:


Częstotliwość wdrażania i Mean Time to Recovery

TBD w połączeniu z pipelinem CI/CD powoduje, że każdy „zielony” commit (tj. którego poprawność została sprawdzona za pomocą testów) jest wgrywany na produkcję. Wypychanie każdej zmiany do mastera oznacza wysoki poziom integracji i potencjalnie częsty deployment. Byłem w zespołach, w których robiło się od 30 do 40 wdrożeń jednego dnia. Zwiększona częstotliwość wdrażania jest drugą z czterech kluczowych metryk.

Pamiętam sytuację z tego samego zespołu, w której wdrożyliśmy coś na front-end. Aplikacja polegała mniej więcej na czymś w rodzaju „wyświetl listę elementów z ich odpowiednimi atrybutami”. Zapomnieliśmy jednak sprawdzić nulle i wartości niezdefiniowane, co spowodowało błąd.

Oczywiście może się to każdemu zdarzyć, bez względu na to, jakich procesów się używa… ale zadziwiające było to, że zauważyliśmy błąd od razu i byliśmy w stanie napisać test oraz naprawić problem. Całość wylądowała w repozytorium, a potem na produkcji w mniej niż 5 minut. Niski Mean Time to Recovery to trzecia z czterech kluczowych metryk.

Ta zdolność do szybkiego wdrażania zmian za pomocą Trunk Based Development oraz CI/CD pozwala w przypadku problemu tworzyć kod, który go rozwiązuje, zamiast zachęcać do cofania się do ostatniej działającej wersji.


Jakość kodu i dzielenie się wiedzą

Największe obawy, jakie towarzyszą zespołom przy rozważaniu TBD, to to, że ucierpi jakość kodu i zwiększy się prawdopodobieństwo popełnienia błędów. Wydaje mi się jednak, że jest na odwrót — wierzę, że TBD skutkuje znacznie bardziej stabilnym i lepszym kodem. Większość zespołów korzystających z feature branchy korzysta też z pull requestów, dzięki którym inni programiści w zespole sprawdzają i komentują kod napisany przez kogoś innego.

Ponieważ w TBD nie ma osobnych gałęzi na różne funkcje, oznacza to również brak pull requestów. To nie musi być problem. Większość zespołów chce tylko zasady „czterech oczu”, która zakłada, że co najmniej dwóch programistów powinno przejrzeć i zatwierdzić cały kod, który będzie scalony z gałęzią główną. Mój zespół również stosuje zasadę 4 oczu, ale robimy to za pomocą programowania w parach. Ponieważ w TBD nie ma code review, to programowanie w parach staje się konieczne.

Dwóch programistów pracujących nad rozwiązaniem danego problemu to często lepsze rozwiązanie niż jeden programista pracujący samemu. Każdy z nich ma różny poziom doświadczenia i znajomość stosu technologicznego i/lub systemu, który opracowuje zespół. Praca w parach zapewnia możliwość uczenia się od członków zespołu w szybkim tempie.

Wyobraź sobie, jak szybko junior lub nowo zatrudniona osoba rozwinie się podczas pracy w parze z seniorem. Nauczy się stylu kodowania w firmie, a decyzje projektowe będą podejmowane przed wykonaniem pracy, zamiast pojawiać jako feedback w code review. Wspólne pisanie kodu również sprawia, że tworzy się mniej silosów wiedzy.


Praca zespołowa

Programowanie w parach jest również formą pracy zespołowej, ale TBD usprawnia teamwork, ponieważ wymaga empatii od każdego z członków.  Dla starszego programisty, który od wielu lat pracuje nad systemem, brak seniora, który komentuje kod tych mniej doświadczonych, może być niekomfortowy. 

Empatia jest jednak ogólnie pożądaną cechą u każdego członka zespołu. Wiara w to, że koledzy i koleżanki są w stanie dobrze wykonywać swoje zadania, jest istotna dla budowania zaufania i pewności siebie w zespole. W większości przypadków seniorzy są inteligentni i mają doświadczenie. Inni jednak też są inteligentni. Jeśli senior chce zobaczyć kod napisany przez juniora, to może się z nim sparować, a junior będzie pisał bardzo dobry kod wcześniej, niż ktokolwiek się tego spodziewa. 


Potencjalne wyzwania:


Niedokończone funkcje

Nikt nie chce przekazywać niedokończonych funkcji dla klientów. Aby obejść ten problem, zespoły mogą wdrożyć feature toggles, za którymi ukrywa się niedokończone funkcje. Kiedy dana funkcja nie jest skończona, to jest to również wyłączone, a gdy funkcja zostanie ukończona, to przełącznik można włączyć (lub całkowicie usunąć). Dzięki feature toggle zespoły mogą nawet przeprowadzać testy A/B lub Canary Releases.


Testy i monitorowanie

Trunk Based Development wymaga od zespołu silnego zestawu testów i dobrego monitorowania w celu jak najszybszego wykrycia błędów. Im szybsza pętla informacji zwrotnej, tym lepiej. Popsuty pipeline staje się priorytetem, dla tych, którzy go popsuli, aby zapobiec ściągnięciu błędnego kodu przez innych. Można temu łatwo zapobiec, wprowadzając bardzo małe zmiany, mając środowisko programistyczne możliwie najbardziej zbliżone do środowiska testowego i produkcyjnego oraz uruchamiając zadania z pipeline'u lokalnie przed wypchnięciem kodu (np. za pomocą git hooks).


Podsumowanie

Znam wiele zespołów, które wdrożyły Trunk Based Development i żaden z nich nie wrócił do bardziej popularnego modelu opartego o pull requesty. Niektóre zespoły przestawiają się nawet na TBD z takich powodów, jak chęć programowania w parach. Myślę, że warto tutaj pamiętać, że jedna rzecz nie zadziała dla wszystkich. Ważne jest, aby zespoły pracowały w sposób najbardziej dla nich odpowiedni.

Znałem kiedyś zespół, który miał nieparzystą liczbę programistów, co oznacza, że nie mieli możliwości sparowania wszystkich zadań, a czasem wypalali się z powodu zbyt częstego parowania. Dlatego użyli krótkożyjących gałęzi, które były tworzone i scalane tego samego dnia, co również liczy się jako TBD.

Następny krok: wypróbuj Trunk Based Development, zaadaptuj według potrzeb Twojego zespołu i ciesz się wynikami.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej