Model pracy trunk-based development
W modelu trunk-based development programiści tworzą gałęzie, na których opracowują wszelkie zmiany. Ich zakres jest bardzo mały, dlatego prace nad nimi można zakończyć nawet w ciągu kilku godzin. Istotą modelu jest fakt, że na tych właśnie gałęziach przechowywane są jedynie drobne zmiany, a nie całe projekty.
Podstawą działania w tym modelu jest brak blokowania innych programistów podczas pracy nad zmianami. Wszelkie działania powinny być prowadzone w taki sposób, by umożliwić wydanie oprogramowania z głównej gałęzi. Przydatny jest tu także zestaw dobrych testów, który pozwoli na dokładne sprawdzenie zmian przed ich złączeniem i wdrożeniem.
Trunk-based development to jedno z dwóch najbardziej popularnych modeli GIT'a. Drugim jest gitflow, w którym programiści tworzą gałąź rozwojową od głównej gałęzi i to na niej pracują aż do momentu, gdy będą pewni wszystkich zmian.
Kiedy warto wdrożyć trunk-based development?
Trunk-based development jest idealnym wyborem, gdy projekt składa się z kilku małych, powiązanych ze sobą obszarów funkcjonalności lub gdy potrzebna jest szybka reakcja na zmieniające się wymagania dotyczące danego projektu.
Należy również podkreślić, że Trunk-based development pozwala na skuteczne zaadresowanie problemów, które pojawiają się w zespołach. Celem zastosowania tego modelu jest także zwiększenie częstotliwości wydawania zmian oraz minimalizacja tzw. Lead Time, czyli czasu od momentu zdefiniowana biznesowego do wdrożenia rozwiązania i przekazania go klientowi.
Aby praca w modelu trunk-based development rzeczywiście była skuteczna i efektywna, konieczne będzie odpowiednie przeszkolenie zespołu.
Jakie wady ma trunk-based development?
Przede wszystkim, warto pamiętać o naczelnej zasadzie tego podejścia – wprowadzane zmiany nie mogą psuć całości. Bardzo ważne jest, by wiedzieć, jak w razie potrzeby cofnąć system do wersji sprzed wprowadzenia ostatnich zmian i zrobić to w określonym przedziale czasowym, by nie utrudnić czy nawet uniemożliwić pracy reszty zespołu.
To wskazuje nam na główną wadę tej metody, czyli w przypadku braku jasnej struktury i planowania, zastosowanie trunk-based development może doprowadzić do chaosu organizacyjnego. Stąd wspomniana już wcześniej konieczność przeszkolenia zespołu przed wdrożeniem trunk-based development.
W wielu przypadkach zastosowanie trunk-based development będzie wymagało zwiększenia zasobów osobowych z racji kompletów testów, jakie wykonywane są na każdym zbiorze zmian. Każda mała zmiana wymaga ich przeprowadzenia, co oznacza, że w jednym czasie uruchomionych zostanie wiele instancji testów.
Jak przebiega praca w trunk-based development?
Wszystkie osoby z repozytorium pracują na jednej gałęzi głównej. Synchronizują zmiany w jej obrębie wielokrotnie w ciągu dnia. Najważniejszą kwestią jest pewność, że wprowadzane zmiany nie zagrożą stabilności gałęzi. Aby to sprawdzić, przeprowadza się testy automatyczne, które można uruchomić lokalnie.
Dopiero wówczas, gdy zespół czy developer ma pewność co do stabilności zmian, wdraża je do gałęzi głównej. Aby pełna stabilność była zachowana, czas poświęcony na wprowadzanie zmian nie powinien być dłuższy niż maksymalnie kilka godzin pracy, jest to jednak wartość umowna.
Wyjątek stanowi sytuacja, w której zespół programistów lub developerów jest duży albo mamy wiele zespołów pracujących z tym samym repozytorium. Wtedy istnieje możliwość tworzenia gałęzi krótko żyjących, których celem jest jedynie wprowadzenie zmian i przeprowadzenie procesu code-review. Długość życia takich gałęzi nie powinna przekraczać trzech dni.
Jakie problemy napotyka się podczas stosowania trunk-based development?
Podczas pracy można napotkać pewne trudności. Dla przykładu, jeżeli jeden zespół czy developer wprowadza swoje zmiany, w których pojawi się jakikolwiek konflikt, rozwiązać będzie go musiał zespół, który będzie wprowadzał zmiany jako kolejny. Nie jest to dużym problemem, kiedy konflikt pojawił się w ostatniej zmianie.
Problem pojawia się jednak wówczas, gdy gałąź była rozwijana przez długi czas i jest bardzo duża. Wówczas znalezienie problemu jest bardzo trudne.
Inną często występującą komplikacją jest sytuacja, gdy główna gałąź istnieje już tak długo, że naturalnie zaczęły powstawać gałęzie odchodzące od niej. W takie sytuacji posiadanie gałęzi głównej nie ma już swojego zastosowania. Aby kontrola wersji była możliwa, konieczne zatem będzie zastosowanie specjalnego systemu.
W czym może pomóc Ci trunk-based development?
Trunk-based development to podejście zakładające wprowadzenie bardzo niewielkich zmian. Ich niewielkie rozmiary są tylko pozorne, bo w rzeczywistości dają niezwykłe efekty. Przede wszystkim, stosując trunk-based development, o wiele szybciej możesz uzyskać informację zwrotną, a co więcej, jest ona znacznie konkretniejsza.
Znalezienie błędu w krótkich kilku linijkach kodu będzie zatem o wiele prostsze niż szukanie go w całym kodzie na 100 linijek. Poza tym korzystanie z tego modelu sprawia, że zmiany wprowadzane przez innych programistów z zespołu są pobierane natychmiast. Dzięki temu, że praca postępuje małym krokami, wszyscy członkowie zespołu na bieżąco mogą obserwować rozwój i postępy.
Mówiąc o pozytywnych skutkach zastosowania trunk-based development, warto wspomnieć także o łatwości i większej skrupulatności w przeglądaniu kodu. Jeżeli jest on krótszy, staje się odpowiednio przystępny oraz czytelny. Znikają wszelkie problemy ze scalaniem zmian, gdyż każdorazowa porcja danych jest bardzo mała.
Dzięki temu konflikty zdarzają się bardzo rzadko, a jeżeli już się pojawią, ich zakres jest niewielki i łatwo można je naprawić. Niewątpliwie, trunk-based development posiada spory potencjał w kontekście pracy większej grupy programistów czy developerów w jednym repozytorium, wdrożenie tego modelu może więc być bardzo korzystne.
4 min.
