SlideShare une entreprise Scribd logo
1  sur  73
Télécharger pour lire hors ligne
Meet Magento Poland 2015
Michał Pakuła
mpakula@divante.pl
Divante
Git workflow
i bezpieczne wydania
Meet Magento Poland 2015
ZANIM ZACZNIEMY…
Słów kilka o warsztatach oraz potrzebnych nam rzeczach.
Meet Magento Poland 2015
Agenda
• Czynniki wypływające na bezpieczne
wydanie.
• Git i standardowy model gałęzi.
• Wydanie na środowisku
produkcyjnym.
• Automatyzacja wydań.
• Część praktyczna.
Meet Magento Poland 2015
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
Meet Magento Poland 2015
CZYNNIKI WPŁYWAJĄCE NA
BEZPIECZNE WYDANIE
Czyli na co zwracać uwagę na poziomie prowadzenia projektu i
pracy z repozytorium.
Meet Magento Poland 2015
Najważniejsze
Wydanie samo w sobie, to kwestia
wykonania kilku prostych czynności na
środowisku produkcyjnym. Najistotniejsze
jest to, co dzieje się wcześniej.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Jednolita nomenklatura
Dla gałęzi tematycznych:
feaute/101223-allegro-module
bugfix/101225-price-format
hotfix/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.
Meet Magento Poland 2015
Numeracja oprogramowania
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Wersja zewnętrzna i wewnętrzna
Na poziomie systemu śledzenia
błędów (zewnętrzna):
1.4.2
obecna wersja
1.4.3
przyszła wersja
1.5.0
przyszła wersja
Na poziomie systemu kontroli
wersji (wewnętrzna):
1.4.2.0
obecna wersja
1.4.2.1
obecna wersja + hotfix
1.4.2.2
obecna wersja + hotfix
1.4.3.0
przyszła wersja
1.5.0.0
przyszła wersja
Meet Magento Poland 2015
Określanie numeru wersji
[bugfix] Wyeliminowanie błędu...
[bugfix] Poprawka...
[bugfix] Ujednolicenie...
[bugfix] Poprawka...
[bugfix] Poprawka...
Wersja docelowa:
1.4.3
1.4.3.0
[feature] Dodanie możliwości...
[feature] Dodanie modułu...
[bugfix] Poprawka...
[bugfix] Ujednolicenie...
[bugfix] Poprawka...
Wersja docelowa:
1.5.0
1.5.0.0
Obecna wersja: 1.4.2
Wersja docelowa: 1.X.X
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
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ć.
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
Standardowy model gałęzi
Model 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ń.
Meet Magento Poland 2015
Przykładowy flow krok po
kroku.
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Zaczynamy 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.
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Jeden 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Kolejny 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Programista 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Gałąź 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Gałąź z poprawką również scalamy do
gałęzi development, analogicznie jak
poprzednią.
~$ git checkout development
~$ git pull
~$ git merge --no-ff bug/101220
Meet Magento Poland 2015
Przykładowy flow krok po kroku
W 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Po 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Na 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Aby 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
W 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Od 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
W 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Aby 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Gdy 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Bezpoś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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Aby 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Aby 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
Meet Magento Poland 2015
Przykładowy flow krok po kroku
Bardziej 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
Meet Magento Poland 2015
Meet Magento Poland 2015
Odpowiedzialność
poszczególnych gałęzi oraz
podstawowe zadady
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
WYDANIE NA ŚRODOWISKU
PRODUKCYJNYM
Podstawowe czynności jakie należy wykonać podczas podmiany
wersji aplikacji.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Strona przerwy technicznej
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
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;
}
Meet Magento Poland 2015
Wpuszczenie ruchu - cookie
if (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
Meet Magento Poland 2015
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;
}
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
AUTOMATYZACJA WYDAŃ
Na podstawie przykładu z życia, zalety automatyzacji oraz
sytuacje, w jakich warto ją stosować.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Przykład automatyzacji
Z wykorzystaniem projektu na redundantnej
architekturze serwerowej zapewniającej HA
(High Availability).
Meet Magento Poland 2015
Meet Magento Poland 2015
• 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ą
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Efekt?
Około 43 czynności, które zajmowały
od 20 do 25 minut!
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
Meet Magento Poland 2015
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).
Meet Magento Poland 2015
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"
Meet Magento Poland 2015
Wykonanie polecenia Ansible
Wykonanie zadań wyłączających stronę
przerwy technicznej:
~# ansible-playbook deploy.yml 
--tags "maintenance_off,haproxy_restart"
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
CZĘŚĆ PRAKTYCZNA
Meet Magento Poland 2015
PODSUMOWANIE
Meet Magento Poland 2015
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ń.
Meet Magento Poland 2015
Pytania?
Meet Magento Poland 2015
Dziękuję za uwagę!

