Blog

Dewelopment oparty o gałąź główną (Trunk-based development) to sposób pracy z repozytorium kodu, w którym zmiany ewidencjonuje się od razu w głównej gałęzi. Jest antagonistyczny w stosunku do git-flow, przez co wiele osób uważa go za kontrowersyjny. Jest za to skuteczny. W raporcie „Stan DevOps – Raport 2017” trunk-based development jest jednym z wyróżników najlepiej radzących sobie przedsiębiorstw. Dziś opowiem o rozwoju opartym o gałąź główną. Artykuł porównujący to podejście oraz git-flow niebawem.

Trunk-based development, jak sama nazwa wskazuje, to rozwijanie oprogramowania w oparciu o trunk (pień, nomenklatura z SVN) czy też master(git). Według tej metody albo w ogóle nie powinno się tworzyć odgałęzień, albo powinny żyć nie więcej niż dzień. Czyli jak najczęściej komitujemy i wrzucamy do pnia/mastera w naszym „centralnym” repozytorium. W Git wypychanie zmian (push) jest równie ważne co częste zmiany (commit), bo ściśle rzecz biorąc, nasze lokalne repozytorium jest odgałęzieniem centralnego, kanonicznego repozytorium. Inaczej mówiąc, może być niewierną kopią.

Zwrot „wrzucamy do pnia/mastera” można implementować na dwa sposoby: pierwszy to wprowadzanie zmian prosto, bezpośrednio do mastera. Tak jak to wyglądało w starym, dobrym SVN. Drugi to odciągnięcie z mastera gałęzi i scalenie jej za pomocą pull requestu. I to wszystko w trakcie jednego dnia, bo inaczej gałąź żyje już za długo i tracimy korzyści płynące ze stosowania dewelopmentu opartego o gałąź główną. Oczywiście ten jeden dzień jest umowny, ale starzy wyjadacze i amerykańscy naukowcy empirycznie uznali, że jeden dzień ma sens.

Jeden dzień

Jeden dzień? Króciutko. Co (w co najwyżej!) w jeden dzień zdąży się naklepać, przejrzeć (zreviewować) i scalić (zmerge’ować)? Niedużo. I o to chodzi. Wprowadzane zmiany będą malutkie. Ma to szereg cudownych następstw:

• przede wszystkim informacja zwrotna! Jest szybsza i bardziej konkretna. Gdy cokolwiek się „wysypie” to o ileż łatwiej znaleźć zmianę w 3 linijkach niż w 100. W ten sposób częściowe rozwiązanie problemu sami sobie podajemy na tacy;
• ciągła integracja działa naprawdę na tym, co trafi na produkcję;
• natychmiast pobieramy zmiany wprowadzone przez innych programistów;
• nie jesteśmy w stanie za jednym zamachem stworzyć skomplikowanej funkcjonalności. Zatem wrzucamy do mastera kolejne elementy/etapy naszej pracy. Dzięki temu współpracownicy obserwują rozwój funkcjonalności, nasz tok myślenia i w razie potrzeby mogą szybko skorygować nasz kurs;
• przegląd kodu (code review) będzie znacznie lepszej jakości. Zazwyczaj jest tak, że im mniej mamy do przejrzenia, tym skrupulatniej to zrobimy;
• utrapienia związane ze scalaniem zmian (merge hell) są niemal wyeliminowane, bo porcja danych jest mała i czas między odciągnięciem a scaleniem jest znikomy;
• unikamy fazy integracji wielu gałęzi, która może się nieoczekiwanie i nieprzewidywalnie wydłużać.

Zwiększenie zasobów

Z nie tak bardzo cudownych konsekwencji warto wymienić, że trzeba dbać, aby zmiana nie psuła całości oraz o to, że mogą być potrzebne większe zasoby sprzętowe.

Zmiana nie powinna psuć całości – jest to bardzo ważna zasada, która wymaga także wprowadzenia kilku dodatkowych praktyk: zakaz ewidencjonowania czegokolwiek do popsutej kompilacji. Każdy powinien wiedzieć, jak cofnąć system do poprzedniej wersji oraz wyznaczyć sobie określony przedział czasowy, w którym naprawimy kompilację lub cofniemy zmianę, aby nie przeszkadzać zespołowi. Dzięki temu, że każda kompilacja działa, mamy pewność, że przywrócenie systemu do poprzedniej wersji pomoże oraz łatwiej będzie nam zidentyfikować błąd.

Zwiększenie zasobów sprzętowych może okazać się konieczne, gdyż więcej instancji CI będzie wykonywało się równolegle. Chodzi o to, że na każdym zbiorze zmian wykonuje się komplet testów. Testy wykonują się (zazwyczaj) tak samo długo, niezależnie od wielkości zmian w systemie. Jeśli więc będziemy wprowadzać dużo małych zmian, a na każdej zmianie, zgodnie z zaleceniami CI, musi wykonać się zestaw testów, to będziemy mieli uruchomione wiele instancji testów, każda na innej zmianie. Nasze środowisko może być do tego nieprzystosowane. Może być potrzebne jego rozszerzenie.

Podsumowując, dewelopment oparty o gałąź główną, jako jedyny wśród sposobów pracy z rozproszonym system kontroli wersji, daje możliwość prawdziwej ciągłej integracji, ale jak wszystko, ma swoje wady i zalety.