Zarządzanie cyklem rozwoju aplikacji

Wszyscy myślący o swojej karierze jako deweloper prędzej, czy później spotkają się w problemem zarządzania cyklem rozwoju aplikacji. Gdzie trzymać kod nowych funkcjonalności, jak odseparować wersję produkcyjną od deweloperskiej, jak skutecznie zarządzać hotfixami, oraz masa innych problemów, które kiedyś trzeba będzie rozwiązać. Vincent Driessen zaproponował solidny model cyklu zycia aplikacji oparty o system kontroli wersji git. Został on dokładnie opisany na jego blogu.

Do rzeczy

Całość opiera się na idei opiera się na rozdzieleniu wszystkich zmian wprowadzanych do kodu aplikacji na zestaw gałęzi. Tworzenie, relacje oraz ich łączenie jest dyktowane poprzez zestaw zasad, których respektowanie prowadzi to przejrzystego stanu kodu źródłowego.

Proponowany model składa się z

[item]gałęzi głównych[/item]

• master : wskazuje na najnowszą wersję kodu aplikacji, która rozumiana jest jako produkcyjna
• develop : wskazuje na najnowszą wersję kodu aplikacji zawierającą zmiany deweloperskie

[item]gałęzi pomocniczych[/item]

• feature : zestaw zmian w kodzie zawierających nową funkcjonalność
• release : stan kodu aplikacji odpowiadający wersji RC
• hotfix : poprawki krytycznych błędów aplikacji, które nie mogą czekać na przygotowanie nowej wersji aplikacji

Rozproszenie centralnego repozytorium

Skąd wziął się podział na dwie grupy gałęzi? Jak wiemy git jest zdecentralizowanym systemem kontroli wersji, zatem technicznie rzecz ujmując, w jego kontekście nie istnieje coś takiego jak główne repozytorium. Odejściem od tej koncepcji jest logiczne wydzielenie repozytorium głównego, z którym wszyscy deweloperzy będą synchronizować wprowadzane. Zazwyczaj nadawana mu nazwa to origin, która jest znana wszystkim użytkownikom git jako właśnie zewnętrzne repozytorium. Dla aplikacji otwartoźródłowych zazwyczaj takim miejscem jest serwis GitHub.

Dodatkową korzyścią używania gita jest możliwość dodania innych deweloperów pracujących nad tą samą funkcjonalnością jako zdalne repozytoria i synchronizowanie wprowadzane zmiany w kodzie między sobą bez udziału głównego repozytorium.

Master/develop branch

Gałęzie master oraz develop zostały wydzielone jako główne dlatego, iż tylko one znajdują się w (logicznie) głównym repozytorium (origin) i tylko z nimi synchronizuje się każdy deweloper pracujący nad daną aplikacją.

Gałąź master zawsze wskazuje na najnowszą produkcyjną/finalną wersję aplikacji, co nie powinno wymagać dalszego wyjaśniania. Każde zmiany w kodzie jakie znajdą się w tej gałęzi oznaczają wydanie kolejnej wersji produkcyjnej.

Natomiast gałąź develop zawiera najnowsze zmiany w aplikacji. W momencie gdy kod źródłowy zostanie ustabilizowany i jest gotowy do "wypuszczenia" zostaje on mergowany do gałęzi master oraz oznaczany jako kolejna wersja. Można nazwać tę gałąź integracyjną, ponieważ może ona służyć jako podstawa to wypuszczania wersji nightly oraz uruchamiania na niej zestawy testów (o ile takowe istnieją).

Przykładem usługi ciągłej integracji dla serwisu GitHub może być Travis-CI

Feature Branch

[item]Może mieć dowolną nazwę poza master, develop, release-* czy hotfix-*, które są zarezerwowane do innych celów.[/item] [item]Mogą być tworzone na podstawie dowolnego commita.[/item] [item]Dołączane są tylko do gałęzi develop.[/item][item]Istnieją zazwyczaj wyłącznie w lokalnych repozytoriach, nigdy w origin.[/item]Przeznaczeniem gałęzi feature są nowe funkcjonalności, które mogą być wprowadzone w nie znanym jeszcze momencie. Istnieją one tak długo jak dana funkcjonalność jest tworzona. W momencie gdy dane zmiany zostaną uznane za gotowe dołączane one są do gałęzi develop a istnienie danej gałęzi nie jest już wymagane. Warto tutaj zaznaczyć, aby przy mergowaniu zmian użyć flagi --no-ff pozwoli to na wydzielenie commitów odpowiedzialnych za dany zestaw zmian, co możemy zaobserwować poniżej.

Release branch

[item]Ma nazwę release-*[/item] [item]Mogą być tworzone na podstawie gałęzi develop.[/item] [item]Dołączane są tylko do gałęzi master i develop.[/item]Tworzona jest aby przygotować nową produkcyjną wersję aplikacji. Pozwala na wprowadzanie ostatnich poprawek w kodzie i naprawę pomniejszych błędów. Wszystkie nieukończone funkcjonalności nie mogą zostać dołączone "na szybko", muszą poczekać do wydania nowej wersji. Od tego momentu wszystkie zmiany wprowadzane w gałęzi develop będą zawarte w nowej wersji. Przy stanie kody zbliżonym do finalnego, gałąź zostaje dołączona do master, w której każdy commit z definicji jest nową wersją, a następnie otagowana w celu łatwiejszej referencji do danej wersji. Wszystkie dokonane zmiany dołączane są również do gałęzi develop w celu zachowania spójności.

Hotfix branch

[item]Ma nazwę hotfix-*[/item] [item]Tworzone są na podstawie gałęzi master.[/item] [item]Dołączane są tylko do gałęzi master i develop.[/item]Cykl życia tej gałęzy jest bardzo zbliżony do release, ponieważ tworzy ona nową wersję aplikacji, z tą różnicą, że nie została ona wcześniej zaplanowana. Powodem dla którego tak się staje jest nieprawidłowy stan aplikacji lub bądź krytyczny błąd, który musi zostać naprawiony niezależnie od planowanej kolejnej wersji. Dołączanie zmian do gałęzi develop zapewnia naprawę aplikacji nie tylko w nowej wersji, ale też we wszystkich kolejnych co wynika z definicji tej gałęzi. Wyjątkiem od tej zasady jest dołączanie zmian do gałęzi release zamiast develop, ponieważ również będzie to skutkowało dołączeniem wszelkich zmian do wersji deweloperskiej, co również zostało zdefiniowane wcześniej.

Zatem

O ile na początku zdjęcie przedstawiające tych parę prostych założeń wyglądało (w tym dla mnie) całkiem strasznie, o tyle po wgryzieniu się w temat oraz przemyśleniu go na spokojnie jest to rozsądny sposób ogarnięcia nawet dużego zespołu deweloperów. Oczywiście jeżeli będą chcieli w pełni współpracować :)

Aby ułatwić zarządzanie aplikacją w tym modelu jego autor stworzył dodatek do git o nazwie gitflow, który automatyzuje większość czynności związanych z pracą z gałęziami.

Wszystkie użyte grafiki pochodzą z bloga Vincent'a Driessen'a i są jego własnością.