[QE 2017] Piotr Marczydło - Wdrażanie na wulkanie, czyli CI w świecie, który nie znosi opóźnień
•Download as PPSX, PDF•
0 likes•138 views
Prezentacja z VI edycji Quality Excites. Termin „Continuous Integration” robi karierę. Wszyscy w IT używają go tak często, że powoli staje się pustym hasłem. W zderzeniu z praktyką jest jednak różnie, bo do gry włączają się przyzwyczajenia, drogi na skróty kuszą. Dzisiaj każdy może w mgnieniu oka postawić VM i całą infrastrukturę, ale jak przy tym zachować najwyższą jakość? Podczas prelekcji Piotr przybliżył rozwiązanie problemu w prywatnej chmurze DreamLabu przy pomocy Atlassiana. Opowiedział, w jaki sposób jego zespół przeprowadza testy, analizuje kod i monitoruje wdrożenia serwisów, z których korzysta 23 miliony użytkowników w Europie.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to [QE 2017] Piotr Marczydło - Wdrażanie na wulkanie, czyli CI w świecie, który nie znosi opóźnień
Similar to [QE 2017] Piotr Marczydło - Wdrażanie na wulkanie, czyli CI w świecie, który nie znosi opóźnień (20)
More from Future Processing
More from Future Processing (20)
[QE 2017] Piotr Marczydło - Wdrażanie na wulkanie, czyli CI w świecie, który nie znosi opóźnień
- 1. Wdrażanie na wulkanie, czyli CI w świecie, który nie znosi opóźnień Quality Excites, 2017 Piotr Marczydło
- 5. 2 500 domen 350 serwisów 3 000 serwerów i urządzeń
- 8. 8
- 9. Czeka na nas wiele pułapek Brak spójności w projekcie Niska jakość kodu Niska świadomość tego, co dzieje się w projekcie Projekt nie nadaje się do deployowania Koszt zbyt późnej naprawy rośnie dramatycznie Source: Visual Studio Tools for Apache Cordova
- 10. Jak wygląda uproszczony proces developmentu Definiowanie wymagań Projektowanie Implementacja Testowanie
- 11. 11 Przecież mówiliśmy o lepszym, szybszym i tańszym developmencie?
- 12. Continuous Integration Metodologia developmentu Codzienna integracja Automatycznie weryfikowana Zmniejszone ryzyko
- 13. Co wchodzi w skład builda? Kompilacja Testy jednostkowe Testy integracyjne Statyczna analiza kodu Automatyczny deployment Testy funkcjonalne/API Generowanie artefaktów
- 15. 15
- 16. Loc. 1 Loc. 2
- 18. Jakie czekały nas wyzwania? - Automatyka zarządzająca agentami - Rotacja - Bezstanowość i przestrzeń dyskowa - Chaos Monkey Co zyskaliśmy? - Środowisko identyczne z produkcyjnym - Agenty budujące aplikacje o tych samych parametrach, co maszyny w Cloudzie - Kontrolę nad konfiguracją - Skalowalność
- 21. 32 752 32 518 2 681 0 5000 10000 15000 20000 25000 30000 35000 Total Tests Count AllTests successfulTestCount Testy Selenium/Api
- 23. 23 Monitoring
- 24. Source: https://en.wikipedia.org/wiki/Continuous_delivery Co jeszcze? 1. Ilość testów/ratio 2. Czas buildu 3. Czas deployu 4. Analiza kodu
- 25. Chaotic Firefighting Predictable Service Level Agreement Zero touch Continuous Deployment
Editor's Notes
- Cześć nazywam się Piotr Marczydło i pracuję w Dreamlabie Zgodzicie się ze mną, że niewątpliwą zaletą AGILE jest to, że szybko możemy zrobić ta przysłowiowa hulajnoge ten POC, a potem się wrócić i z bagażem doświadczeń zrobić rower, a jeżeli dodamy do tego nowoczesne technologie to postawienie całej infrastruktury to kwestia kilku minut. Jednak co to znaczy szybko i jak zachować przy tym wszystkim najwyższa jakość Wdrażanie na wulkanie, to nie przypadek. W świecie mediów gdzie wszystko musi być "już" każda pomyłka czy opóźnienie jest bardzo kosztowne W czasie prezentacji przedstawię jak zmierzyliśmy się z tymi wyzwaniami oraz rozwiązujemy je z pomocą narzędzi atlassiana Bamboo, Stasha, Jira oraz SonarQube, a to wszystko jest oparte o środowisko cloudowe w prywatnej chmurze Dreamlabu
- Czy jest Dreamlab Spółka wchodząca w skład Grupy Onet-RAS Polska tworząca największe serwisy treściowe w Polsce Onet Fakt NK Przegląd Sportowy VOD
- Jeśteśmy w 5 krajach europy i poza Polską tworzymy takie serwisy na Słowacji, Węgrzech, Serbii i Szwajcarii
- Co przekłada się na duże liczby 23 miliony RU 150 mln PV dziennie Co przekłada się na 7 mln requestów na minutę 4.5 miliarda na dobę
- Ten spory ruch sieciowy jest generowany z 350 serwisów oraz 2500 domen Które są zlokalizowane na pokaźną/dużą liczbą serwerów
- Za tym wszystkim stoją ludzie 40 zespołów w 3 biurach – w Krakowie, Wrocławiu i Warszawie Pracuje u nas Ponad 350 specjalistów Nasze zespoły przeprowadzają ponad 350 wdrożeń dziennie
- Mając z tyłu głowy te liczby zastanówmy się co pozwoli nam dostarczać oprogramowanie LEPSZE to znaczy wysokiej jakości,, przetestowane, zawierające najlepsze praktyki i standardy kodowania SZYBCIEJ czyli buildy nie są eventem – za to ciągłym procesem, testy zrównoleglone i bez planowanych integracji TANIEJ - Wczesne wykrywanie błędów, fix gdy jest to najmniej kosztowne, a testowanie łatwo powtarzalne
- Chwila jak to, powiecie niemożliwe, a gdzie zasada „wybierz dwa”
- To jest IT tutaj się nie da, a też czeka na nas wiele pułapek Uciążliwe merge, no i zarządzanie poprawkami których nikomu nie chce się robić Zawsze warto dopisać kolejną funkcję robiącą to co 3 inne, co prawda bardziej wydajne, ale ukryte w lawinie znaków na całą szerokość utrzymywanie listy zależności To nie tak, że nie działa, po prostu na masterze ktoś coś wrzucił no i na serwerze robiliśmy zmiany, ale „u mnie działa” To wszystko powyżej składa się na najważniejszy czynnik czyli koszt ewentualnej naprawy takich wykresów są dziesiątki, a najważniejsza jest prawa strona po przedstawieniu produktu szerszej publiczności fixy stają się kosztowne
- Żeby temu zapobiec i zapanować nad chaosem warto to sobie ułożyć w proces, wtedy zacznijmy od uproszczonego modelu developmentu Najpierw jest pomysł i definicja wymagań czyli moment w którym określamy wszystkie funkcjonalności aplikacji Projektowanie architektury mając wzgląd na rozwiązywanie problemów biznesowych oraz planowanie zadań Implementacja kodowania Testowanie
- No tak, ale miało być o lepszym, szybszym i tańszym developmencie. A przedstawiony model zakłada ręczną pracę przez co nasza praca nie będziesz ani szybsza ani tańsza przez co trochę dążymy w stronę waterfalla, a mówiliśmy o agile
- CI – czyli metodologia developmentu, codziennej ciągłej stałej integracji która automatycznie weryfikuje buildy Nie są to, nightly buildy, buildy z IDE, Zaplanowane punkty integracji Innymi słowy Ciągła integracja to nie ciągła kompilacja przez co zmniejsza ryzyko przy wdrożeniu
- Skoro automatyczne budowanie ma nam poprawić jakość to jakie komponenty w jaki sposób wpływają na to Kompilacja – zapewnia, ze kod w ogóle się kompiluje... Na każdej docelowej platformie Statyczna analiza kodu – zapewnia lepszy kod (zgodny ze standardami), wcześnie wykrywa problemy i narzuca dobre praktyki Jednostkowe – zapewniają, że rezultat funkcji jest taki jak zakładaliśmy Integracyjne – zapewnia że kod i db lub inne aplikacje stanową jedno i są w stanie się komunikować Automatyczny deployment – w tym momencie mamy pewność, że aplikacja jest deployowalna, zapewnia wersje demo i eliminuje „u mnie działa” Testy funkcjonalne/API – dzięki temu zapewniamy jakość E2E Generowanie – zapewnia aktualną dokumentację i odciąża developerów, zwraca raporty i metryki
- Skoro to już wszystko wiemy, od czego zaczeliśmy w DL
- Gdy ponad 3 lata temu zastawialiśmy jak to ugryźć CI na warsztat wzięliśmy: Jenkins GitLabCI Bamboo -Bardzo ważnym dla nas kryterium była pełna integracja z Jirą czyli narzednie do zarządzania projektami której niestety na tamtą chwilę Jenkins nie był w stanie zapewnić Bamboo i Stash zapewniało nam pełne spięcie z ActiveDirectory oraz zarządzanie uprawnieniami dostępu Najważniejsze czas na wdrożenia Jenkinsa czy GitLabaCi był dużo wyższy niż Bamboo, większość rozwiązań trzeba było oskryptować samodzielnie (a później utrzymywać)
- Po decyzji co do bamboo przyszło nam zaplanować architekturę Mając na uwadze szerokie spektrum technologii z jakimi się mierzymy przy naszej codziennej pracy Potrzebowaliśmy agenta Windows, Mac opartego o farmę MacMini, android obecnie na farmie Inttel Nuc + Docker Oraz cloud czyli nasz główny system gdzie wdrażamy aplikacje oparte o nasze autorskie SDK tj. Python, NodeJS, Java, PHP Razem to wszystko jest ponad 30 nie zależnych środowisk. Jest jeszcze jedna bardzo ważna sprawa której nie mogliśmy pominąć i kryje się w słowie Continuous jest to rozwiązanie High Avability Nie możemy pozwolić sobie bezradność w wypadku przerwania łącza czy odpięcią podstawowej lokalizacji. Celowo to pominąłem na początku slajdu Bamboo Master oraz Bitbucket Server działąją w klastrze w różnych lokalizacjach na rozwiąniu IBM XIV które charakteryzuje się przewidywalną i wysoką wydajnością oraz elastycznością Za to agenty korzystająć z usługi Discovery w chmurze same zmienią docelowy adres mastera Przez co zachowujemy ciągłość dostępu do repozytorium oraz CI dla głównej części systemów
- BYŁO: - Infrastruktura dedykowana pod aplikację Ustalone capasity w wypadku nie spodziewanych zdarzeń było niewystarczające i nie mogliśmy się skalować. Monolity Nauczkę za to dostaliśmy w 2010 roku gdy zaraz po tragedii w smoleńsku ruch na wiadomości.onet okazał się 11x większy. Wtedy podjęliśmy decyzję o RESECIE infrastruktury. Nie opłacalne było kupienie rozwiązania od zewnętrznych dostawców, ale mając własną serwerownie mogliśmy stworzyć coś swojego. Robimy clouda Aplikacje małe i bezstanowe bez wymagań co do infrastruktury. Dostarczamy SDK dla technologii kanonicznych aby ustandaryzować development Rotację, obligatoryjną – a mamy pewność, że nasze aplikacje sa w stanie się uruchomić, a automatyka Cloud działa, a dodatkowo nie przejmujemy się wyciekami pamięci, Chaos Monkey – idąc za wzorem netfliksa chcieliśmy mieć pewność, że mimo awarii jak np. wyłączenie VM nasze serwisy będą nadal funkcjonalne, a automatyka będzie w stanie sobie z tym poradzić
- Na początku warto wspomieć, że Bamboo nie zostało zaprojektowane dla Clouda (od niedawna jest wsparcie dla EC2), a jednak nie do końca świadomie zrobiliśmy to. Jakie czekały nas wyzwania? Automatyka zarządzająca agentami – ważne było aby agenty były w stanie same się uruchomić ale też generowania capasity (dla każdego środowiska) Rotacja – która wyłączała agenty powodowała, że feedback był nie rzetelny Bezstanowość i przestrzeń dyskowa – nie mogliśmy zostawiać danych na dysku potrzebne było ich eleastyczne przekazywanie Chaos Monkey – czyli nie obliczalna rotacja wymagała od nas rozbudowy automatyki Co zyskaliśmy? Środowisko identyczne z produkcyjnym Agenty budujące aplikacje o tych samych parametrach co maszyny w cloudzie - to jest dodatkowy test Kontrolę nad konfiguracją – zapewnie saltstack mozęmy dodać biblioteki i upgradować oraz łatwie wdrożenie przez orchiestrowane Skalowalność w wypadku zapotrzebowania na capasity konkretnej technologii możemy łatwo żąglować agentami dostosowując się do potrzeb
- Kolejnym krokiem aby zapewnić ciągłość i powtarzalność było ułożenie jednego szablonu builda-deploymentu Tutaj napotkały nas problemy 1. Dedykowanie planu per technologia – błędne było założenie z góry że nie da się zrobić uniwersalnego planu mimo iż „endpoint” czyli Providera aplikacji tak na prawdę nie interesuje w jakiej technologii jest aplikacja i spowodowało to duże rozjazdy przy aktualizacji wersji SDK czy zmiana w api providera, a wynikało to z kolejnego problemu 2. Bamboo nie wspiera templatowania czy też „linkowania” – nie mozemy bezpośrednio powiedzieć „to jest wzór i jak coś się zmieni to u mnie też zmień” I to wcale nie jest głupie, bo co tak naprawdę wdrażamy, fronty? Backendy? Workery? Mówiłem o ponad 3000 urządzeń? To dlaczego by nie wdrażać konfiguracji infrastruktury, maszyn wirtualnych czy też zmian w DNSach? To trochę wygląda na walkę z wiatrakami dlatego trzeba podejść do sprawy metodycznie i organizować w miarę mozlwiości rzeczy wspólne w jeden szablon I takie rozwiązanie udało nam się wypracować po dłuższym czasie. Stworzyliśmy referencyjny plan dla aplikacji w naszych SDK który spełnia założenia CI oraz dostosowuje się do wymagań Clouda
- To teraz do roboty wdrażajmy. Przychodzisz do firmy zapoznajesz sie z systemami, oglądasz monitoring i widzisz... Ciągły ruch do naszych aplikacji frontowych to ponad 4 miliony requestów na minutę w ciągu dnia – OK Jesteś dość kumaty więc wybierasz zadanie z Jiry i tworzysz sobie z tego miejsca brancha, ściągasz go na dysk, odpalasz IDE, kodujesz, commitujesz, kodujesz i patrzysz na maila... Bamboo pisze, testy nie przechodzą, SonarQube odpowiedzialny za statyczną analize kodu świeci, że pokrycie testami za niskie czyli masz stały feedback super poprawiasz, szybki pull request koledzy dają okejkę, kolejny mail na Incie przeszły testy i wdrożenie leci, sukces... Tak to działa wykres powyżej przedstawia liczbę wdrożeń w tym samym systemie co generuje te miliony ruchu. Po 17 już nikt nie wdraża CI zmniejsza ryzyko Zapytacie o ten pik o 4 to automatyczne wdrożenie statycznej wersji strony jest ich więcej jednak na potrzebę slajdu zostały odfiltrowane CI zapewnia automatyzację
- Skoro o ryzyku i automatyzacji mowa to pracujemy w zespołach DevOps czy znaczy Development Operations and Tests, zespół jest odpowiedzialny za produkt na całej ścieżce do prod Innymi słowy aplikacja musi być najwyżeszej jakości wchodząc na proda, to zespół jest za nią dopowiedzialny i nikt nie będzie trzymał szafy aż innych przyjdzie naprawić. Do tego niezbędę było przeniesienie odpowiedzialności pisania testów jednostkowych integracyjnych oraz funcjonalnych frontu i API na zespoły developerskie W ten sposób obecnie posiadamy bazę prawie 33 tyś testów w tym ponad 2,6 tyś testów funkcjonalnych odpalanych cyklicznie w procesie CI Dodatkowo testujemy kod wspomnianym SonarQubem Dostępność platform testami syntetycznymi, a serwisów zewnętrznym narzędziem Monit24
- Pracując w firmie gdzie jest 350 specjalistów w tym 4 testerów nie byli byśmy w stanie robić wszystkiego ręcznie W pewnym momencie powiedzieliśmy sobie CI to usługa W modelu SaaS – w tym modelu dystrybucji odbiorcę nie interesuje sprzęt ani środowisko pracy korzysta z oprogramowania jakiego potrzebuje Zrobiliśmy to integrując CI i panel PaaS aplikacją gdzie można zamówić projekt z repozytorium oraz włączyć monitoring procesu który dystrybuujemy per zespół. Z drugiej strony Zaletą wynikającą z takiego rozwiązania jest wysoka kontrola nad tym kto i na ile używa CI oraz stały monitoring dostępności usługi per odbiorca (zespół – projekt) To z kolei pozwala szybko reagować na nieprawidłowości w systemie
- Monitoring najważniejsza część każdego procesu bez znajomości stanu faktycznego nie zrobimy kroku do przodu Jak nam w tym pomaga proces CI
- Dotyczy to developerów którzy tak jak pokazane na pipiline w każdym kroku CI dostają feedback Warto w procesie uwzględnić stały monitoring CI per produkt/zespół i udostępnić metryki ilości wykonanych testów (ratio) – aby mieć pewność, że jakość jest podnoszona Czasu buildu – nasz feature spowodował tego, że dłużej budujemy aplikację Czasu deployu – a mozę wdrażamy dłużej Wyników analizy kodu – czy nie tracimy na jakości, czy utrzymujemy stanadrdy Wiedza i transparentość jest kluczem do sukcesu Z drugiej jako Admin/Ewangelizator CI Zbierać te dane i analizować w ten sposób definiować status procesu Szybciej wykrywać anomalie czy to dotyczące stabilości systemu czy może problemów w zespołach Aby na koniec definiować wąskie gardła i planować rozwój w celu ich wyelimonowania
- Koniec końców musimy odpowiedzieć sobie na pytanie jak bardzo jesteśmy w CI, jaką jakość zachowujemy, czy to może jest używanie PR czy może rollbacki albo ich brak i same roll forward Nie ma gotowej recepty, to nie rozwiązanie out-of-the-box nasze doświadczenia pokazują jak żmudnym jest procesem Każda firma, każdy produkt jest inny, a planowanie rozwoju „bo wiem lepiej” lub „mi się wydaje” jest drogą do nikąd. Podjęliśmy próbę zdefiniowania modelu dojrzałości produktów w CI: 1. Proces jest zdezorganizowany chaotyczny, a sukces zależy od nałożonej pracy indywidualnej i ciężkiej do powtórzenia 2. Podstawy zarządzania projektu lecz nadal ciężkie utrzymanie z braku dokumentacji 3. Są przewidywalne - Ustandaryzowany proces dev oraz udokumentowany 4. To takie aplikacje gdzie naszego odbiorce nie interesuje oprogramowanie czy infrastruktura dostarczamy SLA - Proces jest monitorowany i kontrolowany przez zbieranie i analizowanie danych 5. Ciągła poprawa procesu, dzięki monitoringowi aplikacji i użytkowników, wprowadzane są innowacje dla poprawy jakości Model dojrzałości pozwoli wam odnaleźć się w procesie oraz określić kolejne kroki aby robić to lepiej Commitujcie często -- testujcie i budujcie na docelowych środowiskach CI pomoże wam dostarczać oprogramowanie SZYBCIEJ, TANIEJ i LEPSZEJ JAKOŚCI