Contenu connexe

Similaire à Git workflow - Michał Pakuła

Feature flags na ratunek projektu w JavaScript
Feature flags na ratunek projektu w JavaScriptFeature flags na ratunek projektu w JavaScript
Feature flags na ratunek projektu w JavaScriptThe Software House
 
Wprowadzenie do MEF w .NET 4.0
Wprowadzenie do MEF w .NET 4.0Wprowadzenie do MEF w .NET 4.0
Wprowadzenie do MEF w .NET 4.0Maciej Zbrzezny
 
Jak migrować kod legacy do Symfony? Tips & tricks
Jak migrować kod legacy do Symfony? Tips & tricksJak migrować kod legacy do Symfony? Tips & tricks
Jak migrować kod legacy do Symfony? Tips & tricksXSolve
 
Integration framework dla SAP Business One
Integration framework dla SAP Business OneIntegration framework dla SAP Business One
Integration framework dla SAP Business OneAnna Lewandowska
 
DrupalDay & Drupal Global Training Days - Wprowadzenie do Drupala
DrupalDay & Drupal Global Training Days - Wprowadzenie do DrupalaDrupalDay & Drupal Global Training Days - Wprowadzenie do Drupala
DrupalDay & Drupal Global Training Days - Wprowadzenie do DrupalaGrzegorz Bartman
 
Ciągłe Dostarcznie - Wprowadzenie
Ciągłe Dostarcznie - WprowadzenieCiągłe Dostarcznie - Wprowadzenie
Ciągłe Dostarcznie - WprowadzenieArtur Radosz
 
Co Ty wiesz o Magento?
Co Ty wiesz o Magento?Co Ty wiesz o Magento?
Co Ty wiesz o Magento?White Ducky
 
Poznaj GITa - Natalia Stanko
Poznaj GITa - Natalia StankoPoznaj GITa - Natalia Stanko
Poznaj GITa - Natalia StankoNatalia Stanko
 
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014Grzegorz Bartman
 
Activiti - BPMN 2.0 nadchodzi
Activiti - BPMN 2.0 nadchodziActiviti - BPMN 2.0 nadchodzi
Activiti - BPMN 2.0 nadchodziMaciek Próchniak
 
Poland - Dev Days 2005
Poland - Dev Days 2005Poland - Dev Days 2005
Poland - Dev Days 2005Tomasz Cieplak
 
Wstęp do Gitlab CI/CD w aplikacjach napisanych w Laravel
Wstęp do Gitlab CI/CD w aplikacjach napisanych w LaravelWstęp do Gitlab CI/CD w aplikacjach napisanych w Laravel
Wstęp do Gitlab CI/CD w aplikacjach napisanych w LaravelLaravel Poland MeetUp
 
A w więc chcesz zostać frontend developerem?
A w więc chcesz zostać frontend developerem?A w więc chcesz zostać frontend developerem?
A w więc chcesz zostać frontend developerem?The Software House
 
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w Magento
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w MagentoMaciej Ostrowski: Podstawy implementacji multi-inwentarza w Magento
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w MagentoMeet Magento Poland
 
Programowanie Komponentowe: #C Wprowadzenie do OSGi
Programowanie Komponentowe: #C Wprowadzenie do OSGiProgramowanie Komponentowe: #C Wprowadzenie do OSGi
Programowanie Komponentowe: #C Wprowadzenie do OSGiMikołaj Olszewski
 
