Zalety i wady

Optymalizacja w celu przyspieszenia cyklu wydawniczego

Stosowanie Trunk Based Development wymusza zastosowanie Continuous Integration i pozwala pójść krok dalej, w stronę Continuous Delivery.

flowchart LR
    id1([Continuous Integration]) --> id2([Continuous Delivery]) --> id3([Continuous Deployment])

Gdy członkowie zespołu wysyłają i synchronizują swoje zmiany kilka razy dziennie, spełnienie teoretycznych wymagań Continuous Integration, by praca była synchronizowana co najmniej raz na dobę, jest formalnością.

Takie środowisko sprawia, że kod jest zawsze gotowy do wydania, zwłaszcza gdy pojawi się nagła potrzeba ze strony biznesu.

Zapewnienie stabilności i gotowość do wydania "na życzenie" oznacza też gotowość do Continuous Delivery

Zawsze gotowy do wydania, nawet (a może "zwłaszcza") gdy tematy są nieskończone

Wydanie nowej wersji jest możliwe, nawet jeśli zespół pracuje nad nową, skomplikowaną funkcją, która nie jest jeszcze w pełni gotowa lub po prostu jej uruchomienie doprowadzi do błędu.

Jeżeli pojawi się nagła potrzeba wprowadzenia zmiany, można się skupić tylko na niej i na ustabilizowaniu gałęzi głównej, by wydać nową wersję.

Wszystko to bez łapania się za głowę i zastanawiania, ile nagle jest tematów do przetestowania przed wydaniem.

Wielkość zespołu nie ma znaczenia

Jeśli wszyscy stosują się do zasad, wielkość zespołu nie wpływa na częstotliwość wydań.

Google od dekady używa swojego monorepo i Trunk Based Development mając tysiące inżynierów (prezentacja: 2012, John Micco - Tools for Continuous Integration at Google Scale).

Niektórzy się łatwo przystosują

Osoby, które praktykują model GitHub-flow w swojej pracy, zauważą, że wszystko jest podobne, jednak należy skupić się na utrzymaniu stabilności gałęzi głównej.

Mniejsze zmiany, mniej bolą

Jeśli zakres wprowadzonych zmian jest mały, a zmiany wysyłane są kilka razy dziennie, to ryzyko wystąpienia konfliktu jest znikome, a nawet jeśli do niego dojdzie, to łatwo go rozwiązać.

Małe zmiany oznaczają też przyjemniejsze i szybsze code-review.

Duplikacja kodu czarno na białym

Stosowanie Trunk Based Development pozwala szybko dostrzec, że ktoś odkrywa koło na nowo.

Przy długo żyjących branch'ach informacja o tym, że jakiś fragment kodu jest powielony lub problem rozwiązany wielokrotnie pojawia się dopiero podczas merge'owania. Często wtedy jest już za późno na reakcję, a próba wyprostowania tematu i zniwelowania duplikatu wiąże się z dodatkowym kosztem.

Nie każdy jest gotowy

Trunk Based Development wymaga narzędzi automatyzujących testy. Jeśli Twój system nie ma testów automatycznych, zacząłbym od odwróconej piramidy testów.

Jeśli członkowie zespołu nie mają kompetencji pozwalających im skutecznie pracować z Feature Flagami, warto ich najpierw odpowiednio wyszkolić.

Osoby, które wcześniej pracowały używając modelu Gitflow, mogą mieć trudności z wyobrażeniem sobie pracy w modelu Trunk Based Development. Może się okazać, że mają "pamięć mięśniową" do stosowania długożyjących branch'y. Najlepiej dać im spróbować i zobaczyć, że praca może być przyjemniejsza.