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.
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
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ń.
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.
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.
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ń.