TYPO3 CMS 6.2 LTS - what's new
TYPO3 CMS 6.2 LTS - what's newTYPO3 CMS 6.2 LTS - what's new
TYPO3 CMS 6.2 LTS - what's newMacopedia
 
DrupalDay Podstawy Drupal 8
DrupalDay Podstawy Drupal 8DrupalDay Podstawy Drupal 8
DrupalDay Podstawy Drupal 8Grzegorz Bartman
 
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test..."Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...Women in Technology Poland
 
IV Targi eHandlu Warsztaty Roman Baluta - Orba
IV Targi eHandlu Warsztaty Roman Baluta - Orba IV Targi eHandlu Warsztaty Roman Baluta - Orba
IV Targi eHandlu Warsztaty Roman Baluta - Orba ecommerce poland expo
 

Similaire à Git workflow - Michał Pakuła (20)

Feature flags na ratunek projektu w JavaScript
Feature flags na ratunek projektu w JavaScriptFeature flags na ratunek projektu w JavaScript
Feature flags na ratunek projektu w JavaScript
 
Wprowadzenie do MEF w .NET 4.0
Wprowadzenie do MEF w .NET 4.0Wprowadzenie do MEF w .NET 4.0
Wprowadzenie do MEF w .NET 4.0
 
Jak migrować kod legacy do Symfony? Tips & tricks
Jak migrować kod legacy do Symfony? Tips & tricksJak migrować kod legacy do Symfony? Tips & tricks
Jak migrować kod legacy do Symfony? Tips & tricks
 
Integration framework dla SAP Business One
Integration framework dla SAP Business OneIntegration framework dla SAP Business One
Integration framework dla SAP Business One
 
DrupalDay & Drupal Global Training Days - Wprowadzenie do Drupala
DrupalDay & Drupal Global Training Days - Wprowadzenie do DrupalaDrupalDay & Drupal Global Training Days - Wprowadzenie do Drupala
DrupalDay & Drupal Global Training Days - Wprowadzenie do Drupala
 
Ciągłe Dostarcznie - Wprowadzenie
Ciągłe Dostarcznie - WprowadzenieCiągłe Dostarcznie - Wprowadzenie
Ciągłe Dostarcznie - Wprowadzenie
 
Co Ty wiesz o Magento?
Co Ty wiesz o Magento?Co Ty wiesz o Magento?
Co Ty wiesz o Magento?
 
Poznaj GITa - Natalia Stanko
Poznaj GITa - Natalia StankoPoznaj GITa - Natalia Stanko
Poznaj GITa - Natalia Stanko
 
Poznaj GITa - Natalia Stanko
Poznaj GITa - Natalia StankoPoznaj GITa - Natalia Stanko
Poznaj GITa - Natalia Stanko
 
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014
Code driven development w Drupalu 7 | DrupalCamp Wrocław 2014
 
Activiti - BPMN 2.0 nadchodzi
Activiti - BPMN 2.0 nadchodziActiviti - BPMN 2.0 nadchodzi
Activiti - BPMN 2.0 nadchodzi
 
Poland - Dev Days 2005
Poland - Dev Days 2005Poland - Dev Days 2005
Poland - Dev Days 2005
 
Wstęp do Gitlab CI/CD w aplikacjach napisanych w Laravel
Wstęp do Gitlab CI/CD w aplikacjach napisanych w LaravelWstęp do Gitlab CI/CD w aplikacjach napisanych w Laravel
Wstęp do Gitlab CI/CD w aplikacjach napisanych w Laravel
 
A w więc chcesz zostać frontend developerem?
A w więc chcesz zostać frontend developerem?A w więc chcesz zostać frontend developerem?
A w więc chcesz zostać frontend developerem?
 
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w Magento
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w MagentoMaciej Ostrowski: Podstawy implementacji multi-inwentarza w Magento
Maciej Ostrowski: Podstawy implementacji multi-inwentarza w Magento
 
Programowanie Komponentowe: #C Wprowadzenie do OSGi
Programowanie Komponentowe: #C Wprowadzenie do OSGiProgramowanie Komponentowe: #C Wprowadzenie do OSGi
Programowanie Komponentowe: #C Wprowadzenie do OSGi
 
