Po co mi workflow

Wyobraźmy sobie projekt do którego kontrybuują dwa zespoły deweloperskie. Obydwa zespoły tworzą dwie różne funkcjonalności. Mimo to potrzebują wprowadzić zmiany w tej samej części kodu. Jakie niebezpieczeństwa niesie za sobą równoległa praca na głównej linii kodu?

Zacznijmy od tego, że praktycznie przy każdej próbie wrzucenia swoich zmian do repozytorium programista będzie zobowiązany do rozwiązania konfliktów, które wystąpiły przy równoległej pracy nad tymi samymi plikami. Co więcej w przypadku wystąpieniu błędów produkcyjnych powrót do kodu z którego zbudowana jest aktualna wersja aplikacji będzie problematyczny.

Dążąc do idealnego rozwiązania warto przyjrzeć się możliwościom jakie daje branching. Tworzenie tak zwanych gałęzi w gicie ułatwia równoległą pracę wielu zespołom, dzięki możliwości tworzenia przestrzeni roboczych z własnymi historiami zmian. W naszym przykładzie każdy z zespołów w momencie rozpoczęcia pracy nad daną funkcjonalnością, może stworzyć oddzielną gałąź. Dzięki takiemu rozwiązaniu na gałęzi master (główna gałąź każdego repozytorium), pozostaje kod, który aktualnie jest na produkcji oraz każdy z zespołów ma własną kopię roboczą, nad którą może pracować. Co więcej każdy z zespołów może z własnej gałęzi uruchomić środowisko na którym będzie swój kod testować nie przeszkadzając przy tym w pracy innym. Takie podejście do zarządzania kodem powszechnie nazywa się „feature branch workflow”. Dodatkową zaletą wykorzystania gałęzi jest możliwość wykorzystania tak zwanych pull requestów. Dzięki nim możliwe jest weryfikowanie zmian wprowadzanych w kodzie releasowanym na produkcję na tak zwaną drugą rękę (ktoś musi zatwierdzić zmianę zanim zostanie ona domergowana do brancha master).

„Feature branch workflow” jest niewątpliwie ulepszeniem procesu deweloperskiego w porównaniu ze scentralizowanym podejściem (jedna główna gałąź na której pracują wszyscy programiści). Jednak istnieje wiele bardziej wszechstronnych rozwiązań. Aktualnie najpopularniejszym sposobem zarządzania repozytorium jest „Gitflow workflow”. W gitflow, tak samo jak w przypadku pracy na gałęziach deweloperskich programiści tworzą nowe funkcjonalności na swoich lokalnych feature branchach. Różnicą jest to, że zmiany z feature branchy domergowywane są do nowego brancha develop. Jakiś czas przed releasem, tworzona jest nowa gałąź z gałęzi develop. Na tej tak zwanej gałezi releasowej znajduje się kod, który będzie wypuszczany na produkcję. To na tej gałęzi product owner oraz testerzy mogą testować nowe, bądź zmieniane funkcjonalności, aby upewnić się że zmiany które mają być udostępnione w nowej wersji oprogramowania nie powodują błędów. W momencie releasu zmiany z brancha releasowego są nakładane na gałąź masterTo podejście powoduje, że każdy merge na branchu master jest równoznaczny z wersją oprogramowania wypuszczonego do klientów.

Łatwo możemy spostrzec, że gitflow rozwiązuje kilka nietrywialnych problemów w zarządzaniu kodem w firmie. Głównym powodem dla którego powstało gitflow jest możliwość łatwego nakładania poprawek na różne wersje oprogramowania. Dzięki odseparowaniu gałęzi develop i master, programista ma łatwy przegląd wersji kodu które wylądowały na produkcji. Mając tą wiedzę z łatwością może nałożyć swoje poprawki, tworząc gałąź hotfix i nakładając go na branche master i develop. Gitflow ułatwia też elastyczne dobieranie terminów releasów. Dzięki zastosowaniu feature branchy i brancha develop release może być wykonany w dowolnym momencie bez zagrożenia, że na produkcję wejdzie nie skończona funkcjonalność.

Zastosowanie dowolnego workflow ma na celu ułatwienie równoległej pracy z kodem oraz zmniejszenie ilości konfliktów. Dobrze zarządzane repozytorium powinno również pozwolić na łatwe rozróżnienie, które funkcjonalności wylądowały już na produkcji a które nie. Co więcej większość sposobów pracy z repozytorium ułatwia nakładanie poprawek na wersje produktów, które zostały udostępnione już odbiorcom. Mam nadzieję, że ten artykuł przekonał Cię do spojrzenia i ulepszenia twojego procesu developmentu.

 

Krzysztof Studniarek, Starszy Analityk IT w mBanku