Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

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

  • gałęzi głównych
    • master : wskazuje na najnowszą wersję kodu aplikacji, która rozumiana jest jako produkcyjna
    • develop : wskazuje na najnowszą wersję kodu aplikacji zawierającą zmiany deweloperskie
  • gałęzi pomocniczych
    • 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

  • Może mieć dowolną nazwę poza master, develop, release-* czy hotfix-*, które są zarezerwowane do innych celów.
  • Mogą być tworzone na podstawie dowolnego commita.
  • Dołączane są tylko do gałęzi develop.
  • Istnieją zazwyczaj wyłącznie w lokalnych repozytoriach, nigdy w origin.
  • 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

  • Ma nazwę release-*
  • Mogą być tworzone na podstawie gałęzi develop.
  • Dołączane są tylko do gałęzi master i develop.
  • 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

  • Ma nazwę hotfix-*
  • Tworzone są na podstawie gałęzi master.
  • Dołączane są tylko do gałęzi master i develop.
  • 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ą. 

    porady programowanie

    Komentarze

    0 nowych
    tfl   8 #1 31.07.2013 11:01

    +1

    Bardzo dobry art! Mimo, że sama idea jest już dość stara i czasem pojawia się sama z siebie w długim procesie developerskim, to taka uporządkowana i zaplanowana metoda jest bardzo efektywna

    bachus   20 #2 31.07.2013 12:29

    Czy ja mam tylko wrażenie, że ten model jest sztywny i średnio "Agile"?

    tfl   8 #3 31.07.2013 12:51

    @bachus

    Przy wszystkich metodologiach agile, ktore dzielone sa na sprinty (podobnie jak scrum) moim zdaniem bedzie sie spisywac doskonale.

    vircung   5 #4 31.07.2013 13:17

    @bachus Sama idea jest prosta i prawdopodobnie dlatego masz takie wrażenie. Jednak ten model jest zwinny i bardzobardzo skalowalny.

    Możliwości ma ogromne. W tym posiadanie jednocześnie kilku gałęzi Release, tak jak Feature, o ile będzie trzymana konwencja mergowania z Hotfix. Kwestia jedynie dopracowania szczegółów.

    mikolaj_s   14 #5 31.07.2013 14:16

    Bardzo ciekawy materiał. Dzięki .

    koneton   6 #6 31.07.2013 14:25

    Wpis ciekawy, ale nieco mylący tytuł. W tytule i tekście używasz zamiennie nazwy aplikacja i projekt. To są dwie różne rzeczy. Cykl życia aplikacji to zupełnie coś innego niż cykl życia projektu.

    vircung   5 #7 31.07.2013 14:47

    @koneton, słuszna uwaga, poprawiłem się. Oczywiście projekt to pojęcie znacznie szersze niż aplikacjia, którą tworzą różnej maści deweloperzy.

    Faja   3 #8 31.07.2013 15:07

    Hmm ciekawe czy autor się przyzna że ten tekst tylko przetłumaczył...

    vircung   5 #9 31.07.2013 15:16

    @Faja, hmm już pierwszy link prowadzi do oryginalnego wpisu, a ostatnie zdanie wyraźnie mówi, że grafiki również pochodzą z tamtego miejsca :) 2:0 dla Ciebie :)

      #10 31.07.2013 16:49

    BARDZO MARZYŁEM O STRONIE INTERNETOWEJ I DOROSŁE ŻEBY ZAŁOŻYĆ.MARZYŁEM O TYM OD 5 LAT A MAM 8 LAT

      #11 31.07.2013 16:56

    BARDZO DOBRY ART.CZY JA MAM TYLKO WRAŻENIE, ŻE TEN MODEL JEST SZTYWNYM I ŚREDNIO;AGILE;

      #12 31.07.2013 16:59

    CZY JA MAM TYLKO WRAŻENIE, ŻE TEN MODEL JEST SZTYWNYM I ŚREDNIO;AGILE;

    SebaZ   16 #13 01.08.2013 18:33

    Ktoś okrutnie testuje system komentarzy.