TYPO3 CMS 6.2 LTS - what's new
TYPO3 CMS 6.2 LTS - what's newTYPO3 CMS 6.2 LTS - what's new
TYPO3 CMS 6.2 LTS - what's new
 
DrupalDay Podstawy Drupal 8
DrupalDay Podstawy Drupal 8DrupalDay Podstawy Drupal 8
DrupalDay Podstawy Drupal 8
 
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test..."Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...
"Wyzwania automatyzacji w ciągłej integracji" - o tworzeniu i utrzymaniu test...
 
IV Targi eHandlu Warsztaty Roman Baluta - Orba
IV Targi eHandlu Warsztaty Roman Baluta - Orba IV Targi eHandlu Warsztaty Roman Baluta - Orba
IV Targi eHandlu Warsztaty Roman Baluta - Orba
 

Plus de Divante

The eCommerce Platforms in the Global Setup
The eCommerce Platforms in the Global Setup	The eCommerce Platforms in the Global Setup
The eCommerce Platforms in the Global Setup Divante
 
eCommerce Trends 2020
eCommerce Trends 2020eCommerce Trends 2020
eCommerce Trends 2020Divante
 
Async & Bulk REST API new possibilities of communication between systems
Async & Bulk REST API new possibilities of communication  between systemsAsync & Bulk REST API new possibilities of communication  between systems
Async & Bulk REST API new possibilities of communication between systemsDivante
 
Magento Functional Testing Framework a way to seriously write automated tests...
Magento Functional Testing Framework a way to seriously write automated tests...Magento Functional Testing Framework a way to seriously write automated tests...
Magento Functional Testing Framework a way to seriously write automated tests...Divante
 
Die Top 10 Progressive Web Apps in der Modernbranche
Die Top 10 Progressive Web Apps in der ModernbrancheDie Top 10 Progressive Web Apps in der Modernbranche
Die Top 10 Progressive Web Apps in der ModernbrancheDivante
 
progressive web apps - pwa as a game changer for e-commerce - meet magento i...
 progressive web apps - pwa as a game changer for e-commerce - meet magento i... progressive web apps - pwa as a game changer for e-commerce - meet magento i...
progressive web apps - pwa as a game changer for e-commerce - meet magento i...Divante
 
Customer churn - how to stop it?
Customer churn - how to stop it?Customer churn - how to stop it?
Customer churn - how to stop it?Divante
 
eCommerce trends 2019 by Divante.co
eCommerce trends 2019 by Divante.coeCommerce trends 2019 by Divante.co
eCommerce trends 2019 by Divante.coDivante
 
How to create a Vue Storefront theme
How to create a Vue Storefront themeHow to create a Vue Storefront theme
How to create a Vue Storefront themeDivante
 
Game changer for e-commerce - Vue Storefront - open source pwa
Game changer for e-commerce - Vue Storefront - open source pwa Game changer for e-commerce - Vue Storefront - open source pwa
Game changer for e-commerce - Vue Storefront - open source pwa Divante
 
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speech
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speechVue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speech
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speechDivante
 
How to successfully onboard end-clients to a B2B Platform - Magento Imagine ...
How to successfully onboard  end-clients to a B2B Platform - Magento Imagine ...How to successfully onboard  end-clients to a B2B Platform - Magento Imagine ...
How to successfully onboard end-clients to a B2B Platform - Magento Imagine ...Divante
 
eCommerce trends from 2017 to 2018 by Divante.co
eCommerce trends from 2017 to 2018 by Divante.coeCommerce trends from 2017 to 2018 by Divante.co
eCommerce trends from 2017 to 2018 by Divante.coDivante
 
Designing for PWA (Progressive Web Apps)
Designing for PWA (Progressive Web Apps)Designing for PWA (Progressive Web Apps)
Designing for PWA (Progressive Web Apps)Divante
 
Why is crud a bad idea - focus on real scenarios
Why is crud a bad idea - focus on real scenariosWhy is crud a bad idea - focus on real scenarios
Why is crud a bad idea - focus on real scenariosDivante
 
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentation
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentationvue-storefront - PWA eCommerce for Magento2 MM17NYC presentation
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentationDivante
 
