Git workflow - Michał Pakuła

Meet Magento Poland 2015

Michał Pakuł[email protected]

Divante

Git workflow

i bezpieczne wydania


ZANIM ZACZNIEMY…Słów kilka o warsztatach oraz potrzebnych nam rzeczach.


Agenda

• Czynniki wypływające na bezpieczne wydanie.

• Git i standardowy model gałęzi.

• Wydanie na środowisku produkcyjnym.

• Automatyzacja wydań.• Część praktyczna.


Co będzie nam potrzebne?

• Git w wersji minimum 1.8, najlepiej 2.6

• Edytor tekstowy (nano, vim, Notepad++)

• GitExtensions (Windows)

• GitG lub GitK (Linux)

• Konsola bash (Windows)

• Przykładowe repozytorium


CZYNNIKI WPŁYWAJĄCE NA BEZPIECZNE WYDANIE

Czyli na co zwracać uwagę na poziomie prowadzenia projektu i pracy z repozytorium.


Najważniejsze

Wydanie samo w sobie, to kwestia wykonania kilku prostych czynności na

środowisku produkcyjnym. Najistotniejsze jest to, co dzieje się wcześniej.


Na poziomie projektu

• Stosowanie metodyk zwinnych (np. SCRUM) i cykliczne wydania i planowanie.

• Dobrze opracowany i przemyślany flow na poziomie systemu śledzenia błędów i repozytorium (synergia obu).

• Stosowanie numerów wersji oprogramowania i określanie wersji docelowej dla zadań.

• Kontrola kodu pomiędzy programistami poprzez code-review.


Na poziomie projektu

• Stosowanie list kontrolnych oraz procedur, również tych, które zastosujemy do wycofania zmian.

• Testy funkcjonalności (testerzy, testy automatyczne).

• Środowisko testowe/stage i możliwie jak najlepsze odzwierciedlenie środowiska produkcyjnego.


Na poziomie repozytorium

• Dobra znajomość systemu kontroli wersji i jego mechanizmów.

• Dbanie o porządek w repozytorium poprzez zachowanie atomowości zmian, jednolitej nomenklatury dla gałęzi i migawek oraz stosowanie modelu gałęzi.

• Odzwierciedlenie w repozytorium systemu śledzenia błędów (wspomniana synergia).

• Świadomość zmian będących w repozytorium.• Czysty stan repozytorium na środowisku produkcyjnym –

brak plików zmodyfikowanych oraz nieśledzonych.


Jednolita nomenklatura

Dla gałęzi tematycznych:feaute/101223-allegro-modulebugfix/101225-price-formathotfix/101229-null-price

issue/101234-phing-build-update

Zadania w systemie śledzenia błędów powinny mieć zawsze określony prawidłowy typ.

Dla migawek:RM:101223. Wdrożenie modułu Allegro.


Numeracja oprogramowania


Znaczenie poszczególnych sekcji

• major – sekcja określająca większe zmiany w architekturze aplikacji.

• minor – sekcja określająca nowe funkcjonalności.

• release/bugfix – sekcja określająca poprawki, ulepszenia lub refaktoryzację funkcjonalności.

• hotfix – sekcja określająca poprawki krytyczne wchodzące w skład bieżącej wersji release/bugfix.


Wersja zewnętrzna i wewnętrzna

Na poziomie systemu śledzenia błędów (zewnętrzna):

1.4.2obecna wersja

1.4.3przyszła wersja

1.5.0przyszła wersja

Na poziomie systemu kontroli wersji (wewnętrzna):

1.4.2.0obecna wersja

1.4.2.1obecna wersja + hotfix

1.4.2.2obecna wersja + hotfix

1.4.3.0przyszła wersja

1.5.0.0przyszła wersja


Określanie numeru wersji

[bugfix] Wyeliminowanie błędu...[bugfix] Poprawka...[bugfix] Ujednolicenie...[bugfix] Poprawka...[bugfix] Poprawka...

Wersja docelowa:

1.4.31.4.3.0

[feature] Dodanie możliwości...[feature] Dodanie modułu...[bugfix] Poprawka...[bugfix] Ujednolicenie...[bugfix] Poprawka...

Wersja docelowa:

