Trunk Based Development

Jak to robimy teraz i jakie są z tym problemy

Być może najczęstszym sposobem organizacji repozytorium z kodem mikroserwisu jest jakiś wariant modelu feature-branch. Wygląda on mniej-więcej tak:

• Mamy jakiś branch main, który zawiera ostatnią stabilną wersję kodu i trafia na produkcję automatycznie albo regularnie co jakiś czas,
• Czasem oprócz tego występują branche develop lub staging, które odpowiadają środowiskom nieprodukcyjnym, gdzie możemy w bezpieczny sposób testować, integrować i debugować nasze oprogramowanie,
• Jeśli chcesz zaimplementować nowy feature albo naprawić błąd, to tworzysz tzw. feature branch, bazując na main lub develop. Pracujesz na nim przez jakiś czas, a kiedy jesteś gotowy, tworzysz Pull Request (PR) i czekasz na recenzję i zgodę na merge, po którym twój kod trafia na produkcję od razu lub dopiero za jakiś czas.

Być może zauważasz już pewne minusy takiego podejścia. Na przykład, jeśli twój feature branch jest aktywny zbyt długo, to pojawią się rozbieżności pomiędzy nim a branchem bazowym, przez które musisz wykonać merge i rozwiązać konflikty. Każda taka operacja wiąże się z ryzykiem pomyłek i powstania błędów.

Często zmiany pochodzące z innych branchy psują twój kod. Może się to stać wielokrotnie w czasie pracy nad pojedynczym zadaniem. Nie ma też gwarancji, że testy automatyczne wszystko wyłapią, bo przecież one też zmieniają się pomiędzy merge’ami.

Jeśli implementowany feature jest skomplikowany, to PR zazwyczaj okaże się całkiem duży i jego pełne zrozumienie będzie wymagało sporego wysiłku poznawczego od recenzentów. Wiele osób podda się i tylko pobieżnie przejrzy kod – i prawdę mówiąc trudno im się dziwić!

Jeszcze kolejna sprawa to testowanie – żeby sprawdzić działanie swojego programu w środowisku innym niż lokalne, musisz najpierw zakończyć całą pracę a potem poczekać na zatwierdzenie. Kiedy wreszcie znajdziesz jakieś błędy i je naprawisz, to znowu musisz poczekać aż będzie się dało sprawdzić poprawki w środowisku deweloperskim.

Trunk Based Development w skrócie

Trunk Based Development (TBD) opiera się na następującym pomyśle: skoro mamy już CI/CD, siatkę bezpieczeństwa zapewnioną przez testy i możliwość łatwego publikowania kodu, dlaczego nie robić tego częściej niż tylko raz po zakończeniu pracy nad featurem?

Jeśli tak zrobimy, to nie będzie aż tylu konfliktów, bo członkowie zespołu będą częściej ściągać zmiany, i dużo szybciej otrzymamy też informację zwrotną.

Załóżmy więc na moment, że jest tylko jeden branch: trunk. Jeśli chcesz dodać feature, to pobierasz aktualną wersję repo i zaczynasz pracę. Po pewnym czasie masz gotowe coś, co chcesz sprawdzić poza środowiskiem lokalnym. Na tym etapie budujesz program, uruchamiasz testy i jeśli działają – commitujesz bezpośrednio do trunk. Gotowe!

Ta technika może wydawać się lepiej pasować do małych projektów i zespołów, ale korzystają z niej powodzeniem również duże firmy. Na przykład, Google stosuje wariant TBD w swoim monorepo.

Zawsze bądź gotowy na release!

Ważna jest tu reguła „release ready”: po każdym commicie trunk może być zbudowany i wydany w aktualnym stanie. Jeśli ostatni commit nie przechodzi testów, to trzeba go tylko wycofać i można wydać poprzedni stan kodu.

Ten wymóg może się wydawać nadmiernie restrykcyjny – przecież jakiś feature może być jeszcze niedokończony i nie chcemy wydawać go w aktualnym stanie. Dlatego w połączeniu z TBD można stosować feature flagi i inne techniki ukrywania niedokończonej funkcjonalności.

Uzasadnienie tej reguły to nie tylko fakt, że potrzeby biznesowe mogą nas zaskoczyć. Inna kwestia to że użytkownicy repo będą często pobierać kod z trunka, a my nie chcemy utrudniać pracy zepsutym buildem.

Code review

Jeśli commity trafią prosto na trunk, to jak robić code review? Jest na to kilka sposobów.

• Możesz zacząć stosować programowanie w parach i wówczas założyć, że kod, który powstał w parze jest już sprawdzony przez drugą osobę. Niestety wielu programistom i programistkom nie odpowiada taki styl pracy, więc być może nie jest to najlepsze rozwiązanie, chyba, że twojemu zespołowi to odpowiada.
• Inny sposób to tworzenie branchy, ale nie wiązanie ich jeden do jednego z feature’ami. Są to tylko krótkotrwałe branche do code review i może być ich dowolna ilość na feature. Jeśli masz jakiś commit albo kilka commitów i chcesz, żeby ktoś je przejrzał, to możesz założyć PR i przypisać osobę z zespołu. W ten sposób powstają mniejsze PR-y, które również są łatwiejsze do sprawdzenia.

• Możesz robić okresowy code review, w czasie którego sprawdzisz wszystkie ostatnie zmiany, np. przed wdrożeniem na produkcję, a potem wprowadzić poprawki w osobnych commitach. To jednakże może się okazać skomplikowane z uwagi na dużą ilość zmian do sprawdzenia.

Branche wydań (release branches)

Czasami, niezależnie od naszych najlepszych chęci, trunk nie jest gotowy do wdrożenia na produkcję, ale potrzeby biznesowe zmuszają nas do zrobienia tego właśnie teraz. Moglibyśmy poprawić wszystkie błędy, ale to wymaga czasu, i pojawia się ryzyko, że w międzyczasie inni kontrybutorzy wprowadzą błędy. W takiej sytuacji możemy utworzyć krótkotrwały release branch i naprawić tam problemy. Później, kiedy nasz program jest już na produkcji, praca może iść dalej normalnym trybem na trunku.

Podsumowanie

Trunk Based Development to alternatywna strategia kontroli wersji, która pozwala zespołom na szybszą integrację i feedback oraz zmniejsza liczbę konfliktów i ręcznych merge’y.

Najlepiej sprawdza się w małych i często współpracujących zespołach z szybkim procesem code review, a zatem dobrze nadaje się do mikroserwisów, ale może też być użyta w większych projektach. Powodzenie wymaga siatki testów automatycznych oraz dobrego procesu CI/CD.

Bibliografia

• Strona „Trunk Based Development”
• R. Potvin, J. Levenberg – Why Google Stores Billions of Lines of Code in a Single Repository – O tym jak Google używa TBD