Z każdym kolejnym rokiem, kiedy obserwuję działania firm z sektora IT - i nie tylko - w rozwoju własnego stylu DevOps, jestem po prostu pod wrażeniem na ile sposobów można zaimplementować automatyzację CI / CD (ang. Continuous Integration / Continuous Deployment). Ważne jest to, że świadomość automatyzacji rozwiązań IT jest faktem na rynku i jeśli są firmy, które wykonują wiele prac manualnie, to najpewniej istnieją ostatnie miesiące.
Nie znam obecnie architekta oprogramowania, czy lidera zespołu, który pozwoliłby sobie na ryzykowanie z instalacją, czy wdrażaniem rozwiązań metodą potocznie nazywaną "z palca". Biznesowi zależy na szybkim podnoszeniu się z awarii i wiadomo, kiedy mamy automaty na wielu poziomach systemu informatycznego, to odbudowanie fragmentów i całego systemu po awarii powinno zajmować sekundy, czy minuty a nie godziny!
Dzięki obecnym dość powszechnym narzędziom DevOps z dziedziny CI i CD nie musimy zbyt wiele szukać, aby natknąć się na takie rozwiązania w sieci. Tym artykułem chciałbym wprowadzić Was w temat CI/CD i podzielić się moimi spostrzeżeniami z ponad 10 lat pracy z automatyzacją oprogramowania i systemów IT.
Automatyzacja pracy - DevOps w IT
Jest takie słynne powiedzenie o backupowaniu, które można spokojnie sparafrazować i odnieść do CI/CD tzn. "ludzie w IT dzielą się na takich, którzy robią automaty lub takich, którzy będą je robili". Weryfikuje to każda awaria, czy niedostępność systemu i wnioski nasuwają się same: maszyny najlepiej wykonują powtarzalne zadania a ludzie niestety nie są w tym aż tak precyzyjni. Mam tutaj na myśli konkretną sytuację z IT, tzn. w zespole ludzie mogą robić testy z macierzami i odhaczaniem przetestowanych pozycji, mogą pilnować się na wiele sposobów podczas kodowania, mogą robić sobie grupowe przeglądy kodu, głaskać po główkach, przytakiwać do każdej linijki kodu i wiele innych dziwnych zjawisk. Jedno jest pewne, człowiek jest słaby w powtarzalnych czynnościach i zawsze zdarzyć się może jeden mały błąd/nieuwaga, który/która spowoduje awarię w przyszłości.
Automatyzacja i zastosowanie ścieżek CI oraz CD broni ludzi w IT przed tzw. przyzwyczajeniami i to właśnie automatyzacja + czytelne zasady najlepiej pilnują jakości a nie tester, czy lider techniczny. Tak, wiem, znajdą się też liderzy i testerzy, którzy powiedzą, że testy eksploracyjne są niezbędne i jak najbardziej zgadzam się z tym. To co chcę przekazać, że każdy człowiek ma słabsze dni, w przeciwieństwie do testów automatycznych lub wdrożeń automatycznych.
Testowanie automatyczne - Continuous Integration
Jest to element, który powoduje, że mamy powtarzalną "gwarancję" jakości działania naszego kodu. Oczywiście, o ile testy są napisane zgodnie ze sztuką i pokrywają istotne linie, funkcje, klasy rozgałęzienia kodu. Jeśli mamy testy tylko do builderów a nie mamy testów dla głównych funkcjonalnych klas/ścieżek, wówczas nie mamy co mówić o testowaniu a o sztucznym pokrywaniu kodu testami. Tak zupełnie realnie, każdy zespół i lider projektu powinien znać założenia zasad w danym projekcie. Nie zawsze 50% pokrycia kodu to coś co daje nam zapewniania jakości. Z mojego doświadczenia wynika, że 50 % pokrycia kodu testami (jednostkowe + integracyjne) to dobry wynik, pod warunkiem, że testujemy istotne ścieżki używane na produkcji - odnośnie aplikacji internetowych. W przypadku urządzeń elektronicznych z tzw. firmware, pokuszę się o stwierdzenie, że 50% może okazać się zbyt słabym pokryciem, gdyż w urządzeniach np: (Internetu Rzeczy) dochodzą abstrakcje na innym poziomie np: działanie w trybie offline, bez dostępu do sieci, pojawiają się przerwania, które wymusza klient, warunki fizyczne t.j. temperatura pracy i wilgotność powodują zmianę zachowania w działaniu, wrażliwość na linie zasilania, o ile nie ma drugiej linii lub akumulatora, maszyna stanów wdrożona dla trybu online i offline, jakość wykonania obudowy, metod fizycznej instalacji oraz lokalizacja urządzenia, itd. Jak widać jest wiele więcej prawdopodobnych zmian warunków normalnych pracy niżeli w przypadku aplikacji internetowej zainstalowanej gdzieś w chmurze obliczeniowej i podlegającej limitom zasobów, restartom i ew. przytkaniu łącz sieciowych.
Rola DevOps to taka rola, gdzie decydujemy się na to, co warto przetestować automatycznie a co półautomatycznie, co jest core biznesem, a co satelitą. W roli DevOps podchodzimy poważnie do każdego przypadku, aby nie pominąć takich, które pozornie nie są istotone. Dlatego też testowanie automatyczne i metodologie DevOps są tak silnie ze sobą zespojone. W poniższym porównaniu systemów CI / CD jest możliwych wiele scenariuszy testowania i zachęcam z tego miejsca do podnoszenia dyskusji o tym, jak i co warto testować w naszych projektach. Rozmawiajcie o tym w zespołach, jakie zasady przyjmujecie i jakie jesteście w stanie zaakceptować jako minimum. Tak, warto znać minimum, bo jeśli uznamy, że 100% pokrycia to jest to, co chcemy robić, musimy mieć na uwadze, że firma płaci za to, że pisanie testów trwa 80% czasu do kodu, który pisaliśmy w 10% czasu. Nie każda firma i nie każdy właściciel zrozumie to, że tak drogie jest dbanie o jakość. Nie chodzi - jak się domyślacie - dosłownie o zrozumienie tego czasu pracy wymaganego na testy, a o to, jak duże koszty generuje ten proces i jak niewiele osób posiadających firmy była wcześniej inżynierami oprogramowania, którzy sprawdzili w praktyce, co daje wysoka jakość. To trzeba poczuć na własnym podwórku, aby mówić, że coś kosztuje za dużo w IT i oczywiście świadomie wyważyć, czy na pewno 100% pokrycia testami to jest kierunek, w jakim firma może lub/i powinna podążać.
Warto przypomnieć, że testowanie w IT odbywa się na wielu poziomach prac i wg. ideii DevOps oraz TDD to najpierw powstają testy a potem kod. Z praktyki wiem, że spora część ludzi nie chce lub nie może przestawić się na taki sposób pracy. Szkoda, bo jeśli powstaje na początku test, to łatwiej jest wyobrazić sobie z jakich artefaktów powinna składać się implementacja. Jak wiem od znajomych, niestety uczelnie w PL nie uczą tego na takim poziomie, aby człowiek to poczuł na własnej skórze, więc porażki jakie miewają firmy, to jest też koszt wdrożenia juniorów (absolwentów studiów). Tak, edukacja oparta o praktykę z ludźmi z branży ułatwiłaby dużo, ale jak wiemy na uczelni nie płacą tyle, aby ludzie praktykujący sztukę wysokiej jakości chcieli tam zdobywać chleb. Nie zamierzam tym zdaniem położyć ogólnika na całą edukację w PL, ale chciałbym zaznaczyć, że w branży IT w kilku miastach w PL edukowanie z praktycznej jakości wytwarzania oprogramowania jest na poziomie średnim. Wyjaśnię dlaczego tak twierdzę: na podstawie rozmów z ludźmi z branży IT i edukacji, na podstawie prac magisterkich, czy doktorskich, które czytam/przeglądam "do poduszki" od kilku lat. Obserwuję też rynek, zatrudniam ludzi do pracy i widzę, jaki poziom reprezentują absolwenci studiów a jaki ludzie, którzy rok lub więcej przepracowali w firmie developerskiej IT.
Wracając do testów na różnych poziomach - wyróżnić warto kilka podstawowych pojęć:
- testy jednostkowe (modułowe)
- testy integracyjne
- testy systemowe
- testy behawioralne BDD
- testy wydajnościowe
- testy end-to-end
- testy dedykowane dla platform (mam na myśli platformy mobilne, smartfony, urządznia IoT)
Jak widzicie jest tak, że w testowaniu automatycznym jest co robić i oczywiście stąd często konieczność posiadania takiej roli - stanowiska pracy - w zespole DevOps. Z mojej praktyki jest to w tych czasach dość popularne, że zespół robi produkty a dedykowany tzw. tester automatyczny pisze kod automatów potwierdzających, że ścieżki główne w systemie mają pokrycie w automatach.
Z takimi testami automatycznymi idą w parze testy po każdej zmianie, ew. tzw. night build, czyli testy odpalane nocą, w celu potwierdzenia, że integracja w systemie nie została zaburzona. To może mieć wielką moc, kiedy np: wiele zespołów pracuje nad różnymi domenami większego projektu i codziennie pojawiają się tysiące nowych linii kodu i testów do nich. Oczywiście, każdy zespół dba o swoją kontrolę jakości, ale nie zaszkodzi na pewno wszystkie nowe tagi z danego dnia zintegrować w takim night build, który rano wyśle raport tylko wtedy, kiedy nie udało się dokonać automatycznie integracji rozwiązań. Jest to dodatkowy automatyczny nadzorca pracy w rozproszonych zespołach nad większym produktem.
Jak zdążyliście zauważyć, testowanie automatyczne to jest dziedzina w IT i jeden człowiek tego nie robi, a zaleca się w duchu DevOps wdrażanie zarówno do tego procesu wszystkich developerów. jak i wszystkich adminów oraz innych operatorów systemów np: ludzi z monitoringu. Znam kilka takich sukcesów w większych i mniejszych firmach, w których miałem okazję pracować. Rekomenduję zastosowanie podejścia DevOps - to się opłaca!
Wdrażanie automatyczne - Continuous Deployment
Załóżmy, że mamy już nasze testy, wykonują się na CI, więc skoro zakodowaliśmy ficzer, to czas go wdrożyć! Oczywiście, nie zawsze jest tak różowo w projektach IT. Bywają chwile, że zanim zorientujemy się, jak firma w której jesteśmy wdraża, to zaczynamy szukać innej pracy. Oczywiście, nie chodzi tutaj o bunt, ale o trzymanie pewnego poziomu. Polecam zamiast zmieniać miejsce pracy, zaproponować i podjąć wyzwanie wdrożenia wdrażania kodu w sposób automatyczny.
Deployment, czyli wdrażanie kiedyś odbywało się w sposób dość banalny: e-mail lub ticket do admina, on na drugi dzień go znajdował w kolejce zadań i jeśli miał czas, wykonywał ręczne skrypty lub o ile był bardziej ogarnięty jakieś pół-automatyczne procedury wdrożeniowe. Te czasy na szczęście w większości firm się skończyły i nastała epoka otwartych API do narzędzi, które potrafią wdrożyć za nas kod w chmurze publicznej, prywatnej, na kubernetes lub on-premises. Nastały czasy PaaS, czyli platform jako usług, za które płacimy, ale mamy od nich gotowy zestaw narzędzi. Zależnie od tych narzędzi jedni budują specjalny kod do wdrożenia, inni tworzą dedykowane DSL (ang. Domain Specific Language), jeszcze inni tworzą pliki YAML, w celu opisania jak takie automatyczne wdrożenie powinno przebiegać.
Oczywiście jest tak, że wdrażanie automatyczne na produkcję, raczej warto nazwać od razu pół-automatycznym, bo często jest tak, że dopiero po wyrażeniu zgody kod na maszyny produkcyjne jest wdrażany. Oczywiście nie musi to dotyczyć maszyn w środowisku deweloperskim.
Dobrą praktyką jest również stosowanie tzw. canary deployment, tzn. decydowanie na jaki procent klientów ew. pod jaki konkretnie ficzer ew. dla jakich userów ew. jakiej części świata kierujemy wdrożenie. Np: w Facebook mają tak, że Indie stanowią dla nich "piaskownicę" na produkcji i jest tam wdrażany kod produkcyjny jako pierwszy, o ile nie będzie zgłoszeń o awariach, następują wdrożenia na inne kontynenty. Jeśli chodzi o nasze rodzime biznesy, też potrafią sterować procentem ruchu, w ramach wdrożeń i np: na 5 ze 100-tu instancji usług puszczane jest wdrożenie, aby zaobserwować co się dzieje, po czym wdrażamy na kolejne 5, kolejne 10, 20 i 50, po czym, jeśli po kilku dniach nie ma żadnych wad, oznak błędogenności nowej wersji, przełączamy wdrożenie na 100%. Tak, to daje nam w branży IT wielki button zwany powrotem, w sytuacji rozwoju nieścisłości w nowych wersjach. Ten guzik nazywa się rollback i zdarzyło mi się nie kilka razy go użyć, aby nie wywołać regulaminowej awarii. Nie ma się co bać wycofać kodu z np: 5% maszyn na produkcji, kiedy widzimy możliwość poprawy jakości rozwiązania.
Musicie sobie zdawać sprawę z tego, że przy nie ważne jak bardzo dużej ilości automatów i metryk chroniących nas przed awarią, zawsze to właściwa produkcja jest tym systemem docelowym, który jest używany przez klienta tak jak potrafi, t.j. go nauczyliśmy i czasami t.j. chciałby nas zaatakować. Tak, dobrze zdawać sobie sprawę, że w wielu przypadkach automaty ratują nas przed wielką wywałką produkcji, ale to człowiek na końcu w coś klika i jeśli DevOps, który wdraża nie zweryfikuje do końca, czy wdrożenie przebiega w sposób poprawny, to nikt za niego tego najpewniej nie zrobi. To jest też element odpowiedzialności w roli DevOps, której niektóre firmy się boją, bo jak można dać Januszowi dostęp do produkcji! Nie myślmy w ten sposób, bo Januszowi nie musimy dawać dostępu do produkcji, ale zestaw praktyk i narzędzi, aby mógł wdrażać etapami, po tym jak stwierdzi, że nie działa toto dobrze, aby Janusz mógł wycofać. Zaznaczę od razu, że nic nie mam do imienia Janusz, po prostu to takie polskie i popularne imię, którego użyłem dla przykładu.
Kolosalną sprawą jest odpowiedzialność wdrażającego, więc często taką osobę w zespole uczy się codziennymi drobnymi wdrożeniami, buduje się z zespołem i szlifuje narzędzia do wdrożenia oraz wycofywania wdrożeń. Nie żyjemy w buszu, jeśli są jakieś "węże" w kodzie, to na pewno dobrze się ukrywają i wypełzną we wdrożeniu lub tuż po nim. Automatyczne wdrażanie oraz praktyki, jakie tworzymy w zespole w tym obszarze na pewno pozwolą ludziom z IT spokojniej spać ;-)
Słowo dodam jeszcze do tego, jak często wdrażać kod, bo możecie sobie pomyśleć, że najlepiej to jak wszystko jest ok, idealnie, działa na 101% i wszyscy klepnęli swoje taski. Cóż, wg. ideologii DevOps i znanych mi zwinnych praktych (ang. Agile), to tak naprawdę im częściej wdrażamy drobne zmiany, to nad nimi panujemy, więc zgodnie z zasadą "wdrażaj częściej, podnoś się szybciej" warto o tym wspomnieć, że jest to kwestia biznesu oraz wrażliwości na zmiany.
Jak dla mnie warto przystosować się do zasady, że "jedyną stałą jest zmiana" i doprowadzić infrastrukturę IT do takiego stanu, aby klienci nie odczuwali efektów ubocznych wdrożeń. Nie tyle wiem, że to jest możliwe, ale potrafię takie architektury budować, dlatego rekomenduję podejście budowania wysokiej dostępności (ang. High availability) zamiast ściemniać, że może wdrożenia nocne ew. poranne nas uratują.
Z mojego punktu widzenia, są biznesy, gdzie wydawać by się mogło, że nie da się zbyt tanio zbudować HA (t.j. przemysł medyczny, kosmiczny, górniczy, itp.) na wymaganym poziomie, ale praktyka pokazuje, że jeśli zbierze się zespół zgranych ludzi i będą motywowani do dokonywania niemożliwego, to "da się" osiągnąć wysokie HA, tam gdzie ludzie myślą, że jest to niemożliwe. Ba, nawet da się osiągnąć więcej tzn. podzielić się taką wiedzą ze społecznością OpenSource, a to w efekcie powoduje, że inne rozwiązania stają się niezawodne.
Jakie systemy CI / CD mamy obecnie na rynku?
Tutaj przychodzi mi na myśl porównanie systemów CI zrobione na wikipedii, które jest dość dużym uproszczeniem dostępnych narzędzi. Ze swojej strony chciałbym jednak podzielić się moimi prywatnymi spostrzeżeniami, które uzupełnią Waszą wiedzę. Postanowiłem, że w sposób opisowy opowiem o kilku znanych mi CI/CD z wymienieniem swoich spostrzeżeń n.t.
Wiele prezentowanych rozwiązań posiada wspólne cechy, które niosą nam ważną wartość - jeśli obecnie używasz zbyt drogiego lub wolnego CI / CD, bardzo prosto możesz zmigrować do innego. Zazwyczaj wystarczą zmiany w jednym pliku YAML, który definiuje kroki działania i po sprawie.
Aspekt dość istotny w wielu systemach CI / CD, które mamy na rynku, to że większość oferuje nam darmową automatyzację! Tak, każdy w PL dba o to, aby wydać jak najmniej PLN, czyli mamy to co lubimy - żartuję. Jest tak wiele platform, że konkurencja "gryzie" wzajemnie i dochodzi do tego, że można w firmie używać latami za darmo CI/CD - bo firmy, które je robią dostają grube miliony od VC na tworzenie swoich rozwiązań. Tzn. żaden kowalski zużywający 1 CPU co kilka godzin nie jest dla większości straszny. Dochodzą do tego gracze z TOP 5 firm technologicznych, którzy dają za darmochę CI / CD, bo inaczej nie przyciągną klientów do innych usług, które oferują. Czyli CI / CD stały się takim wabikiem na inne usługi: konsultingowe, reklamowe, magazynowe, i inne. Tak, nie pozostaje nic innego jak tylko brać i działać ;-)
Przedstawię w przypadkowej kolejności systemy CI / CD, z którymi się spotkałem i otwieram tym samym dyskusję n.t. Bo jakby nie było, spędzamy jako osoby w roli DevOps tygodniowo godziny na automatyzacji pracy w jednym lub w kilku z tych systemów. Naszą nagrodą - za to, że automaty wykrywają wcześniej potencjalny problem lub awarię przed produkcją - jest fakt radości z podnoszenia kwalifikacji jako DevOps, zapewne wzrost wynagrodzenia, szacunek w branży i oczywiście powodzenie biznesu, bo jak to mawiał jeden gość "nie ryjemy do szuflady" ;-)
Kiedy dotarłeś już do tego miejsca to świetnie! - znasz już podstawy tematyczne do dalszej lektury.
Składam w tym miejscu obietnicę, że w kolejnym odcinku z tej serii podzielę się z Tobą wiedzą o tym, co stanowi detale w temacie. Postanowiłem zacząć od rozgrzewki i okazało się, że art. byłby za długi z detalami ;-)
Już niebawem kolejny artykuł z tej serii:
Porównanie systemów Continuous Integration & Deployment - wybierz CI / CD dla działań DevOps (2 z 2)
Posty