1.5.01.5.0.0

Obecna wersja: 1.4.2Wersja docelowa: 1.X.X


Zalety numeracji oprogramowania

• Możliwość oznaczania w repozytorium punktów określających wersję.

• Dzięki tagowaniu na poziomie repozytorium łatwiejsze staje się ustawienie aplikacji w odpowiednim punkcie, jak i łatwiej jest wrócić do poprzedniego stabilnego punktu w przypadku, gdy wydanie nie powiedzie się.

• Łatwiejsze zarządzanie zadaniami na poziomie systemu śledzenia błędów poprzez określanie im wersji docelowej.

• Możliwość łatwego tworzenia listy zmian (changelog).


GIT I STANDARDOWY MODEL GAŁĘZI

Możliwe typy gałęzi, ich odpowiedzialność oraz kilka mechanizmów i poleceń Git’a, które warto znać.


Dlaczego Git?

• Bardzo dobre wsparcie dla rozgałęzionego procesu wytwarzania oprogramowania.

• Lokalny, przez co szybki, możliwa praca off-line.• Wbrew pozorom prosty i intuicyjny. Często

podpowiada co jest nie tak i robi to trafnie.• Oferuje mnóstwo przydatnych mechanizmów.• Wspiera wiele obecnych protokołów komunikacji

(HTTP, SSH, FTP, rsync).


Standardowy model gałęziModel gałęzi określa zasady jakie tyczą się poszczególnych gałęzi jeżeli chodzi o ich zawartość (zmiany) oraz dopuszczalny sposób (ff, no-ff) i kierunek scaleń.


Przykładowy flow krok po kroku.


Przykładowy flow krok po krokuZaczynamy nasz nowy sprint od migawki zmian, na którą wskazuje tag 1.4.1.0 oraz gałęzie master i development.

Docelowa wersja aplikacji to 1.4.2, a nasz sprint zawiera w backlog’u dwa zadania do realizacji.


Przykładowy flow krok po krokuJeden z programistów realizuje funkcjonalność widniejącą w systemie śledzenia błędów pod numerem 101115. Zmiany zatwierdza w osobnej gałęzi utworzonej od wspomnianej wcześniej migawki.

~$ git checkout -b feature/101115 master// Dodanie nowych plików i modyfikacja // istniejących.~$ git add <files>~$ git commit -m "RM:101115. Feature message."~$ git push origin feature/101115


Przykładowy flow krok po krokuKolejny programista wykonuje poprawkę istniejącej już funkcjonalności w kolejnej gałęzi o nazwie bug/101220.

Obie gałęzie wywodzą się z migawki, na którą wskazuje gałąź master, zatem żadna z nich nie zawiera zmian z drugiej gałęzi.

Stan aplikacji na obu gałęziach jest odmienny, co nie zaburza pracy drugiej osobie.

~$ git checkout -b bug/101220 master// Modyfikacja istniejących plików.~$ git add -u~$ git commit -m "RM:101220. Bugfix message."~$ git push origin bug/101220


Przykładowy flow krok po krokuProgramista realizujący zadanie dla zachowania atomowości zmian łączy trzy migawki w jedną przy pomocy mechanizmu rebase.

Taka operacja powinna być wykonywana zawsze przed scaleniem gałęzi tematycznej do gałęzi development.

Aby zaktualizować gałąź zdalną origin/feature/101115 należy wypchnąć gałąź lokalną z przełącznikiem -f.

~$ git checkout feature/101115~$ git rebase -i master// Jeżeli coś jest nie tak.~$ git reset --hard origin/feature/101115// Jeżeli wszystko jest w porządku.~$ git push -f origin featire/101115


Przykładowy flow krok po krokuGałąź feature/110115 scalamy do gałęzi development z pominięciem przesunięcia wskaźnika gałęzi (no-fast-forward – przełącznik --no-ff).

Dzięki temu w repozytorium zostanie informacja o tym, że zadanie to było realizowane w osobnej gałęzi tematycznej - zostanie utworzona migawka scalająca z odpowiednim komentarzem: „Merge branch 'feature/101115' into development”.

~$ git checkout development~$ git pull~$ git merge --no-ff feature/101115


