Post on 22-Jan-2018
Meet Magento Poland 2015
Michał Pakułampakula@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-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.
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.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
Meet Magento Poland 2015
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
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łę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ń.
Meet Magento Poland 2015
Przykładowy flow krok po kroku.
Meet Magento Poland 2015
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.
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
Meet Magento Poland 2015
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
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 - 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
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ę!