Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Git workflow - Michał Pakuła

2,166 views

Published on

Prezentacja Git workflow i bezpieczne wydania

Published in: Business
  • Be the first to comment

Git workflow - Michał Pakuła

  1. 1. Meet Magento Poland 2015 Michał Pakuła mpakula@divante.pl Divante Git workflow i bezpieczne wydania
  2. 2. Meet Magento Poland 2015 ZANIM ZACZNIEMY… Słów kilka o warsztatach oraz potrzebnych nam rzeczach.
  3. 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. 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. 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. 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. 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. 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. 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. 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. 11. Meet Magento Poland 2015 Numeracja oprogramowania
  12. 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. 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. 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. 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. 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. 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. 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. 19. Meet Magento Poland 2015 Przykładowy flow krok po kroku.
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  39. 39. Meet Magento Poland 2015
  40. 40. Meet Magento Poland 2015 Odpowiedzialność poszczególnych gałęzi oraz podstawowe zadady
  41. 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. 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. 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. 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. 45. Meet Magento Poland 2015 WYDANIE NA ŚRODOWISKU PRODUKCYJNYM Podstawowe czynności jakie należy wykonać podczas podmiany wersji aplikacji.
  46. 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. 47. Meet Magento Poland 2015 Strona przerwy technicznej
  48. 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. 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. 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. 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. 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. 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. 54. Meet Magento Poland 2015 AUTOMATYZACJA WYDAŃ Na podstawie przykładu z życia, zalety automatyzacji oraz sytuacje, w jakich warto ją stosować.
  55. 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. 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. 57. Meet Magento Poland 2015 Przykład automatyzacji Z wykorzystaniem projektu na redundantnej architekturze serwerowej zapewniającej HA (High Availability).
  58. 58. Meet Magento Poland 2015
  59. 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. 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. 61. Meet Magento Poland 2015 Efekt? Około 43 czynności, które zajmowały od 20 do 25 minut!
  62. 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. 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.
  64. 64. Meet Magento Poland 2015
  65. 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. 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. 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. 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. 69. Meet Magento Poland 2015 CZĘŚĆ PRAKTYCZNA
  70. 70. Meet Magento Poland 2015 PODSUMOWANIE
  71. 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. 72. Meet Magento Poland 2015 Pytania?
  73. 73. Meet Magento Poland 2015 Dziękuję za uwagę!

×