Przykładowy flow krok po krokuGałąź z poprawką również scalamy do gałęzi development, analogicznie jak poprzednią.

~$ git checkout development~$ git pull~$ git merge --no-ff bug/101220


Przykładowy flow krok po krokuW międzyczasie okazuje się, że nasza obecna wersja aplikacji (1.4.1) zawiera poważny błąd, który trzeba natychmiastowo poprawić.

W tym celu tworzymy gałąź hotfix/101223 od gałęzi master i wprowadzamy w niej odpowiednie poprawki eliminujące błąd.

Poprawkę można wykonać bezpośrednio w gałęzi master pod warunkiem, że wydanie nastąpi od razu i osoba wykonująca hotfix ma uprawnienia do wypchnięcia zmian w gałęzi master.

~$ git checkout -b hotfix/101223 master// Modyfikacja istniejących plików.~$ git add -u~$ git push origin hotfix/101223


Przykładowy flow krok po krokuPo weryfikacji zmian, gałąź z poprawką krytyczną scalamy do gałęzi master z pominięciem przesunięcia wskaźnika gałęzi (--no-ff).

~$ git checkout master~$ git merge --no-ff hotfix/101223~$ git push


Przykładowy flow krok po krokuNa gałęzi master tworzymy tag wersji 1.4.1.1 ze zwiększoną czwartą sekcją, określającą numer poprawki krytycznej dla wersji release: 1.4.1.

~$ git tag 1.4.1.1~$ git push --tags


Przykładowy flow krok po krokuAby zachować spójność zmian, zawsze scalamy gałąź master do gałęzi development lub release, gdy tylko pojawią się w niej nowe zmiany. Pozwoli to uniknąć potencjalnych konfliktów w przyszłości.

~$ git checkout development~$ git pull~$ git merge master~$ git push


Przykładowy flow krok po krokuW momencie, gdy gałąź development wypełni się zmianami dla wersji docelowej, można utworzyć gałąź release/1.4.2, która będzie zawierała tylko zmiany z zadań dla bieżącego sprintu.

Po tej operacji gałąź development zostanie uwolniona i będzie można do niej scalać zmiany z zadań dla kolejnego sprintu.

~$ git checkout development~$ git branch release/1.4.2~$ git push origin release/1.4.2


Przykładowy flow krok po krokuOd migawki na którą wskazuje gałąź development oraz release/1.4.2 zostaje utworzona gałąź wraz ze zmianami dla zadania z kolejnego sprintu, przykładowo dla wersji 1.4.3.

Od momentu, gdy powstanie gałąź release, nie można do niej scalać gałęzi development – może ona zawierać zmiany dla kolejnej wersji aplikacji.

~$ git checkout -b feature/101216 development// Dodanie nowych plików i modyfikacja // istniejących.~$ git add <files>~$ git commit -m "RM:101220. Feature message."~$ git push origin feature/101216


Przykładowy flow krok po krokuW utworzonej gałęzie release/1.4.2 stabilizujemy kod aplikacji i poprawiamy błędy i uwagi zgłoszone przez testerów lub klienta.

~$ git checkout release/1.4.2// Modyfikacja istniejących plików.~$ git add -u~$ git commit -m "RM:101220. Fix message."~$ git push


Przykładowy flow krok po krokuAby zachować spójność zmian w repozytorium, gałąź release/1.4.2 scalamy do gałęzi development aby zawierała ona wprowadzone poprawki. Mogą one być istotne dla innych realizowanych zadań.

Jako że gałęzie release/1.4.2 i development są dostępnie w historii zmian bezpośrednio, scalenie następuje z przesunięciem wskaźnika gałęzi (fast-forward), a więc bez utworzenia nowej migawki scalającej.

~$ git checkout development~$ git pull~$ git merge release/1.4.2~$ git push


Przykładowy flow krok po krokuGdy wszystko jest w porządku i jesteśmy gotowi do wydania, scalamy gałąź release/1.4.2 do gałęzi master, wynikiem czego jest nowa migawka scalająca.

~$ git checkout master~$ git merge --no-ff release/1.4.2~$ git push


Przykładowy flow krok po krokuBezpośrednio na gałęzi master tworzymy nowy tak wersji o numerze 1.4.2.0 i wypychamy go do repozytorium centralnego.

