Intensywne ciągłe dostarczanie z systemem Git

Prawdę mówiąc, nie chodzi o to, że system Git sam w sobie jest tak doskonałym narzędziem ciągłego dostarczania. Po prostu przepływy pracy oparte na gałęziach świetnie sprawdzają się w modelu CD, a system Git doskonale obsługuje takie przepływy. Przepływ pracy oparty na tworzeniu i scalaniu gałęzi nie tylko świetnie wpisuje się w model CD, ale także pomaga uporać się z trudnymi błędami, wypróbować nowe technologie lub po prostu zacząć tworzenie nowej funkcji od zera bez ryzyka, że zmiany uniemożliwią innym członkom zespołu dalsze realizowanie własnych zadań.

W oczywisty sposób Subversion oraz inne tradycyjne systemy kontroli wersji także umożliwiają tworzenie gałęzi. Pozwólmy sobie jednak na małą dygresję i poznajmy „złego bliźniaka” tworzenia gałęzi: scalanie.

Tradycyjne systemy kontroli wersji, takie jak Subversion, po prostu nie radzą sobie tak dobrze ze śledzeniem wersji plików funkcjonujących w różnych gałęziach, a gdy przychodzi czas scalania, Subversion musi się zatrzymać i wielokrotnie prosić o wskazówki. (Wiesz… to małe wyskakujące okienko z pytaniem, czy chcesz uwzględnić w scalonej wersji ten czy tamten wiersz). Z uwagi na wymagany stopień ingerencji ze strony użytkownika podczas scalania zespoły często stosują zamrażanie kodu, aby osoba przeprowadzająca scalanie nie napotykała licznych przeszkód związanych z nowymi zmianami napływającymi z jednej z gałęzi. A zamrożenia kodu są kosztowe i przy tym wymuszają bezproduktywny czas.

Z kolei system Git naprawdę dobrze radzi sobie ze śledzeniem zmian w różnych wersjach plików funkcjonujących w różnych gałęziach i zawsze wie, jak wyglądał wspólny przodek konkretnego pliku. Zasadniczo ma on wbudowany GPS, który umożliwia nawigację po scaleniach bez konieczności zatrzymywania się i proszenia o wskazówki przez cały czas.

Z systemem Git możesz swobodnie badać możliwości tworzenia gałęzi w sposób, jaki w systemie Subversion byłby niepraktyczny. Nakłady związane z tworzeniem i scalaniem gałęzi są tak niewielkie, że gałęzie aktywne przez dzień lub dwa stają się nie tylko wykonalne, ale wręcz korzystne.

OK, w porządku. Ale co właściwie sprawia, że tworzenie gałęzi jest tak dobrym rozwiązaniem z perspektywy ciągłego dostarczania?

Przykładowo wszystkie zespoły programistyczne w Atlassian mają umowę, że nic nigdy nie jest zatwierdzane bezpośrednio do gałęzi głównej ani gałęzi stabilnych. Każdy pracuje w gałęziach. W rzeczywistości jesteśmy takimi zwolennikami gałęzi, że tworzymy odrębną gałąź dla każdego zgłoszenia Jira, jakim się zajmujemy, o czym powiem jeszcze za moment.

W każdym razie oznacza to, że można przeprowadzić tyle testów i uszkodzić tyle gałęzi, ile tylko się chce. Gałęzie główne utrzymywane są zaś w stanie umożliwiającym wydawanie z nich kodu. Na ich podstawie można również tworzyć nowe gałęzie bez obaw o przejęcie uszkodzonego kodu. To istotna korzyść z perspektywy CD i ogólnej produktywności programistów (nie wspominając już o morale).

Gałęzie ułatwiają przyjmowanie fragmentów prac spoza zespołu

Łatwość, z jaką w systemie Git odbywa się tworzenie gałęzi — a w szczególności dzielenie całych repozytoriów — ułatwia wprowadzanie fragmentów prac od ludzi spoza zespołu zajmującego się na co dzień danym kodem: podwykonawców, programistów z firm partnerskich, programistów z innych jednostek biznesowych itp. Nie musisz zamartwiać się, że osoby niezaznajomione z Twoją bazą kodu mogą przypadkiem wprowadzić zmiany w Twoich gałęziach krytycznych, uniemożliwiając Ci wysłanie nowego kodu.

Także tutaj rygorystyczne zautomatyzowane testy na gałęziach lub podzielonych repozytoriach stanowią klucz do pomyślnej współpracy. Chcesz przecież sprawdzić kompilację i wyniki testów przed zatwierdzeniem jakichkolwiek scaleń z główną linią kodu.

Poprawnie utworzona gałąź = przejrzyste śledzenie projektu

Obecnie na popularności zyskuje podejście polegające na tworzeniu gałęzi dla każdej historyjki, poprawki błędu lub każdego wdrażanego zadania (tj. każdego zgłoszenia Jira). W Atlassian już kilka lat temu przyjęliśmy model tworzenia gałęzi dla każdego zgłoszenia i nie zamierzamy z niego rezygnować. Zyskał on również popularność wśród naszych klientów.