Pimcore Overview - Pimcore5
Pimcore Overview - Pimcore5Pimcore Overview - Pimcore5
Pimcore Overview - Pimcore5Divante
 
Pimcore E-Commerce Framework - Pimcore5
Pimcore E-Commerce Framework - Pimcore5Pimcore E-Commerce Framework - Pimcore5
Pimcore E-Commerce Framework - Pimcore5Divante
 
The biggest stores on Magento
The biggest stores on MagentoThe biggest stores on Magento
The biggest stores on MagentoDivante
 
B2B Commerce - how to become successful
B2B Commerce - how to become successfulB2B Commerce - how to become successful
B2B Commerce - how to become successfulDivante
 

Plus de Divante (20)

The eCommerce Platforms in the Global Setup
The eCommerce Platforms in the Global Setup	The eCommerce Platforms in the Global Setup
The eCommerce Platforms in the Global Setup
 
eCommerce Trends 2020
eCommerce Trends 2020eCommerce Trends 2020
eCommerce Trends 2020
 
Async & Bulk REST API new possibilities of communication between systems
Async & Bulk REST API new possibilities of communication  between systemsAsync & Bulk REST API new possibilities of communication  between systems
Async & Bulk REST API new possibilities of communication between systems
 
Magento Functional Testing Framework a way to seriously write automated tests...
Magento Functional Testing Framework a way to seriously write automated tests...Magento Functional Testing Framework a way to seriously write automated tests...
Magento Functional Testing Framework a way to seriously write automated tests...
 
Die Top 10 Progressive Web Apps in der Modernbranche
Die Top 10 Progressive Web Apps in der ModernbrancheDie Top 10 Progressive Web Apps in der Modernbranche
Die Top 10 Progressive Web Apps in der Modernbranche
 
progressive web apps - pwa as a game changer for e-commerce - meet magento i...
 progressive web apps - pwa as a game changer for e-commerce - meet magento i... progressive web apps - pwa as a game changer for e-commerce - meet magento i...
progressive web apps - pwa as a game changer for e-commerce - meet magento i...
 
Customer churn - how to stop it?
Customer churn - how to stop it?Customer churn - how to stop it?
Customer churn - how to stop it?
 
eCommerce trends 2019 by Divante.co
eCommerce trends 2019 by Divante.coeCommerce trends 2019 by Divante.co
eCommerce trends 2019 by Divante.co
 
How to create a Vue Storefront theme
How to create a Vue Storefront themeHow to create a Vue Storefront theme
How to create a Vue Storefront theme
 
Game changer for e-commerce - Vue Storefront - open source pwa
Game changer for e-commerce - Vue Storefront - open source pwa Game changer for e-commerce - Vue Storefront - open source pwa
Game changer for e-commerce - Vue Storefront - open source pwa
 
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speech
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speechVue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speech
Vue Storefront - Progressive Web App for Magento (1.9, 2.x) - MM18DE speech
 
How to successfully onboard end-clients to a B2B Platform - Magento Imagine ...
How to successfully onboard  end-clients to a B2B Platform - Magento Imagine ...How to successfully onboard  end-clients to a B2B Platform - Magento Imagine ...
How to successfully onboard end-clients to a B2B Platform - Magento Imagine ...
 
eCommerce trends from 2017 to 2018 by Divante.co
eCommerce trends from 2017 to 2018 by Divante.coeCommerce trends from 2017 to 2018 by Divante.co
eCommerce trends from 2017 to 2018 by Divante.co
 
Designing for PWA (Progressive Web Apps)
Designing for PWA (Progressive Web Apps)Designing for PWA (Progressive Web Apps)
Designing for PWA (Progressive Web Apps)
 
Why is crud a bad idea - focus on real scenarios
Why is crud a bad idea - focus on real scenariosWhy is crud a bad idea - focus on real scenarios
Why is crud a bad idea - focus on real scenarios
 
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentation
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentationvue-storefront - PWA eCommerce for Magento2 MM17NYC presentation
vue-storefront - PWA eCommerce for Magento2 MM17NYC presentation
 