~$ git tag 1.4.2.0~$ git push --tags


Przykładowy flow krok po krokuAby zachować porządek, zawsze pod koniec sprintu lub po wydaniu należy usunąć scalone gałęzie, lokalne oraz zdalne.

// Usunięcie referencji lokalnych:~$ git branch -d feature/101115 bug/101220 \ hotfix/101223 release/1.4.2// Usunięcie referencji zdalnych:~$ git push --delete origin feature/101115 bug/101220 hotfix/101223 release/1.4.2


Przykładowy flow krok po krokuAby gałąź feature/101216 zawierała zmiany wprowadzone w gałęzi release, a obecnie znajdujące się w gałęzi development, możemy scalić tą drugą do gałęzi feature/101216.

Prowadzi to jednak do utworzenia nowej migawki scalającej, co negatywnie wpływa na czytelność repozytorium.

~$ git checkout feature/101216~$ git merge development~$ git push


Przykładowy flow krok po krokuBardziej eleganckim i czytelniejszym rozwiązaniem z punku widzenia grafu repozytorium jest przeniesienie gałęzi feature/101216 tak, aby wywodziła się ona z migawki, na którą wskazuje gałąź development.

Nie można jednak wykonywać mechanizmu rebase na gałęziach, na których pracują inne osoby. Może to doprowadzić to poważnych problemów ze spójnością repozytorium - jest to ingerencja w historię zmian.

~$ git checkout feature/101216~$ git rebase development~$ git push -f origin feature/101216


Odpowiedzialność poszczególnych gałęzi oraz

podstawowe zadady


Gałąź master

• Istnieje przez cały czas życia repozytorium.

• Zawiera stabilny i przetestowany kod aplikacji.• Bezpośrednio w niej mogą być wykonywane jedynie

poprawki krytyczne (hotfix).• Każda zmiana w gałęzi master powinna zostać scalona

do gałęzi release i/lub development.• Scalać do niej można jedynie gałęzie release lub

development dla wersji docelowej.

• Tylko gałąź master powinna zawierać tagi wersji, na które ustawiane jest środowisko produkcyjne.


Gałąź release/x.y.z

• Tworzona jest po ukończeniu zadań dla wersji docelowej, którymi wypełnia się gałąź development.

• Główną ideą jest uwolnienie gałęzi development.• Gałąź istnieje na czas stabilizacji zmian dla wersji

docelowej aplikacji i powinna zostać usunięta po wydaniu.

• Nie można do niej scalać gałęzi development oraz gałęzi tematycznych. Jedyna gałąź, którą można scalić to gałąź master.

• Każda zmiana pojawiająca się w gałęzi release powinna znaleźć się w gałęzi development.


Gałąź development

• Istnieje przez cały czas życia repozytorium.

• Powinna zawierać ukończone i gotowe do testowania zadania scalane z gałęzi tematycznych.

• Nie może zawierać nieukończonych i/lub niestabilnych zmian mogących zaburzać pracę innych osób.

• Zazwyczaj od niej tworzone są gałęzie tematyczne.• Od niej tworzona jest gałąź release w momencie, gdy

gałąź development wypełni się zmianami dla wersji docelowej (pod koniec sprintu).


Gałęzie tematyczne

• Istnieją na czas realizacji zadania.

• Mogą być tworzone z gałęzi development lub innej gałęzi tematycznej.

• Powinny być zawsze scalane do gałęzi development.• Gałęzie tematyczne powinny zawierać zmiany tylko dla

jednego zagadnienia w systemie śledzenia błędów.• W swojej nazwie powinny mieć zawsze typ zmiany i

numer zagadnienia z systemu śledzenia błędów (feature/101233-rma-module).

• Powinny być usuwane tuż po zrealizowaniu zadania i scaleniu do gałęzi development lub release.


WYDANIE NA ŚRODOWISKU PRODUKCYJNYM

Podstawowe czynności jakie należy wykonać podczas podmiany wersji aplikacji.


Przygotowania

• Weryfikacja zmian w repozytorium.

• Przejście przez listę kontrolną.

• Przygotowanie procedury wydania.

• Testy zmian na serwerze stage.