Utworzenie gałęzi dla każdego zgłoszenia ułatwia selekcjonowanie zmian, które zostaną dostarczone do produkcji lub dołączone do pakietu wydania. Nie gromadzisz wszystkich zmian na kupce w gałęzi głównej, więc możesz wybrać, które zmiany zostaną do niej wprowadzone i kiedy to nastąpi. Możesz dostarczyć produkt o minimalnej wymaganej funkcjonalności realizowany w ramach epiku wraz jednym przydatnym dodatkiem bez konieczności czekania, aż wszystkie przydatne dodatki będą gotowe. Możesz też dostarczyć jedną poprawkę błędu i zrobić to w ramach regularnego wydania. Nawet jeśli poprawka jest pilna, nie musisz borykać się z całym cyrkiem wycofywania innych zmian, które jeszcze nie są gotowe do dostarczenia, aby móc dostarczyć tylko tę jedną zmianę.

To właśnie ta łatwość, z jaką można wysłać pojedynczą zmianę kodu, stanowi istotę ciągłego dostarczania.

Dzięki takiemu podejściu niezatwierdzony kod nie tylko nie trafia do gałęzi głównej, ale także po uwzględnieniu w nazwie gałęzi odpowiedniego klucza zgłoszenia Jira oraz nazwiska lub inicjałów programisty, można błyskawicznie sprawdzić, na jakim etapie są prace programistyczne w przypadku każdego zgłoszenia.

Zwróć uwagę na konwencję nazewnictwa przyjętą na powyższej ilustracji: mamy tutaj unikatowy klucz wdrażanego zgłoszenia JIRA oraz krótki, czytelny opis, czego dotyczy zgłoszenie. Dzięki temu menedżer wydania lub inny interesariusz może zajrzeć do powyższego repozytorium i na pierwszy rzut oka sprawdzić, że historyjka użytkownika śledzona pod numerem AMKT-13952 jest już gotowa do wydania, ponieważ została scalona z gałęzią main. To właśnie możliwość śledzenia niewymagająca ręcznych działań — tadam!

Cieszę się, że o to pytasz. Omówię tutaj w skrócie i ogólnie wszystkie fazy, ponieważ szczegółowe informacje na temat każdej z nich znajdziesz w innych artykułach w tej witrynie.

• Utworzenie gałęzi zgłoszenia, nad którym będziesz pracować. W nazwie gałęzi uwzględnij klucz zgłoszenia Jira, aby było jasne, do czego służy gałąź. A jeśli korzystasz z innych narzędzi Atlassian, takich jak Bitbucket i Bitbucket Pipelines, będą one wychwytywać ten klucz zgłoszenia i utworzą łącza między zgłoszeniem, Twoją gałęzią, commitami, kompilacjami, pull requestami i wdrożeniami powiązanymi z tym zgłoszeniem. Innymi słowy, klucze zgłoszeń zdziałają cuda.
• Wprowadzenie zmian w gałęzi. Przebywasz tutaj w swoim małym własnym świecie, więc możesz zaszaleć. Wypróbuj coś nowego. Zepsuj coś. Nieważne, bo później i tak nastąpi…
• Poddanie Twojej gałęzi ciągłej integracji. Tylko od Ciebie i Twojego zespołu zależy, czy zdecydujesz się przeprowadzić tutaj specjalistyczne testy obciążenia czy kompleksowe testy oparte na interfejsie użytkownika. Możesz też automatycznie wyzwalać wykonanie testu przy każdym wypchnięciu zmian do gałęzi. Zespoły Atlassian zasadniczo przeprowadzają testy jednostkowe i integracyjne na gałęziach programistycznych.
• Częsta aktualizacja gałęzi o najnowszy kod z gałęzi głównej. W tym celu możesz użyć opcji zmiany bazy lub zatwierdzenia gałęzi. Decyzja należy do Ciebie! (Pamiętaj, aby nie używać polecenia rebase w odniesieniu do gałęzi, nad którą pracujesz wspólnie z innymi programistami, ponieważ będą zrzędzić). Tak czy inaczej, przed scaleniem wykryjesz kolizje integracyjne, co ułatwi utrzymanie porządku w gałęzi głównej.
• Utworzenie pull requestu, gdy wszystko będzie gotowe do scalenia. To oznacza, że wdrożenie zostało ukończone, pobrano zmiany od innych członków zespołu i rozwiązano ewentualne kolizje, a wszystkie testy gałęzi przebiegły pomyślnie.
• Scalanie i wdrażanie według uznania. Niektóre zespoły preferują automatyczne dostarczanie każdej zmiany tuż po scaleniu z gałęzią główną i pomyślnym wykonaniu wszystkich testów, czyli model ciągłego wdrażania. Inne zespoły wolą, aby to konkretna osoba decydowała o tym, które zmiany i kiedy zostaną dostarczone. Wszystko zależy od Ciebie i Twojego zespołu.

Tak to wygląda. Przepływy pracy oparte na tworzeniu gałęzi upraszczają proces ciągłego dostarczania, a system Git eliminuje problemy wynikające z tworzenia gałęzi. W kolejnych artykułach znajdziesz bardziej szczegółowe informacje na temat konfiguracji Twojego repozytorium Git w sposób przyjazny dla modelu ciągłego dostarczania i dowiesz się, jak przełożyć te pomysły na praktykę, korzystając z narzędzi Atlassian. Do zobaczenia na kolejnej stronie!