Pimcore Overview - Pimcore5
Pimcore Overview - Pimcore5Pimcore Overview - Pimcore5
Pimcore Overview - Pimcore5
 
Pimcore E-Commerce Framework - Pimcore5
Pimcore E-Commerce Framework - Pimcore5Pimcore E-Commerce Framework - Pimcore5
Pimcore E-Commerce Framework - Pimcore5
 
The biggest stores on Magento
The biggest stores on MagentoThe biggest stores on Magento
The biggest stores on Magento
 
B2B Commerce - how to become successful
B2B Commerce - how to become successfulB2B Commerce - how to become successful
B2B Commerce - how to become successful
 

Git workflow - Michał Pakuła

  • 1. Meet Magento Poland 2015 Michał Pakuła mpakula@divante.pl Divante Git workflow i bezpieczne wydania
  • 2. Meet Magento Poland 2015 ZANIM ZACZNIEMY… Słów kilka o warsztatach oraz potrzebnych nam rzeczach.
  • 3. Meet Magento Poland 2015 Agenda • Czynniki wypływające na bezpieczne wydanie. • Git i standardowy model gałęzi. • Wydanie na środowisku produkcyjnym. • Automatyzacja wydań. • Część praktyczna.
  • 4. Meet Magento Poland 2015 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
  • 5. Meet Magento Poland 2015 CZYNNIKI WPŁYWAJĄCE NA BEZPIECZNE WYDANIE Czyli na co zwracać uwagę na poziomie prowadzenia projektu i pracy z repozytorium.
  • 6. Meet Magento Poland 2015 Najważniejsze Wydanie samo w sobie, to kwestia wykonania kilku prostych czynności na środowisku produkcyjnym. Najistotniejsze jest to, co dzieje się wcześniej.
  • 7. Meet Magento Poland 2015 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.
  • 8. Meet Magento Poland 2015 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.
  • 9. Meet Magento Poland 2015 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.
  • 10. Meet Magento Poland 2015 Jednolita nomenklatura Dla gałęzi tematycznych: feaute/101223-allegro-module bugfix/101225-price-format hotfix/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.
  • 11. Meet Magento Poland 2015 Numeracja oprogramowania
  • 12. Meet Magento Poland 2015 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.
  • 13. Meet Magento Poland 2015 Wersja zewnętrzna i wewnętrzna Na poziomie systemu śledzenia błędów (zewnętrzna): 1.4.2 obecna wersja 1.4.3 przyszła wersja 1.5.0 przyszła wersja Na poziomie systemu kontroli wersji (wewnętrzna): 1.4.2.0 obecna wersja 1.4.2.1 obecna wersja + hotfix 1.4.2.2 obecna wersja + hotfix 1.4.3.0 przyszła wersja 1.5.0.0 przyszła wersja
  • 14. Meet Magento Poland 2015 Określanie numeru wersji [bugfix] Wyeliminowanie błędu... [bugfix] Poprawka... [bugfix] Ujednolicenie... [bugfix] Poprawka... [bugfix] Poprawka... Wersja docelowa: 1.4.3 1.4.3.0 [feature] Dodanie możliwości... [feature] Dodanie modułu... [bugfix] Poprawka... [bugfix] Ujednolicenie... [bugfix] Poprawka... Wersja docelowa: 1.5.0 1.5.0.0 Obecna wersja: 1.4.2 Wersja docelowa: 1.X.X
  • 15. Meet Magento Poland 2015 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).
  • 16. Meet Magento Poland 2015 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ć.
  • 17. Meet Magento Poland 2015 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).
  • 18. Meet Magento Poland 2015 Standardowy model gałęzi Model 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ń.
  • 19. Meet Magento Poland 2015 Przykładowy flow krok po kroku.
  • 20. Meet Magento Poland 2015 Przykładowy flow krok po kroku Zaczynamy 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.
  • 21. Meet Magento Poland 2015 Przykładowy flow krok po kroku Jeden 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
  • 22. Meet Magento Poland 2015 Przykładowy flow krok po kroku Kolejny 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
  • 23. Meet Magento Poland 2015 Przykładowy flow krok po kroku Programista 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
  • 24. Meet Magento Poland 2015 Przykładowy flow krok po kroku Gałąź 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
  • 25. Meet Magento Poland 2015 Przykładowy flow krok po kroku Gałąź z poprawką również scalamy do gałęzi development, analogicznie jak poprzednią. ~$ git checkout development ~$ git pull ~$ git merge --no-ff bug/101220
  • 26. Meet Magento Poland 2015 Przykładowy flow krok po kroku W 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
  • 27. Meet Magento Poland 2015 Przykładowy flow krok po kroku Po 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
  • 28. Meet Magento Poland 2015 Przykładowy flow krok po kroku Na 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
  • 29. Meet Magento Poland 2015 Przykładowy flow krok po kroku Aby 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
  • 30. Meet Magento Poland 2015 Przykładowy flow krok po kroku W 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
  • 31. Meet Magento Poland 2015 Przykładowy flow krok po kroku Od 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
  • 32. Meet Magento Poland 2015 Przykładowy flow krok po kroku W 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
  • 33. Meet Magento Poland 2015 Przykładowy flow krok po kroku Aby 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
  • 34. Meet Magento Poland 2015 Przykładowy flow krok po kroku Gdy 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
  • 35. Meet Magento Poland 2015 Przykładowy flow krok po kroku Bezpoś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
  • 36. Meet Magento Poland 2015 Przykładowy flow krok po kroku Aby 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
  • 37. Meet Magento Poland 2015 Przykładowy flow krok po kroku Aby 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
  • 38. Meet Magento Poland 2015 Przykładowy flow krok po kroku Bardziej 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
  • 40. Meet Magento Poland 2015 Odpowiedzialność poszczególnych gałęzi oraz podstawowe zadady
  • 41. Meet Magento Poland 2015 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.
  • 42. Meet Magento Poland 2015 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.
  • 43. Meet Magento Poland 2015 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).
  • 44. Meet Magento Poland 2015 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.
  • 45. Meet Magento Poland 2015 WYDANIE NA ŚRODOWISKU PRODUKCYJNYM Podstawowe czynności jakie należy wykonać podczas podmiany wersji aplikacji.
  • 46. Meet Magento Poland 2015 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.
  • 47. Meet Magento Poland 2015 Strona przerwy technicznej
  • 48. Meet Magento Poland 2015 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).
  • 49. Meet Magento Poland 2015 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; }
  • 50. Meet Magento Poland 2015 Wpuszczenie ruchu - cookie if (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
  • 51. Meet Magento Poland 2015 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; }
  • 52. Meet Magento Poland 2015 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).
  • 53. Meet Magento Poland 2015 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.
  • 54. Meet Magento Poland 2015 AUTOMATYZACJA WYDAŃ Na podstawie przykładu z życia, zalety automatyzacji oraz sytuacje, w jakich warto ją stosować.
  • 55. Meet Magento Poland 2015 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.
  • 56. Meet Magento Poland 2015 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.
  • 57. Meet Magento Poland 2015 Przykład automatyzacji Z wykorzystaniem projektu na redundantnej architekturze serwerowej zapewniającej HA (High Availability).
  • 59. Meet Magento Poland 2015 • 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ą
  • 60. Meet Magento Poland 2015 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.
  • 61. Meet Magento Poland 2015 Efekt? Około 43 czynności, które zajmowały od 20 do 25 minut!
  • 62. Meet Magento Poland 2015 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.
  • 63. Meet Magento Poland 2015 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.
  • 65. Meet Magento Poland 2015 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).
  • 66. Meet Magento Poland 2015 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"
  • 67. Meet Magento Poland 2015 Wykonanie polecenia Ansible Wykonanie zadań wyłączających stronę przerwy technicznej: ~# ansible-playbook deploy.yml --tags "maintenance_off,haproxy_restart"
  • 68. Meet Magento Poland 2015 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.
  • 69. Meet Magento Poland 2015 CZĘŚĆ PRAKTYCZNA
  • 70. Meet Magento Poland 2015 PODSUMOWANIE
  • 71. Meet Magento Poland 2015 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ń.
  • 72. Meet Magento Poland 2015 Pytania?
  • 73. Meet Magento Poland 2015 Dziękuję za uwagę!