• Poprawki w przypadku wykrycia błędów w gałęzi release.

• Scalenie gałęzi release/development do gałęzi master.

• Utworzenie tag'a wersji na gałęzi master.

• Powiadomienie zainteresowanych osób o wydaniu i czasie niedostępności serwisu i wprowadzanych zmianach.


Strona przerwy technicznej


Po co strona przerwy technicznej?

• Odseparowanie ruchu od serwisu na czas niezbędnych operacji (migracje, indeksacje, czyszczenie cache, rekonfiguracja serwerów).

• Zasłaniamy przed użytkownikiem potencjalne błędy aplikacji i jej komunikaty.

• W czasie przerwy możemy sprawdzić i przetestować wprowadzone zmiany.

W czasie przerwy technicznej nie powinno wykonywać się poprawek (hotfix).


Strona przerwy technicznej w Magento

Domyślny mechanizm strony przerwy technicznej w Magento nie umożliwia wpuszczenia ruchu do

aplikacji dla wybranych osób. Niemożliwe jest zatem przetestowanie zmian podczas wydania.

$maintenanceFile = 'maintenance.flag';

# Jeżeli istnieje plik maintenance.flag włącz stronę przerwy technicznej:if (file_exists($maintenanceFile)) { include_once dirname(__FILE__) .'/errors/503.php'; exit;}


Wpuszczenie ruchu - cookieif (file_exists($maintenanceFile)) { $maintenanceKey = 'ynjZt3IA';

# Jeżeli ustawiony został parametr w adresie URL i ma oczekiwaną wartość, # ustaw cookie: if (isset($_GET['mskip']) && ($maintenanceKey === $_GET['mskip'])) { setcookie("mskip_{$maintenanceKey}", '1'); $skipMaintenance = true; }

# Jeżeli przychodzące żądanie nie zawiera cookie i nie został przekazany # w adresie URL parametr z oczekiwaną wartością, włącz stronę przerwy # technicznej: if (!isset($_COOKIE["mskip_{$maintenanceKey}"]) && !isset($skipMaintenance)){ include_once dirname(__FILE__) .'/errors/503.php'; exit; }

unset($maintenanceKey, $skipMaintenance);}

http://www.example.com/?mskip=ynjZt3IA


Wpuszczenie ruchu - IP

Opcja wpuszczania ruchu po adresie IP wymaga każdorazowego sprawdzenia działania strony

przerwy technicznej z innego adresu IP.

# Adres maszyny zdalnej, z której przychodzi żądanie:$remoteIp = $_SERVER['REMOTE_ADDR'];# Tablica adresów IP, które mają dostęp do serwisu:$allowedIps = array('5.134.210.152', '195.150.9.51');

# Jeżeżeli adres IP nie znajduje się w puli dozwolonych adresów, włącz stronę# przerwy techczniej:if (file_exists($maintenanceFile) && !in_array($remoteIp, $allowedIps)) { include_once dirname(__FILE__) .'/errors/503.php'; exit;}


Standardowa procedura wydania

• Weryfikacja stanu repozytorium na środowisku produkcyjnym (obecnie ustawiony tag wersji, obecność zmodyfikowanych lub nieśledzonych plików).

• Synchronizacja repozytorium (git fetch).• Włączenie strony przerwy technicznej.• Przełączenie się na tag nowej wersji.• Czynności niezbędne po wprowadzeniu zmian w

systemie plików (czyszczenie cache, reindeksacja, restart workerów, rekompilacja css/js, budowanie projektu, rekonfiguracja serwera, itp).


Standardowa procedura wydania

• Testy zmian w czasie trwania przerwy technicznej oraz sprawdzenie ścieżek krytycznych.

• Wycofanie zmian w przypadku problemów.• Wyłączenie strony przerwy technicznej.• Poinformowanie zainteresowanych osób o statusie

wydania.


AUTOMATYZACJA WYDAŃ

Na podstawie przykładu z życia, zalety automatyzacji oraz sytuacje, w jakich warto ją stosować.


Kiedy stosować automatyzację?

Automatyzację należy stosować w przypadku większych aplikacji działających

na bardziej złożonych architekturach serwerowych, gdzie trzeba wykonać

większą ilość czynności.


Co daje automatyzacja?

• Znacząco skraca czas potrzebny na wykonanie czynności na środowisku produkcyjnym, również w przypadku potencjalnej konieczności wycofania zmian.

• Eliminuje potencjalne błędy mogące wystąpić podczas procedury wydania (np.: pominięcie jakiegoś kroku procedury wydania).

• Daje testerom więcej czasu na sprawdzenie wprowadzonych zmian oraz ścieżek krytycznych.


Przykład automatyzacji

Z wykorzystaniem projektu na redundantnej architekturze serwerowej zapewniającej HA

(High Availability).


• Zalogowanie się po SSH na osiem serwerów – lb (2), app (3), db (1), worker (2).

• Przełączenie się na użytkownika root (8).• Ustawienie godziny na stronie przerwy technicznej

poprzez edycję pliku index.html na serwerach lb (2).• Włączenie strony przerwy technicznej - rekonfiguracja

haproxy i restart usługi (2).• Synchronizacja repozytorium na serwerach app oraz

worker (5 - Brak NFS).

• Przełączenie repozytorium na tag nowej wersji (5).

Konieczne czynności przed automatyzacją


Konieczne czynności przed automatyzacją

• Budowanie projektu przy pomocy phing (5).

• Wyczyszczenie cache WSDL w /tmp (3).• Inwalidacja cache lazy-load (1).• Wyczyszczenie cache Magento – Redis (1).• Restart worker’ów Gearman (1).

• Włączenie strony przerwy technicznej - rekonfiguracja haproxy i restart usługi (2).

W przypadku konieczności wycofania zmian należy przejść przez niemal całą procedurę raz jeszcze.


Efekt?

Około 43 czynności, które zajmowały

od 20 do 25 minut!


Ansible na pomoc

• Ansible nie jest narzędziem dedykowanym automatyzacji wydań, jest czymś więcej.

• Ansible wykonuje określone w pliku YML zadania na poszczególnych grupach serwerów.

• Mechanizm zawsze uruchamiany jest z jednego serwera.

• Wywołanie mechanizmu można dowolnie parametryzować i jawnie określać, gdzie mają zostać wykonane poszczególne zadania.


Efekty automatyzacji

Dzięki automatyzacji, wszystkie czynności niezbędne do wydania nowej wersji aplikacji wykonywane są na wszystkich serwerach

automatycznie w mniej niż 3 minuty.


Konieczne czynności po automatyzacji

• Zalogowanie się po SSH na serwer app-1 (1).

• Przełączenie się na użytkownika root (1).• Wykonanie (prawie) całego playbook’a Ansible (1).• Wykonanie zadania wyłączającego stronę przerwy

technicznej (1).

Jedynie 4 czynności do wykonania, których łączny czas nie powinien zająć więcej niż

5 minut (z czego 3 min to Ansible).


Wykonanie polecenia Ansible

Wykonanie wszystkich zadań poza wyłączeniem strony przerwy technicznej:

~# ansible-playbook deploy.yml \ --skip-tags "maintenance_off" \ --extra-vars "git_ref=7.4.0.0 maintenance_time=16:30"


Wykonanie polecenia Ansible

Wykonanie zadań wyłączających stronę przerwy technicznej:

~# ansible-playbook deploy.yml \ --tags "maintenance_off,haproxy_restart"


Inne mechanizmy

• Capistrano

• Chef

• Phing

• Puppet

• Vlad the deployer

• Skrypt bash

Użyte narzędzie zawsze powinno zależeć od wielkości i złożoności projektu oraz

architektury serwerowej.


CZĘŚĆ PRAKTYCZNA


PODSUMOWANIE


Najistotniejsze rzeczy

• Opracowanie flow na poziomie prowadzenia projektu i repozytorium według jego specyfiki.

• Weryfikacja zmian trafiających na środowisko produkcyjne oraz ich jakości.

• Dbanie o stan repozytorium, jego spójność i czytelność.

• Każdorazowe stosowanie procedur podczas wydania.

• Automatyzacja wydań.


Pytania?


Dziękuję za uwagę!

Git workflow - Michał Pakuła

Business

Transcript of Git workflow - Michał Pakuła