Automatyzacja i testowanie

Zmiany nie będą dotyczyły tylko kodu samej aplikacji, ale też testów (tworzenie testów jednostkowych nowej funkcjonalności). Jednym z kluczowych atrybutów ciągłej integracji jest wysoki stopień wykorzystania zautomatyzowanych testów. Po zakończeniu wprowadzania zmian na lokalnym komputerze wykonywany jest zautomatyzowany proces kompilacji (build). W procesie tym pobierany jest kod źródłowy z lokalnego repozytorium, który jest następnie kompilowany, łączony z plikiem wykonywalnym, a na końcu przeprowadzane są testy automatyczne. Build uznaje się za prawidłowy, gdy kompilacja oraz testy zakończą się poprawnie, bez błędów.  

Integracja i aktualizacja

Następnym krokiem jest zatwierdzenie zmian w repozytorium. Na tym etapie należy uwzględnić zmiany wprowadzone przez innych członków w zespole, ponieważ w międzyczasie zmiany innego programisty mogły zostać już zintegrowane z głównym repozytorium tworzonego oprogramowania. Należy więc najpierw zaktualizować lokalną gałąź z kodem z głównej gałęzi (master) i ponownie uruchomić zautomatyzowaną kompilację (build). Jeżeli w trakcie tego procesu pojawią się konflikty (zmiany w kodzie kolidujące ze zmianami wprowadzonymi przez innych programistów), należy je rozwiązać i ponownie uruchomić kompilację. Gdy zakończy się ona powodzeniem, zmiany można zatwierdzić i zintegrować z głównym repozytorium. 

W tym momencie wykonywana jest ponowna kompilacja, lecz tym razem jest ona przeprowadzana na serwerze integracyjnym. Zdarza się, że podczas kompilacji na lokalnej stacji roboczej coś może zostać przeoczone, przez co główne repozytorium zostanie zaktualizowane w nieodpowiedni sposób. Dopiero gdy zmiany w głównym repozytorium zbudują się poprawnie na serwerze CI, można je będzie uznać za zakończone sukcesem. 

Jeśli dojdzie do konfliktów w plikach zmienionych przez innych programistów, zwykle będą one wychwycone, gdy programista zatwierdzający zmiany utworzy zaktualizowaną kopię roboczą, a sama kompilacja zakończy się niepowodzeniem. Błąd jest szybko wyłapany, a zadaniem programistów jest zlokalizowanie źródła błędów i naprawienie ich. W środowisku CI należy unikać sytuacji, w których przez dłuższy czas kompilacje integracyjne kończą się błędem – trzeba je naprawić najszybciej, jak to możliwe. 

Po pomyślnej kompilacji na serwerze ciągłej integracji nowe zmiany można wprowadzić na przykład na środowiska testowe, gdzie testerzy będą mogli przeprowadzać testy na aktualnej wersji oprogramowania zawierającej najnowsze zmiany. 

Zarządzanie błędami i powiadomienia

Na każdym etapie procesu ciągłej integracji po stronie serwera, w razie niepowodzenia w budowaniu projektu, można zaimplementować narzędzia raportujące błędy. W ten sposób, w przypadku wystąpienia błędu w którymś kroku kompilacji – odpowiedni użytkownicy mogą zostać powiadomieni, na przykład za pomocą wiadomości e-mail lub powiadomienia na firmowym czacie. 

Przykładowy ogólny schemat procesu ciągłej integracji: 

Praktyka DevOps

Termin DevOps pochodzi z połączenia dwóch słów: development i operations (programowanie i operacje). Służy do określenia podejścia do rozwoju oprogramowania zakładającego zmniejszanie barier pomiędzy zespołami deweloperskimi i operacyjnymi firmy. Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Oznacza to przyjęcie i wdrożenie pewnych praktyk w celu skrócenia czasu od identyfikacji nowego wymagania do momentu jego wdrożenia dla klientów. W podejściu tym wykorzystywana jest omawiana ciągła integracja i ciągłe dostarczanie, które pomagają skrócić czas wprowadzenia produktu na rynek i stworzyć oprogramowanie lepszej jakości. 

Historia i rozwój

Celem DevOps jest skrócenie czasu wprowadzenia produktu na rynek. Filozofia DevOps narodziła się w 2008 roku podczas konferencji Agile w Toronto, kiedy  Patrick Debois wygłosił wykład pod tytułem „Infrastructure and Operations“. Wyjaśnił w nim zastosowanie podejścia Agile do budowy infrastruktury, a na koniec zaproponował lepszą metodę komunikacji oraz pomysły, dzięki którym programiści mogliby „ poszerzać swoje horyzonty”, w sensie pogłębiania wiedzy systemowej niezbędnej do zapewnienia płynniejszego procesu wydawania oprogramowania. Mijały lata, a podejście DevOps stawało się coraz bardziej popularne, a w ślad za nim pojawiła się nowa rola w świecie IT – inżynier DevOps.  

Rola inżyniera DevOps

Inżynier DevOps stanowi swego rodzaju pomost pomiędzy programistami a działem operacyjnym. W większości przypadków rola, jaką przyjmuje, jest ich mieszanką (inżynierowie ci muszą posiadać wiedzę niezbędną do doradzania i zarządzania problemem z obu dyscyplin). W niektórych przypadkach odpowiedzialność inżyniera DevOps związana jest z ciągłą integracją i dostarczaniem. Inne obowiązki obejmują zarządzanie infrastrukturą, zazwyczaj w postaci kodu (IaC) oraz pomoc we wdrażaniu optymalnych praktyk DevOps w całej firmie. Czasem inżyniera DevOps postrzega się go także jako osobę odpowiedzialną głównie za utrzymanie oprogramowania w środowisku produkcyjnym i automatyzację procesów, rozwiązywanie problemów, administrowanie systemem.  Rola inżyniera DevOps jest zróżnicowana i może zmieniać się w zależności od firmy. 

Zalety podejścia DevOps

Efektywność i współpraca 

Zespoły, które wdrażają podejście DevOps, stają się bardziej wydajne, dzięki czemu tworzone oprogramowanie wydawane jest nie tylko szybciej, ale też jest bardziej stabilne. Lepsza współpraca i zwiększona produktywność pozwalają też osiągać cele biznesowe, takie jak szybsze wprowadzenie produktu na rynek czy utrzymanie jego niezawodności i stabilności w każdych warunkach. Zastosowanie metodyki DevOps nie tylko pozwala zautomatyzować i optymalizować procesy za pomocą technologii. Jest to przede wszystkim zmiana kultury wewnątrz organizacji i ludzi zaangażowanych w ten proces.  

Wdrożenie kultury DevOps wymaga głębokich zmian w dotychczasowym sposobie pracy zespołów i przestrzegania określonych zasad, jednak te zmiany pozwalają stworzyć środowisko pracy o wysokiej wydajności.   Cechą charakterystyczną DevOps jest ścisła współpraca między zespołami. Różne zespoły, na przykład zespoły deweloperów i odpowiedzialne za operacje, muszą dzielić się swoimi procesami, priorytetami i problemami. Muszą także wspólnie planować pracę oraz cele i środki związane z ich osiągnięciem. W miarę jak zespoły dostosowują się do nowej rzeczywistości, obowiązki w poszczególnych rolach również zaczynają się poszerzać. Na przykład deweloperzy stają się odpowiedzialni nie tylko za tworzenie aplikacji w fazie programowania, ale też za wydajność i stabilność w fazie działania. Jednocześnie zespół operacji uwzględnia nadzór, zabezpieczenia i zgodność w fazach planowania i programowania.  

Elastyczność i reaktywność 

Elastyczność zespołów pozwala na wydawanie oprogramowania w krótszych cyklach. Łatwiej jest planować wdrażanie zmian i zarządzać ryzykiem – to droga do stworzenia stabilnego produktu. Krótsze cykle wydawania nowych wersji pozwalają także sprawniej reagować na zmiany zachodzące na rynku, dzięki czemu można szybciej dostosować się do zmian potrzeb klientów i nie odstawać od konkurencji. Podejście DevOps stanowi state-of-the-art nowoczesnego tworzenia oprogramowania i jest dziś pierwszym wyborem wielu firm z tego powodu, że promuje najlepsze praktyki niezbędne do poprawy jakości oprogramowania. DevOps wymaga zmiany nie tylko w sposobie myślenia o infrastrukturze, ale także w  zakresie dobrego projektowania i organizowania wewnętrznej infrastruktury firmy.   

Ciągłe testowanie 

Ciągłe testowanie (Continuous Testing, CT) to umiejętne wykorzystanie pewnych narzędzi i technik. Cytując sylabus ISTQB, ciągłe testowanie to:  

„Podejście obejmujące proces wczesnego, częstego, szerokiego, automatycznego testowania w celu otrzymania możliwie szybko informacji zwrotnej o poziomie ryzyka biznesowego związanego z aplikacją przed jej wydaniem”.  

Podejście to znacznie skraca czas potrzebny do wykonania testów manualnych. 

Głównym celem wprowadzenia podejścia CI/CD jest poprawa jakości wydawanego oprogramowania, a ciągłe testowanie i kontrola powinny być częścią tego procesu.  Celem ciągłego testowania jest zapewnienie, że wydawane oprogramowanie będzie niezawodne.  W tym celu tworzy się różnego rodzaju testy, które mogą być wykonywane automatycznie za każdym razem, gdy oprogramowanie jest budowane. 

Poziomy testów w ciągłym testowaniu 

1. Testy jednostkowe – bazę testów automatycznych stanowią testy jednostkowe. Są one wykonywane za każdym razem, gdy oprogramowanie jest kompilowane i budowane.  

2. Testy integracyjne – kolejnym poziomem testów, który należy włączyć, są testy integracyjne. Są one przeprowadzane po testach jednostkowych i wykorzystują rzeczywiste dane. Testy integracyjne są ważną fazą w ciągłym testowaniu, ponieważ odpowiadają za testowanie całego systemu, a nie tylko tworzonego kodu.  

3. Testy akceptacyjne (E2E) – ostatnią fazą są testy akceptacyjne. W tej fazie wykonywane są testy przygotowane przez zespół QA w celu przetestowania systemu z punktu widzenia użytkownika. Celem tej fazy jest weryfikacja wymagań użytkownika i ich walidacja. 

Kontrola kodu 

Oprócz różnych faz testowania, istnieje także faza kontroli kodu. Polega ona na sprawdzeniu kodu przy wykorzystaniu zestawu reguł wykorzystywanych do sporządzenia raportu na temat samego oprogramowania. Można ją podzielić na dwie fazy:  

1. Przegląd kodu wykonywany przez programistę, który nie jest  jego autorem. Przed integracją z główną gałęzią (master) kod musi zostać zatwierdzony. Członkowie zespołu sprawdzają kod i dodają komentarze, jeśli jakieś fragmenty wymagają zmian. W tym przypadku autor kodu dokonuje zmian na ich podstawie, a po skończonej pracy kod ponownie trafia do przeglądu. Jeśli nikt nie będzie miał zastrzeżeń – kod zostanie zaakceptowany i scalony z główną gałęzią. 
2. Faza statycznej analizy jest wykonywana przez odpowiednie narzędzia. Kod może zostać wtedy zweryfikowany przez pewne reguły, na przykład sprawdzające złożoność metod.  

Automatyzacja i shift-left testing 

Ciągłe testowanie wykorzystuje podejścia automatyzacji do przyspieszenia testowania poprzez przyjęcie podejścia shift-left testing, które łączy etapy wytwarzania oprogramowania i zapewniania jakości. Takie podejście może obejmować zestaw przepływów pracy testów automatycznych, które można łączyć z narzędziami raportującymi i metrykami w celu otrzymania jasnego obrazu jakości oprogramowania. 

Zapewnia to zespołom projektowym otrzymanie szybkiej informacji zwrotnej na temat jakości oprogramowania. Pozwala również testować na wcześniejszych etapach wytwarzania oprogramowania oraz zwiększyć pokrycie testami, eliminując wąskie gardła testowe, takie jak: dostęp do współdzielonych środowisk testowych czy oczekiwanie na stabilny interfejs użytkownika. 

Ciągłe testowanie niesie ze sobą szereg korzyści, takich jak: 

• Integrowanie zespołów testowych, deweloperskich i operacyjnych na każdym etapie cyklu życia oprogramowania. 
• Pozwala na wdrożenie testów automatycznych w takim zakresie, jak to tylko możliwe, aby stale testować kluczowe funkcje. 
• Szybkie i ciągłe informacje zwrotne, które są istotne również dla biznesu. 
• Usunięcie wąskich gardeł w kwestii dostępności środowisk testowych, które mogą być stale dostępne. 
• Pozwala na stałe i aktywne zarządzanie jakością w całym etapie dostarczania oprogramowania.  

Fundamenty ciągłego testowania 

Ciągłe testowanie opiera się na kombinacji określonych narzędzi i technik. Odpowiednie ich wdrożenie tworzy system, dzięki któremu znacząco można ograniczyć liczbę błędów przedostających się na środowiska rozwojowe lub produkcyjne. Większość błędów ma bardzo krótką żywotność, ponieważ są one wyłapywane przez testy. Odpowiednie zaimplementowanie tego podejścia powinno rozpoczynać się na jak najwcześniejszym etapie cyklu życia oprogramowania, aby móc je odpowiednio budować, aktualizować i (w razie potrzeby) refaktoryzować. Sama budowa i działanie zależą w głównej mierze od potrzeb projektowych – inne testy i techniki będą wykorzystywane do testowania sklepu internetowego, inne do testowania systemów w branży automotive. Lecz niezależnie od przypadku, cel pozostanie ten sam – uzyskanie jak najszybciej informacji zwrotnej w przypadku wystąpienia błędu. 

Projektowanie małych komponentów i usług 

Idea ciągłego testowania polega na maksymalnym zautomatyzowaniu procesów testowania i wdrażania oraz zapewnieniu, że każdy komponent aplikacji może zostać poddany testom, gdy tylko zostanie opracowany. Przykłady, które mogą ułatwić implementację tego podejścia to: projektowanie małych komponentów i usług oraz projektowanie danych testowych wykorzystywanych w ciągłym testowaniu. 

Projektowanie małych komponentów i usług – nowe komponenty powinny nie tylko spełniać określone funkcje w trakcie działania programu, ale również być w pełni testowalne niezależnie od innych komponentów. Celem jest zapewnienie, że każda w pełni przetestowana usługa będzie spełniała swoje zadania zgodnie z założeniami, aby w trakcie ich łączenia i przejścia do etapu testów integracyjnych komponenty bezproblemowo współpracowały ze sobą.. Należy więc już na etapie projektowania odpowiednio przygotować architekturę i ograniczyć sprzężenie komponentów tak bardzo, jak to możliwe. W efekcie zyskamy komponenty bardziej stabilne, które zmniejsza ryzyko, że jakakolwiek zmiana dokonana w komponencie „A” spowoduje nieoczekiwaną zmianę zachowania w innych komponentach. Ograniczenie połączeń między nimi upraszcza proces testowania, rozwiązywania problemów oraz konserwacji. Dodatkowo w łatwiejszy sposób można izolować ewentualne problemy – analizie zostanie poddany konkretny komponent, bez potrzeby przeszukiwania ich grup i zależności między nimi. 

Projektowanie danych testowych wykorzystywanych w ciągłym testowaniu 

Posiadanie w pełni zautomatyzowanego rozwiązania do zarządzania danymi testowymi jest niezbędne do solidnego wdrożenia ciągłego testowania. Złym podejściem byłoby na przykład kopiowanie produkcyjnej bazy danych w celu utworzenia danych testowych, nie anonimizując uprzednio wrażliwych danych. Tworzenie nowych zestawów danych testowych od zera dla każdej serii testów również nie jest dobrym pomysłem ze względu na bardzo słabą efektywność, zwłaszcza gdy nie są generowane automatycznie. 

Jak zatem stworzyć skuteczne rozwiązania do generowania i zarządzania danymi testowymi? Z pomocą przychodzą pewne charakterystyki, do których można zaliczyć na przykład: 

• Tworzenie i generowanie danych testowych 
  Daje możliwość tworzenia nowych, zbiorczych zestawów danych uwzględniających zależności, tak jakby pochodziły ze środowiska produkcyjnego. 
• Możliwość pobrania pewnego podzbioru danych produkcyjnych 
  Na podstawie określonych kryteriów, maskowania wrażliwych pól i umieszczania ich w środowisku testowym, zachowując ich integralność referencyjną. Najtrudniejsza w realizacji jest ostatnia część: wrażliwe pola muszą być zamaskowane w taki sposób, aby zachować oryginalne powiązania między danymi. Przykładowo, jeśli wartość numeru PESEL musi zostać zamaskowana i zastąpiona niepowiązaną wartością, każde odwołanie do tego numeru PESEL w bazie danych musi zostać zamaskowane tą samą wartością. 
• Możliwość maskowania i transformacji danych 
  Rozwiązanie powinno też zapewnić możliwość automatycznego porównania danych wstępnie zamaskowanych, aby upewnić się, że nie doszło do ich utraty i że proces maskowania nie spowodował błędów w ich integralności. 
• Możliwość przesyłania danych 
  Proces polegający na przesyłaniu wyodrębnionych, zamaskowanych danych na środowiska testowe, z zachowaniem integralności. Proces ten powinien obejmować funkcje dodawania, edytowania, aktualizacji i usuwania. 
• Możliwość odświeżania danych 
  Polega na okresowym przeglądzie i usuwaniu starych pakietów danych testowych oraz zamienianiu ich na nowy zestaw. 
• Ekstrakcja danych i tworzenie ich podzbiorów 
  Pozwala na tworzenie mniejszych kopii danych produkcyjnych zdefiniowanych za pomocą określonych kryteriów. 
• „Postarzanie” danych 
  Technika, w której dane są zmieniane w celu dopasowania ich do określonych, specyficznych warunków i wykorzystania ich w pewnych procesach (na przykład symulacji określonej godziny lub daty). 
• Możliwość tworzenia i wyodrębniania danych testowych 
• Zarządzanie zbiorami danych 
• Wykorzystanie narzędzi, które umożliwiają nie tylko zarządzanie wieloma zbiorami danych, ale także ich archiwizację i wersjonowanie.  

Rola testów jednostkowych w ciągłym testowaniu 

Podstawę testów w podejściu ciągłego testowania, zgodnie z piramidą testów, stanowią testy jednostkowe. Są one najszybsze w wykonaniu i sprawdzają działanie oprogramowania we wczesnej fazie jego wytwarzania. Powinno ich więc być jak najwięcej (przy zachowaniu odpowiedniego stosunku liczby do jakości – nie jest prawdą, że większa liczba testów stanowi o jakości).  

Projektowanie testów jednostkowych 

Zdarza się, że testy jednostkowe są źle zaprojektowane i zamiast jednostek testują kompletne przypadki użycia (wywołanie metod, asercje, wywołanie większej liczby metod i tworzenie większej liczby asercji). Takie testy są zwykle niestabilne, a błędy wykryte w jednej części kodu mogą maskować inne błędy i utrudniać ich wykrycie. Aby temu zapobiec, należy przeanalizować takie testy, wyodrębnić z nich poszczególne, testowane funkcjonalności i asercje i rozbić je na mniejsze testy sprawdzające każdą funkcjonalność z osobna. 

Implementacja testów na różnych poziomach 

Testowanie bardziej złożonych ścieżek, dajmy na to przypadków użycia, powinno zostać zaimplementowane na przykład w testach akceptacyjnych. W ciągłym testowaniu można wykonywać wszystkie rodzaje testów, lecz im wyższy poziom testów, tym liczba przypadków testowych powinna być mniejsza (są one mniej stabilne, czas ich wykonywania jest dłuższy, wykrywają błędy w późniejszych etapach, przez co wydłuża się czas naprawy, a koszt rośnie). 

Dotyczy to zwłaszcza testów UI (User Interface), gdy testowana jest logika biznesowa i zachowanie interfejsu użytkownika. Może tu dojść do wielu współzależnych awarii. Oddzielenie warstwy interfejsu od systemu bazowego, aby logika biznesowa mogła zostać opatrzona zaślepkami (mock) jest istotną zmianą zbliżającą nas do większej stabilności testów. 

Jednym z podejść jest uruchamianie testów jednostkowych w sposób ciągły, a testów wyższych poziomów – na żądanie (nie muszą one być uruchamiane automatycznie w trakcie budowy projektu w narzędziu ciągłej integracji – zamiast tego, istnieje możliwość uruchomienia ich w sposób manualny, gdy potrzeba). 

Rola podejścia TDD 

Praktykowanie podejścia TDD (Test-Driven Development) w wytwarzaniu oprogramowania ułatwia zrozumienie i wdrożenie ciągłego testowania. W TDD testy tworzone są przed implementacją funkcjonalności. Najpierw tworzony jest mały test, po którym następuje implementowanie powiązanego fragmentu całej funkcjonalności. Następnie dokonuje się refaktoryzacji w celu ulepszenia kodu i wyeliminowania ewentualnych powieleń. Dzięki ciągłemu testowaniu otrzymujemy natychmiastową informację zwrotną na każdym z tych kroków. Nie tylko z tego jednego testu, który jest w danym momencie pisany, lecz ze wszystkich powiązanych testów, bez dodatkowego wysiłku i zaangażowania ze strony programisty. Dzięki temu może on skupić się w pełni na projektowaniu i pisaniu kodu, zamiast rozpraszać się koniecznością uruchamiania testów. 

Cel ciągłego testowania 

Zarówno w podejściu TDD, jak i w ciągłym testowaniu, celem jest jak najszybsze uzyskanie informacji zwrotnej. Pod wieloma względami naturalnym rezultatem skutecznego stosowania TDD jest dobrej jakości zestaw testów. Różnica polega na tym, że stosując ciągłe testowanie, zyskuje się dodatkowe źródła informacji zwrotnych. Stary aksjomat podejścia TDD mówi, że testy sprawdzają poprawność kodu, z kolei kod weryfikuje poprawność testów. Testy sprawdzają również projekt kodu – źle zaprojektowany kod jest trudny do przetestowania.  

Jakie narzędzia wykorzystywane są w procesie dostarczania oprogramowania z CI/CD? 

Jenkins 

Jenkins to serwer ciągłej integracji (CI) typu open source.  Kontroluje kilka etapów procesu dostarczania oprogramowania, takie jak testowanie, kompilacja i wdrażanie. Popularność tego narzędzia wynika między innymi z jego możliwości śledzenia i monitorowania powtarzalnych działań pojawiających się w trakcie prac nad projektem. Każda zmiana w aplikacji jest kompilowana i testowana, a w razie wykrycia błędu Jenkins ostrzeże zespół o problemach. 

Wdrożenie kodu na produkcję 

Jednym z podstawowych zastosowań Jenkinsa jest możliwość wdrażania kodu na produkcję. Jeśli wszystkie testy opracowane dla danej funkcji lub releasu zakończą się powodzeniem, Jenkins może automatycznie opublikować kod na środowisku staging lub produkcyjnym (jest to właśnie przykład Continuous Deployment opisanego w poprzednim artykule). 

Automatyzacja workflow i różnych zadań 

Innym przypadkiem, w którym można użyć Jenkinsa, jest m.in. automatyzacja workflow. Na przykład, gdy programista pracuje na kilku środowiskach, w pewnym momencie zajdzie konieczność instalacji lub aktualizacji pewnych komponentów na każdym z nich. Jeśli instalacja lub aktualizacja wymaga wykonania wielu kroków, przeprowadzenie jej ręcznie może skutkować pojawieniem się błędów, a dodatkowo będzie czasochłonne. Zamiast tego wszystkie kroki potrzebne do finalizacji można odpowiednio skonfigurować w Jenkinsie. Dzięki temu cały proces będzie stabilny i szybki, bo też zawsze będzie wykonywany identycznie. 

Konfiguracja zadań 

Jenkins umożliwia tworzenie zadań (Jenkins Jobs) na różne sposoby. Konfigurację można stworzyć całkowicie przez UI, przeklikując odpowiednie opcje, lecz lepszym wyborem jest utworzenie pliku konfiguracyjnego i zdefiniowanie w nim wszystkich niezbędnych kroków. W Jenkinsie wykorzystuje się w tym celu skrypty pisane w języku Groovy. Zaletą w stosowaniu tej opcji jest dodatkowo to, że plik konfiguracyjny można przechowywać wraz z kodem dotyczącej go aplikacji. Dzięki temu mamy zapewnione wersjonowanie zmian i powstaje kopia zapasowa, przydatna w przypadku wystąpienia awarii. 

Rozszerzalność poprzez pluginy 

Możliwości Jenkinsa można rozszerzać dzięki wielu pluginom dostępnym na stronie https://plugins.jenkins.io/. Ich liczba pozwala na dowolne skonfigurowanie serwera pod konkretne potrzeby, począwszy od zmiany wyglądu elementów interfejsu użytkownika po możliwość integracji z zewnętrznymi serwisami lub aplikacjami czy modyfikujące kroki w tworzonych jobach.  

GitLab 

Innym narzędziem, o którym warto wspomnieć, jest GitLab. Serwis ten nie tylko pozwala na tworzenie i przechowywanie repozytoriów kodu, ale także udostępnia narzędzia do wersjonowania oprogramowania, zarządzania zadaniami oraz procesami CI/CD. Pozwala on wszystkim członkom zespołu współpracować na wszystkich etapach projektu, upraszczając tworzenie oprogramowania. 

Funkcjonalności GitLaba 

GitLab to internetowe repozytorium Git, które umożliwia zespołom programistów planowanie, kodowanie, testowanie, wdrażanie i monitorowanie zmian tworzonego oprogramowania w jednym miejscu. Natomiast Git to dobrze wszystkim znany system kontroli wersji. 

Jedną z istotnych możliwości jest śledzenie błędów: GitLab posiada wbudowany system umożliwiający zespołom tworzenie, przypisywanie i śledzenie błędów. Zapewnia także tablicę zarządzania projektami z konfigurowalnymi przepływami pracy (workflow) w celu wizualizacji zadań i postępów. 

Inną kluczową funkcjonalnością GitLaba są zintegrowane potoki CI/CD (pipelines). Dzięki temu można łatwo zautomatyzować procesy testowania, budowania i wdrażania, zapewniając dokładne testowanie zmian w kodzie przed połączeniem z główną bazą kodu i wdrożeniem w środowisku produkcyjnym. 

GitLab posiada także wewnętrzny system wiki, umożliwiający zespołom tworzenie i utrzymywanie dokumentacji projektowej. 

Podsumowanie 

Podejście Continuous Integration wraz z Continuous Development i Continuous Testing stanowią komplementarne praktyki. Continuous Development umożliwia obserwowanie wdrażanych zmian w czasie rzeczywistym i jednocześnie eliminuje proces ręcznego śledzenia zmian. Błędy znalezione na jak najwcześniejszym etapie są najszybsze i najtańsze w naprawie. 

Budowanie aplikacji wraz z przeprowadzeniem testów na lokalnym środowisku może zająć kilka minut, a ich przeprowadzenie daje pewność, że wprowadzone zmiany będą przygotowane do integracji z główną gałęzią repozytorium. Czasem zmiany mogą budzić szczególne wątpliwości –   na przykład, gdy modyfikacji wymagają pliki konfiguracyjne. W takim przypadku można wykonać pełną kompilację i uruchomić wszystkie testy, aby mieć pewność, że zmiana nie spowodowała błędów w innych obszarach aplikacji, a kod jest bezpieczny i może zostać dodany do głównego repozytorium. 

Ciągła integracja ma na celu identyfikowanie problemów, ale może również posłużyć jako narzędzie do zmniejszania kosztów uruchamiania testów wyższego poziomu – wykrycie błędów na etapie testów jednostkowych sprawi, że testy z pozostałych poziomów będą bardziej stabilne, co daje dodatkową pewność co do jakości. at the capabilities are within the connectivity management framework. At Inetum, we are a partner of Cumulocity IoT, which has a network of partners providing platform-compatible devices with substantial connectivity capabilities.

Przejdź do:

1. 1. Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)
2. 2. Wyzwania CI/ CD
3. 3. Czym jest ciągłe dostarczanie i automatyzacja CI/CD?
4. 4. Continuous Delivery (CD) 
5. 5. Korzyści ciągłego dostarczania (CD)
6. 6. Automatyzacja vs. manualne wdrażanie
7. 7. Podsumowanie

Continuous Integration, Delivery and Deployment to praktyki rozwoju oprogramowania, które w ostatnich latach zdobyły dużą popularność. Gdybyśmy mieli je podsumować jednym słowem, brzmiałoby to: automatyzacja. Wszystkie te trzy praktyki sprowadzają się do automatyzacji procesu testowania i wdrażania, minimalizacji (lub całkowitego eliminowania) potrzeby ingerencji człowieka, redukcji ryzyka wystąpienia błędów oraz ułatwienia tworzenia i wdrażania oprogramowania do tego stopnia, że może to zrobić każdy programista w zespole. Poznaj kluczowe praktyki i korzyści w zakresie automatyzacji CI/CD.  

Definicja Continuous Integration (CI) oraz Continuous Delivery (CD)

Ciągła integracja

Continuous Integration, CI jest praktyką stosowaną w procesie wytwarzania oprogramowania polegającą na częstym, regularnym integrowaniu bieżących zmian w kodzie do głównego repozytorium aplikacji. Zwykle programiści włączają swoje zmiany co najmniej raz dziennie, co przy zespole składającym się z kilku lub kilkunastu osób skutkuje wieloma integracjami wykonywanymi każdego dnia. Każda integracja jest weryfikowana przez zastosowanie automatyzacji w projekcie (włączając również testy automatyczne) w celu jak najszybszego wykrycia ewentualnych błędów integrowanego kodu. Stosowanie tego podejścia prowadzi do znacznego zmniejszenia liczby problemów związanych z integracją i umożliwia szybsze tworzenie spójnego oprogramowania.

Ciągłe dostarczanie

Continuous Delivery, CD – jest praktyką inżynierii oprogramowania polegającą na regularnym wydawaniu kolejnych wersji oprogramowania w krótkich cyklach. Oznacza to, że z każdą kompilacją budowana jest nowa wersja całego tworzonego oprogramowania. Nie znaczy to jednak, że oprogramowanie jest od razu wypuszczane na środowisko produkcyjne. Nic jednak nie stoi na przeszkodzie, aby to zrobić, gdyby zaszła taka potrzeba. Ta nieznaczna różnica dotycząca automatycznego wdrażania zmian bezpośrednio na środowisku produkcyjnym odróżnia ciągłe dostarczanie od ciągłego wdrażania (Continuous Deployment) – w którym to każda kompilacja całego oprogramowania kończy się wydaniem kolejnej wersji na środowisku produkcyjnym. Zespoły developerskie dbają o to, aby nowe funkcje były dodawane w małych pakietach, dzięki czemu ewentualne wydanie nowej wersji oprogramowania może nastąpić szybko i w dowolnym momencie. W praktyce maksymalizuje to możliwość uzyskania szybkiej informacji zwrotnej na temat oprogramowania zarówno z perspektywy biznesu, jak i technicznej.

Wyzwania CI/CD

O ciągłej integracji po raz pierwszy napisał Kent Beck w swojej książce pod tytułem „Extreme Programming Explained”, wydanej po raz pierwszy w 1999 roku. Ideą CI było: jeżeli regularna integracja kodu jest dobra – dlaczego nie wykonywać jej przez cały czas? „Cały czas” oznacza: za każdym razem, gdy ktoś wprowadza zmianę w systemie kontroli wersji.

Problem z ciągłą integracją, dostarczaniem i wdrażaniem polega jednak na tym, że konfiguracja nie należy do najprostszych czynności i zajmuje dużo czasu, zwłaszcza jeśli zespół ma z nią do czynienia po raz pierwszy lub postanowiono wdrożyć proces do istniejącego już projektu.

Jednak korzyści płynące z wprowadzenia tych praktyk są warte poświęconego czasu. Przejawi się to w mniejszej liczbie błędów, ułatwieniu ich identyfikacji i naprawy, a ostatecznie w stworzeniu oprogramowania lepszej jakości.

Czym jest ciągłe dostarczanie i automatyzacja CI/CD?

Ciągła integracja (CI).

Kluczowe aspekty skutecznej ciągłej integracji

Przyjrzyjmy się CI jeszcze bliżej. Ciągła integracja na przestrzeni ostatnich kilku lat stała się w zasadzie standardem w zwinnych metodykach wytwarzania oprogramowania. Początkowo, w połączeniu z uruchamianiem automatycznych testów jednostkowych na lokalnym środowisku programisty, miała na celu zapewnienie, że programista nie włączy kodu, który mógłby powodować błędy w aplikacji. Z biegiem czasu metoda ta ewoluowała.

Obecnie kompilacje uruchamiane są na serwerach ciągłej integracji, które budują projekt oraz uruchamiają zautomatyzowane testy – automatycznie, przy każdej zmianie dodanej przez programistów, lub okresowo. Wynik (w postaci raportów, logów) generowany jest po zakończeniu procesu budowania. Obecnie podejście ciągłej integracji jest wykorzystywane nie tylko w metodykach zwinnych, ale również w innych metodykach wytwarzania oprogramowania.

Oprócz przeprowadzania testów jednostkowych i integracyjnych można też uruchamiać testy statyczne i dynamiczne, mierzyć i profilować wydajność, tworzyć dokumentację bazującą na kodzie źródłowym oraz upraszczać manualne procesy zapewnienia jakości. W ten sposób ciągła integracja zapewnia również ciągłą kontrolę jakości oprogramowania.

Dobrze funkcjonująca ciągła integracja opiera się na spełnieniu pewnych warunków wstępnych, a także przestrzeganiu kilku podstawowych praktyk. Przy jej wdrażaniu należy zadbać przede wszystkim o trzy rzeczy:

1. Narzędzie kontroli wersji
   Wszystko w projekcie musi być ewidencjonowane w jednym narzędziu kontroli wersji: kod, skrypty, bazy danych, skrypty kompilacji i wdrażania oraz wszystko inne, co jest niezbędne do tworzenia, instalowania, uruchamiania i testowania aplikacji.
2. Narzędzie do zautomatyzowanej kompilacji
   Należy mieć możliwość uruchomienia kompilacji za pomocą wiersza poleceń. Podstawowym narzędziem może być prosty program wiersza poleceń, który skompiluje tworzony program, a następnie uruchomi testy. Może to być też złożona kolekcja skryptów kompilacji, które wywołują się nawzajem w odpowiedniej kolejności. Niezależnie od mechanizmu, osoba lub komputer musi mieć możliwość uruchomienia kompilacji, budowania, uruchamiania testów i wdrażania w sposób zautomatyzowany za pomocą wiersza poleceń. Skrypty powinny być traktowane jak kod – muszą być testowane i stale refaktoryzowane, aby były stabilne, uporządkowane i łatwe do zrozumienia.
3. Zgoda całego zespołu
   Ciągła integracja jest praktyką, a nie narzędziem. Wymaga od zespołu programistycznego dyscypliny i zaangażowania. Każdy w zespole musi często wprowadzać swoje zmiany do repozytorium i przyjąć założenie, że najważniejszym zadaniem w trakcie pracy nad projektem jest naprawa wszelkich zmian, które psują aplikację. Jeśli zespół nie będzie przestrzegał tych zasad, poprawne wdrożenie ciągłej integracji może nie być efektywne i nie doprowadzi do satysfakcjonującej poprawy jakości wytwarzania oprogramowania.

Zalety ciągłej integracji w porównaniu z podejściem tradycyjnym

W porównaniu do tradycyjnego podejścia, gdzie zmiany wprowadzane w kodzie źródłowym są kompilowane, testowane i integrowane raz na jakiś czas (raz w tygodniu lub rzadziej), wykorzystanie podejścia ciągłej integracji zapewnia wiele korzyści:

• wcześniejsze wykrywanie problemów kompilacji/integracji, dzięki czemu są naprawiane w sposób ciągły, a nie w ostatniej chwili, tuż zanim główna wersja oprogramowania zostanie przygotowana do wydania, 
• zespół otrzymuje natychmiastową informację zwrotną na temat jakości, funkcjonalności oraz wpływu pisanego kodu na cały system, 
• w ramach tego procesu wykonywane są zautomatyzowane testy. Dzięki nim możliwa jest natychmiastowa kontrola poprawności architektury projektu i jakości kodu – są one wykonywane w ramach procesów kompilacji, budowania i wdrażania zmian (deployment) na różne środowiska, 
• wczesny dostęp do aktualnej wersji oprogramowania (przed oficjalnym wydaniem) do celów testowych lub demonstracyjnych. 

Kluczowe praktyki w procesie ciągłej integracji

Optymalne korzyści z procesu ciągłej integracji można uzyskać, gdy przestrzega się ustalonych w zespole procedur, co wymaga dyscypliny, jak wspomniałem wcześniej. Istnieją też sprawdzone, dobre praktyki, których przestrzeganie znacząco zwiększy sukces we wdrożeniu tego procesu. Składają się na nie poniższe aspekty: 

1. Częsta integracja kodu – najważniejsza praktyka w ciągłej integracji. Kod powinno się integrować przynajmniej kilka razy dziennie. Regularne wysyłanie zmian niesie ze sobą inne korzyści – zmiany są przesyłane w mniejszych pakietach, co zmniejsza prawdopodobieństwo błędu w kompilacji, a także ułatwia poszukiwanie ewentualnych zmian (mniejsza liczba plików do przeszukiwania). To minimalizuje też prawdopodobieństwo wystąpienia konfliktów z kodem innych programistów w przypadku pracy wymagającej zmiany w wielu plikach. W przypadku awarii lokalnej stacji roboczej, która spowodowałyby utratę lokalnych zmian w kodzie – programista nie musi pisać wszystkiego od początku, lecz może zacząć od etapu zmian wprowadzonych w ostatniej integracji.
2. Zarządzanie obszarem roboczym – ważne jest, aby środowisko programistyczne było starannie zarządzane – przede wszystkim zwiększa to produktywność. Deweloperzy powinni zawsze rozpoczynać nową pracę od aktualnej, działającej wersji kodu z głównej gałęzi repozytorium. Powinni móc uruchomić kompilację, testy i być w stanie wdrożyć aplikację w swoim lokalnym środowisku. Uruchamianie aplikacji w środowisku lokalnym powinno wykorzystywać te same zautomatyzowane procesy, co w serwerach ciągłej integracji.
3. Kompleksowy zestaw testów automatycznych – konieczne jest posiadanie zestawu testów automatycznych, aby mieć pewność, że aplikacja działa poprawnie. Najważniejsze z punktu widzenia ciągłej integracji są testy: jednostkowe, integracyjne oraz akceptacyjne. Ich kombinacja powinna zapewnić bardzo wysoki poziom pewności co do tego, że żadna z wprowadzonych zmian nie naruszyła stabilności aplikacji.   
4. Krótki proces budowania i testowania projektu – kompilacja, budowanie i wykonanie testów nie powinny trwać dłużej niż 5-10 minut. Jeśli z jakiegoś powodu proces ten zajmuje zbyt dużo czasu, mogą wystąpić problemy takie jak: 
   • niecierpliwość programistów – mogą oni przestać wykonywać pełną procedurę (na przykład pomijać etap testów), co będzie powodować więcej błędów kompilacji na serwerze ciągłej integracji. 
   • proces ciągłej integracji może trwać tak długo, że do czasu ponownego uruchomienia kompilacji może zostać zintegrowanych wiele zmian – znalezienie tej, która powoduje błędy, może być bardzo czasochłonne. 
   • rzadsza integracja zmian przez programistów z powodu czasochłonności procesu – czekanie kilku godzin na zakończenie kompilacji i testów jest stratą czasu i zasobów. 

Continuous Delivery (CD) 

Ciągła integracja stanowi podstawę solidnego, nowoczesnego wytwarzania oprogramowania. Jest to czynnik umożliwiający wdrożenie jeszcze bardziej zaawansowanych technik. W ciągłej integracji, gdy wszystkie testy zakończą się pomyślnie, zyskujemy pewność, że oprogramowanie działa. Jednakże – w jaki sposób upewnić się, że oprogramowanie będzie działało w środowisku docelowym? Czy będzie współpracowało z innymi aplikacjami? Wreszcie – jak dostarczyć je do użytkowników końcowych? Z pomocą przychodzi podejście ciągłego dostarczania (Continuous Delivery, CD). 

W swej istocie ciągłe dostarczanie polega na minimalizowaniu czasu potrzebnego do wprowadzenia zmian w aplikacji oraz minimalizowaniu ryzyka wystąpienia problemów, które także mogą pojawić się w trakcie tego procesu. Może składać się z kilku faz, takich jak: 

• Odkrywanie – w której analizuje się pomysły, ogólne działanie, funkcjonalności – aby uzyskać szersze zrozumienie przestrzeni problemu i zastanowić się nad potencjalnymi rozwiązaniami. 
• Definiowanie – gdzie formalne kryteria akceptacji i prace projektowe stanowią bazę do dalszych prac rozwojowych. 
• Rozwój – w której produkt jest budowany i testowany funkcjonalnie. 
• Akceptacja – w tej fazie przeprowadzane są testy akceptacyjne wysokiego poziomu i uzyskuje się potwierdzenia od akcjonariuszy. 
• Wdrożenie – zmiana jest wprowadzana na produkcję. 
• Weryfikacja – w ramach której, na podstawie wszelkich danych, analizuje się zmiany, aby upewnić się, że osiągnęły one zamierzony wpływ. 

Każda faza stanowi swego rodzaju listę kontrolną określającą, co jest potrzebne, aby zmiany szły naprzód. Czasem przywołane fazy wysokiego poziomu są podzielone na bardziej szczegółowe. Na przykład, faza rozwoju może mieć wyszczególnione podfazy:  

• architektury technicznej,  
• budowania lub kompilacji,  
• i przeglądu kodu.  

Niezależnie od złożoności poszczególnych faz, zadania związane z pracą nad nimi mogą być podejmowane przez wiele osób o różnych umiejętnościach. Zadania mogą być więc wykonywane równolegle, lecz powinny zachować niezależność. 

Continuous Delivery automatyzuje proces wdrażania oprogramowania na różne środowiska w projekcie. Niektóre z nich można wykorzystać do przeprowadzania różnych testów automatycznych, takich jak:  

• testy integracyjne,  
• testy akceptacyjne,  
• czy też testy niefunkcjonalne, jak na przykład testy wydajnościowe lub penetracyjne.  

Nie należy również zapominać o przeprowadzeniu testów manualnych, które mogą wykryć nowe klasy defektów, których automatyczne testy zwykle nie są w stanie wychwycić. 

Korzyści ciągłego dostarczania (CD) 

Wdrożenie podejścia ciągłego dostarczania niesie wiele korzyści, do których należą:

#1. Oszczędność czasu

W średnich i dużych firmach programy oraz ich infrastruktura są zwykle tworzone i obsługiwane przez wiele oddzielnych zespołów. Każde wdrożenie nowej wersji aplikacji musi być skoordynowane między nimi. Należy ustalić między zespołami datę wprowadzenia nowej zmiany, takiej, która obu zespołom będzie odpowiadała.

Ponadto należy rozpowszechnić informację na temat nowej wersji (na przykład: jakie obszary aplikacji zostaną poddane zmianom, czy jest wymagana nowa konfiguracja, zmiany w integracji itp.). Dodatkowo zespoły muszą udostępnić niezbędne pliki, i tak dalej – procedury mogą się różnić w zależności od stopnia formalności i dojrzałości procesów w organizacji.

Generalnie wszystkie niezbędne działania z pewnością będą trwały kilka godzin, czasem nawet kilka dni. Często procesowi temu towarzyszą również przestoje spowodowane różnymi czynnikami. A ponieważ przestojów należy unikać w godzinach pracy, zdarza się, że wdrożenia odbywają się w nocy lub w weekend. Może to działać demotywująco na zespoły operacyjne odpowiedzialne za wdrożenie, a stąd już tylko krok do popełniania błędów. Wprowadzenie ciągłego wdrażania poprzez automatyzację zadań może zaoszczędzić wiele czasu i skrócić proces z kilku dni do nawet kilku minut oraz oszczędzić nerwów ludziom z zespołów operacyjnych. Dobrze skonfigurowane narzędzie pozwoli na praktycznie bezobsługowe wdrożenie, koordynowane przez jedną lub kilka osób bez potrzeby angażowania całych zespołów.

#2. Krótsze cykle wdrożeń

Firmy wykonujące wydania i wdrożenia manualnie robią to zwykle raz w tygodniu lub nawet rzadziej. Rzadkie wydania doprowadzają do przedłużających się procesów rozwoju, a w ostateczności spowolnienia czasu wprowadzenia produktu na rynek. Jeżeli na przykład oprogramowanie jest aktualizowane raz na kwartał, wprowadzenie nowej, małej funkcji lub istotnej poprawki może niepotrzebnie rozciągnąć się w czasie i spowodować odpływ klientów. Na przykład właściciel sklepu internetowego, w którym pewien etap procesu zakupowego został źle zaprojektowany (co powoduje trudności w zakupach) będzie musiał czekać 3 miesiące, zanim poprawka zostanie wdrożona. W tym czasie sklep może stracić ogromną liczbę klientów, a co za tym idzie – realne pieniądze. Automatyczne wdrażanie może całkowicie wyeliminować ten rodzaj problemów.

#3. Krótszy czas otrzymania informacji zwrotnej (feedback)

Najlepszym sposobem na uzyskanie wartościowych opinii na temat produktu jest wdrożenie go na środowisko produkcyjne, gdzie będzie ono używane przez prawdziwych użytkowników. Dzięki temu można mierzyć ich zaangażowanie w różnych częściach systemu. Użytkownicy często wyrażają również opinie na temat aplikacji i sugerują zmiany.

Niestety, zadanie to nie jest takie proste, gdy tworzy się na przykład narzędzia do użytku wewnętrznego w firmie. Można wtedy poprosić kilka osób, aby przetestowały je na jednym ze środowisk testowych, lecz to rodzi wyzwania. Potrzeba na to wykorzystania ich roboczogodzin, środowisko testowe musi być w pełni przygotowane i skonfigurowane z wszystkimi niezbędnymi danymi, które na końcu i tak zostaną usunięte. Jest to proces czasochłonny i skomplikowany.

Przy ręcznych wydaniach, co często idzie w parze z nieczęstym okresem wdrażania, cykl otrzymania feedbacku jest bardzo powolny, co jest sprzeczne z całą ideą zwinnego procesu wytwarzania oprogramowania. Komunikacja między ludźmi również nie zawsze jest idealna – praca w grupie to zawsze ryzyko nieporozumień. Zdarza się, że pierwsza implementacja funkcjonalności nie spełnia pierwotnych oczekiwań. W takiej sytuacji dyskusje (a więc informacja zwrotna) są nieuniknione. Powolne cykle wdrożeniowe prowadzą zatem do spowolnienia rozwoju aplikacji, frustrując nie tylko zespół, ale także interesariuszy. Użytkownicy docelowi, zdając sobie sprawę z czasu trwania wdrażania kolejnych aktualizacji, mogą nawet nie prosić o poprawki lub nie sugerować różnych udogodnień – prędzej przeniosą się do aplikacji konkurencyjnej, której autorzy lepiej dbają o ten aspekt. Na dłuższą metę powolne cykle wdrożeniowe przekładają się na utratę jakości aplikacji i odpływ użytkowników.

#4. Niezawodność wydań

Manualne wdrażanie zazwyczaj nie odbywa się często. To oznacza, że każde wydanie zawiera dużo zmian, co z kolei zwiększa ryzyko niepowodzenia. Gdy duże aktualizacje są źródłem zbyt wielu problemów, inżynierowie i managerowie szukają sposobów na poprawę stabilności kolejnego wydania, niejednokrotnie poprzez tworzenie kolejnych procedur i list kontrolnych.

Tworzy to błędne koło, ponieważ więcej procesów wymaga włożenia jeszcze większego wysiłku w kolejne wydania, a co za tym idzie – więcej czasu. Sprawia to, że cykle wydawania oprogramowania są jeszcze dłuższe, co z kolei rodzi potrzebę zmiany procedur, aby… ten czas skrócić. Sposobem na wyjście z tego błędnego koła jest automatyzacja etapów lub nawet całego procesu wydawania. Gdy więc proces ten stanie się niezawodny i szybszy, nic nie będzie stało na przeszkodzie, aby zwiększyć liczbę wydań, które jednorazowo będą zawierały mniejsze zmiany. Czas zaoszczędzony dzięki automatyzacji uwalnia zasoby, które można wykorzystać, aby jeszcze bardziej usprawnić zautomatyzowany proces wydawania.

#5. Mniejsze pakiety ułatwiają znalezienie źródła problemu

Kiedy wdrożenie spowoduje błąd w oprogramowaniu (a zawierało ono tylko jedną lub dwie nowe funkcje lub same poprawki błędów), dość łatwo można ustalić, która ze zmian stanowi źródło błędu. Duże pakiety, gdzie na jedno wydanie przypada wiele zmian w różnych częściach aplikacji, utrudniają znalezienie źródła problemów i wydłużają czas poszukiwań oraz naprawy. Ta, ze względu na wiele zmian zawartych w wydaniu (poziom skomplikowania pakietu przez różne zależności) trwa dłużej.

#6. Swoboda architektoniczna

Obecne trendy w inżynierii oprogramowania odchodzą od monolitycznych aplikacji na rzecz systemów rozproszonych, składających się z małych komponentów (mikroserwisów). Mniejsze aplikacje lub usługi są łatwiejsze w utrzymaniu, a wymagania dotyczące skalowalności wymuszają, aby działały na różnych urządzeniach, często na wielu jednocześnie. Ręczne wydawanie poszczególnych mikroserwisów, w przypadku gdy są ich setki, wydaje się być niemożliwe do przeprowadzenia w sposób bezawaryjny w satysfakcjonującym czasie. Automatyzacja wdrożeń pozwala konfigurować wydawanie aplikacji w sposób optymalny, tak, aby zapewnić niezawodność działania oprogramowania.

#7. Zaawansowane techniki zapewnienia jakości

Wyobraźmy sobie wyszukiwarkę wycieczek, której właściciel chce ulepszyć algorytm wyszukiwania. Można wdrożyć zarówno starą, jak i nową wersję silnika jednocześnie i uruchamiać zapytania na obu. Definiując przy tym odpowiednie metryki, można w prosty sposób oceniać działanie nowego algorytmu. Dzięki nim, w przypadku, gdy stary silnik będzie zwracał na przykład lepsze wyniki na niektóre zapytania – można wykorzystać te dane w celu ulepszenia nowego. Automatyczne wdrażanie nie jest samo w sobie gwarantem zapewnienia jakości, ale stanowi bazę do zastosowania zaawansowanych technik w celu jego osiągnięcia.

Automatyzacja vs. manualne wdrażanie

Główne praktyki stosowane w obu podejściach (Continuous Integration i Continuous Deployment) są jednakowe. Różnicę stanowi etap zastosowania automatyzacji wdrożenia do środowiska produkcyjnego, co obrazuje poniższy rysunek.  

Jak już wspomniałem, celem podejścia Continuous Delivery jest automatyzacja każdego etapu cyklu wdrażania do ostatniego środowiska przedprodukcyjnego, dzięki czemu zmiany można wprowadzić na docelowe środowisko w dowolnym momencie. W Continuous Deployment zmiany są dostarczane bezpośrednio na środowisko produkcyjne. Różnica to sposób wdrażania – automatyczny lub manualny.

Praktyka ciągłego wdrażania jest skomplikowana, procesy wykorzystywane w ciągłej integracji nie są w stanie pokryć wszystkich niezbędnych etapów koniecznych do jej poprawnego zaimplementowania w projekcie. Niezbędne jest użycie dodatkowych narzędzi, pozwalających na testowanie i kontrolowanie różnych części systemu (na przykład wydajności, gotowości do działania, weryfikacja poprawności integracji itp.).

Podsumowanie

Dziś bez praktyk CI/CD trudno wyobrazić sobie jakikolwiek nowoczesny projekt IT. Automatyzacja procesów ciągłej integracji i ciągłego dostarczania pozwala nam skrócić czas wdrażania zmian, wydawać oprogramowanie częściej i w sposób niezawodny. Dodatkowo szybciej uzyskujemy feedback od użytkowników. Już teraz zachęcam was do lektury drugiej części artykułu. Przyjrzę się w nim bliżej procesowi dostarczania oprogramowania z wykorzystaniem CI/CD i omówię konkretne praktyki testerskie wraz z przeglądem najlepszych narzędzi CI/CD.

PRZEJDŹ DO:

1. 1. Czym jest usługa Azure Active Directory?
2. 2. Czym jest aplikacja multi-tenant?
3. 3. Rozpocznij pracę z usługą Azure AD
4. 4. Rejestrowanie aplikacji multi-tenant
5. 5. Logowanie do aplikacji jako użytkownik zewnętrzny
6. 6. Aplikacja multi-tenant wywołująca wewnętrzne API
7. 7. Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji
8. 8. Usługa Azure AD od Microsoft – podsumowanie

Zarządzanie dostępami do aplikacji jest zagadnieniem poruszanym w przypadku niemal każdego systemu. Dbając o odpowiednie uwierzytelnianie, nie tylko ograniczamy możliwości pozyskania czy modyfikowania wrażliwych danych, ale mamy również większą elastyczność w przypadku tzw. User Experience, poprzez definiowanie ról czy właściwości związanych z danym użytkownikiem. 

Czym jest usługa Azure Active Directory? 

Azure Active Directory (AAD) jest serwisem chmurowym firmy Microsoft pozwalającym na zarządzanie dostępami i tożsamościami. Korzystając z tego rozwiązania, możemy również rejestrować nasze aplikacje i określać zasady dostępności. Przy czym rozważamy tutaj zarówno dostępy użytkowników, jak i innych aplikacji. Do zarejestrowanego rozwiązania w danej dzierżawie (z ang. tenant ) dostęp mogą mieć wszystkie obiekty (użytkownicy, aplikacje) ją współdzielące. AAD pozwala również na „udostępnianie” aplikacji innym najemcom, dzięki czemu nie musimy martwić się o zarządzanie użytkownikami zewnętrznymi naszej aplikacji. Tak skonfigurowane rozwiązanie nazywamy multi-tenantowym. 

Czym jest aplikacja multi-tenant? 

Aplikacja typu multi-tenant pozwala obsługiwać wielu dzierżawców poprzez jedną instancję. Przy tego typu rozwiązaniach istotne jest, aby klient nie miał dostępu do danych należących do innych najemców. Jest to najczęściej rozwiązywane poprzez logikę biznesową lub rozdzielenie baz danych tak, aby każdy klient miał własną. 

Aplikacja wielodostępowa zarejestrowana w Azure Active Directory pozwala przenieść zarządzanie użytkownikami i określanie poziomu dostępu do rozwiązania na barki administratora danego dzierżawcy. Zmniejsza to koszty związane z utrzymywaniem użytkowników po stronie dostawcy usługi.  

Należy jednak pamiętać, że kwestia dostępu do poszczególnych elementów aplikacji jest dalej rozwiązywana przez programistów poprzez definiowanie odpowiednich polityk w kodzie. 

Rozpocznij pracę z usługą Azure AD

Firma Microsoft udostępnia administratorom materiały niezbędne do zarządzania usługami w Azure Portalu.  Dokumentacja zawiera też odpowiedzi na często zadawane pytania. Wszelkie informacje są dostępne na stronie Microsoft Azure Active Directory,  gdzie można się dowiedzieć wszystkiego na temat zarządzania tożsamością i dostępami w chmurze. Jeżeli jeszcze nie korzystasz z usług Microsoft Azure, warto zacząć właśnie w tym miejscu.   

Rejestrowanie aplikacji multi-tenant 

Podczas rejestracji nowej aplikacji jesteśmy zobligowani do wybrania, jakiego rodzaju konta chcemy wspierać. Wybierając opcję zaznaczoną poniżej, dajemy możliwość dostępu innym dzierżawcom. Jeżeli mamy wątpliwości, którą opcję wybrać, pod sekcją znajduje się link z krótkim opisem, na co zezwala każda z nich. 

Zarejestrowanie obiektu aplikacji powoduje utworzenie aplikacji biznesowej, a dokładniej jednostki usługi (z ang. Service Principal). To właśnie do jednostki usługi są podpinane dostępy użytkownika do aplikacji. Dokładnie ten sam mechanizm jest wykorzystywany w przypadku zewnętrznych klientów. 

Logowanie do aplikacji jako użytkownik zewnętrzny  

Przy pierwszej próbie logowania do aplikacji jesteśmy poproszeni o udzielenie zgody dla danej aplikacji. W zależności od ustawień dzierżawcy będziemy mogli sami jej udzielić lub będzie ona wymagała zatwierdzenia przez administratora.  

Warto nadmienić, że administrator udziela zgody dla wszystkich użytkowników, przez co tylko pierwsze logowanie do aplikacji jakimkolwiek użytkownikiem będzie wywoływać prośbę o udzielenie uprawnień.  

Przy samoakceptacji (self-consent) będzie ona wywoływana indywidualnie dla każdego użytkownika przy pierwszej próbie logowania. 

Tu u niektórych z was mogą pojawić się obawy: czy zezwalając na dostęp do danych użytkownika, przydzielamy go dostawcy, u którego aplikacja została zarejestrowana? Spokojnie, nie do końca tak jest. Podobnie jak w przypadku dzierżawcy pierwotnego tworzona jest jednostka usługi jako aplikacja biznesowa, i to w zależności od ustawionych dostępów względem niej nasze rozwiązanie pozyskuje informacje o aktualnie zalogowanym użytkowniku. 

Gdy DevOps lub inżynier rejestruje aplikację i chce, aby logowano się do niej przez Microsoft, docelowa aplikacja z docelowymi dostępami używanymi przy logowaniu utworzy się automatycznie podczas rejestracji. Nie ma wówczas potrzeby, by użytkownicy wyrażali zgodę dla aplikacji w tej dzierżawie. 

Przeczytaj także: Czym jest Azure IoT? Jakie daje możliwości? Jaki jest koszt usług i gdzie zdobyć niezbędną wiedzę?

Aplikacja multi-tenant wywołująca wewnętrzne API 

Często, zwłaszcza w przypadku mikroserwisów, zdarza się, że nasza aplikacja komunikuje się z inną poprzez jej API. Kiedy dzieje się to w modelu serwis do serwisu, wystarczy, że zagwarantujemy dostęp w dzierżawie dostawcy. Sytuacja komplikuje się, kiedy chcemy aby aplikacja komunikowała się poprzez API w imieniu zalogowanego użytkownika. 

Dla rozwiązania multi-tenantowego musimy zagwarantować, że API ma swojego reprezentanta u najemcy w postaci jednostki usługi, co wymusza publiczną dostępność szablonu API. Wszystko za sprawą mechanizmu weryfikacji dostępów, który tak naprawdę ma miejsce ramach tenanta, tj. dzierżawcy użytkownika. Dlatego należy dokładnie przemyśleć model komunikacji między aplikacjami. 

Istotne jest, aby w zarejestrowanym obiekcie aplikacji API zdefiniować aplikację webową jako jedną ze zautoryzowanych – dzięki temu klient będzie mógł zezwolić na dostęp do API, a tym samym jednostka usługi zostanie zarejestrowana w jego dzierżawie. 

Zarządzanie tożsamościami – ograniczanie dostępu do aplikacji 

Jak już wspomniałem, w momencie pojawienia się aplikacji biznesowej u danego dzierżawcy każdy użytkownik ma do niej dostęp. Możemy jednak to ograniczyć.  

Jeżeli chcemy, aby tylko określeni użytkownicy czy też grupa użytkowników miała dostęp, musimy ustawić naszą jednostkę usługi w taki sposób, żeby wymagała przypisania. 

Wtedy, aby użytkownik bądź grupa miała dostęp, aplikacja musi widnieć w przypisanych do użytkownika lub grupy. 

Innym sposobem na modyfikowanie dostępów do aplikacji jest dostęp warunkowy, który pozwala wymuszać pewne zachowania bądź blokować dostęp w zależności od ustawionych scenariuszy. Opcja ta jest jednak dostępna w wersji Premium Azure Active Directory. Informacje o planach cenowych i dostępnych usługach znajdziesz na stronie Microsoft Azure. 

Usługa Azure AD od Microsoft – podsumowanie 

Aplikacja wielodostępowa pozwala zredukować koszty poprzez współdzielenie jednej instancji przez wielu klientów. Zastosowanie Azure Active Directory do zarejestrowania takiego rozwiązania ogranicza dodatkowo koszty związane z utrzymywaniem użytkowników, gdyż niejako korzystamy z tych należących do najemcy. To od administratora dzierżawcy, który chce mieć dostęp, zależy, komu i w jakim zakresie chce go przydzielić. 

Niestety ograniczamy się wtedy tylko do klientów Microsoft, przez co możemy być mniej konkurencyjni. Jeżeli chcielibyśmy mieć rozwiązanie dostępne dla klientów niezależnie od dostawcy poświadczeń którego używają, ciekawą opcją jest Azure Active Directory B2C z Single Sign-On.  

Przejdź do:

1. 1. Serwer TCP na platformie Azure – ale po co?
2. 2. Komunikacja po TCP – jakie są opcje?
3. 3. Konfigurujemy Azure Container Instances
4. 4. Testy
5. 5. Problem zmiany adresu IP po przeładowaniu…
6. 6. Container Apps z TCP jako kolejny etap ewolucji
7. 7. Podsumowanie

Serwer TCP (Transmission Control Protocol) na platformie Azure – ale po co?

W naszym projekcie, pracując nad rozwiązaniem pozwalającym systemom POS (ang. point of sale) na obsługiwanie płatności, musieliśmy zintegrować je z systemem obsługującym komunikację z terminalami płatniczymi. Wiązało się to z posiadaniem fizycznego urządzenia, w tym przypadku terminala, do celów testowych. Pracując w trybie zdalnym, z zespołem rozproszonym po kilku miastach w Polsce, niemożliwe było współdzielenie jednego takiego urządzenia. Zdecydowaliśmy, że do testów i na etapie pracy nad kodem będziemy używać stuba (czyt. staba) – aplikacji, która będzie zwracała predefiniowane odpowiedzi).

Lista wymagań wobec naszego zamiennika była bardzo krótka:

• Komunikacja musi odbywać się po TCP
• Żądanie musi zwracać oczekiwaną odpowiedź
• Serwer musi być w stanie obsłużyć równoległe żądania

Gotowe rozwiązanie w .NET było przygotowane tak, aby można je było uruchomić lokalnie na Dockerze.

Po upewnieniu się, że stub spełnia nasze oczekiwania i bez ryzyka może zastąpić rzeczywistą integrację, postanowiliśmy użyć go do testów E2E (ang. end to end), które są elementem pipeline’u DevOps. W tym celu trzeba było aplikację umieścić gdzieś na platformie Azure, z której korzystaliśmy.

Azure Serverless workflow orchestration

Automatyzacja procesów biznesowych jest naturalną transformacją. Poznaj rozwiązanie oparte na Azure Durable Function, które pozwoli ci przejść gładko przez ten proces.

Przeczytaj artykuł

Komunikacja po TCP – jakie są opcje?

Największą trudnością w znalezieniu odpowiedniego zasobu okazał się wymagany rodzaj protokołu, niewspierany przez serwisy bazujące głównie na komunikacji po HTTP. Jakie mieliśmy opcje?

1. Maszyna wirtualna – można postawić maszynę wirtualną i na niej uruchomić aplikację, ale wymagałoby to dodatkowej konfiguracji dostępu do maszyny oraz utrudniało monitorowanie samej aplikacji.
2. Azure Kubernetes Services – kolejną opcją jest AKS, który daje sporą elastyczność w kwestii automatyzacji zarządzania infrastrukturą, jednak na potrzeby prostego stuba jest to nadmiarowe rozwiązanie (wymagałoby odpowiedniej konfiguracji, a i tak nie wykorzystalibyśmy wielu opcji, jakie oferuje).
3. Azure Container Instances – przeglądając portfolio usług Azure, natrafiłem na informację, że protokół TCP jest dostępny dla Azure Container Instances. Wyglądało to na idealne rozwiązanie, które można byłoby w prosty sposób uruchomić. Dodatkowym atutem była łatwość monitorowania i fakt, że lokalnie stub działał na kontenerze dockerowym.

Obejrzyj także wideo z serii BiteIT:

Konfigurujemy Azure Container Instances

Na potrzeby tego artykułu przygotowałem uproszczoną wersję docelowego rozwiązania. Działa ono jak echo, zwracając otrzymane żądanie do nadawcy, i to właśnie tę aplikację będę starał się udostępnić poprzez Azure Container Instances.

Poniżej fragment kodu serwera odpowiedzialny za obsługę żądań.

private void Echo(IAsyncResult result) 

{ 

var listener = (TcpListener)result.AsynState!; 
	 

if (!_active) 

     { 

          return 

 
     } 
 
     var client = listener.EndAcceptTcpClient(result); 

     _logger.LogInformation(“Client connected from: {ip}”, 
     client.Client.RemoteEndPoint); 
     _allDone.Set(); 

     Task.Run(async () => 

     { 

          using (var stream = client.GetStream()) 

          var buffer = _array.Pool.Rent(256); 

         Array.Pool.Return(await stream.Echo(buffer), clearArray: true); 
     } 

     client. Close(); 

     }); 

 
} 

Jako osoby zajmujące się wytwarzaniem oprogramowania powinniśmy dążyć do automatyzowania powtarzalnych czynności, dlatego całą konfigurację zasobów umieściłem w plikach Bicep. Takie rozwiązanie pozwala używać raz zdefiniowanej konfiguracji wielokrotnie podczas wdrażania jej na platformie Azure.

Podstawowa konfiguracja Azure Container Instances wymaga zdefiniowania:

1. Zasobów, z jakich może korzystać skonteneryzowana aplikacja.

resources: { 

     requests: {  

          cpu: 1  

          memoryInGB: 1  
     } 
} 

2. Lokalizacji obrazu, na podstawie którego będzie budowany kontener, wraz ze zdefiniowanymi portami zewnętrznymi.

image: '${containerRegistryName}/tcp-server:latest’ 

ports: [  

{ 

port: port 

protocol 'TCP' 

} 

] 

3. Dostępu do rejestru, na którym znajduje się obraz.

imageRegistryCredentials: [ 

{ 

server: containerRegistryName 

username: registryUserName 

password: registryPassword 

} 

] 

4. Konfiguracji adresu IP.

IpAddress: { 

type: ‘Public’ 

ports: [  

    {  

port: port 

protocol: ‘TCP’  

    } 

          ] 

} 

Najważniejsza rzecz, o której trzeba pamiętać, to aby wewnętrzny port odpowiadał portowi zewnętrznemu, inaczej komunikacja po TCP nie będzie działać.

Poniżej cały plik Bicep dla konfiguracji Azure Container Instances:

Czas na testy

Po wdrożeniu na środowisko Azure mogliśmy upewnić się, że aplikacja działa i nasłuchuje na żądania.

Do celów testowych napisałem prostego klienta TCP jako test w xUnit. 

[Fact]  

public void MakeSingleCall() 

{ 

var buffer = _arrayPool.Rent(256); 

try 

{ 

using var client = GetClient(); 

using var stream = client.GetStream(); 

stream.Write(Encoding.UTF8.GetBytes(TestMessage)); 

 

          while (!stream.DataAvailable) 

          { 

               Thread.Sleep(1000); 

          } 

 

          StringBuilder sb = new(); 

          while (Stream.DataAvailable) 

         { 

         var readBytes = stream. Read(buffer); 

         Sb.Append(Encoding.UTF8.GetString(buffer[...readBytes])); 

         } 

         Assert.Equal(TestMessage, sb.ToString()); 

    } 

    finally   

    { 

           _arrayPoolReturn(buffer); 

    } 


} 

Do nawiązywania połączenia służy prywatna metoda GetClient.

private static TcpClient GetClient() 

{  

var socketException = new SocketException(); 

ushort attempts = 0; 

while (attempts < RetryAttempt) 

{ 

try  

{ 

TcpClient client = new (HostName, Port); 

return client; 

          } 

          catch (socketException  ex  

          { 

          socketException = ex; 

                attempts++; 

                Thread.Sleap(TimeSpan.FromSeconds(Math.Pow(2,  attempts))); 

                continue;   

 

          } 

     } 

     throw SocketException; 

} 

Jak widać, test zakończył się sukcesem, a w logach kontenera mamy informację o nawiązaniu połączenia.

Problem zmiany adresu IP po przeładowaniu…

Mógłbym w tym momencie przejść do podsumowania, jako że mamy działającą aplikację w Azure pozwalającą na komunikację po TCP. Niestety w dokumentacji Azure Container Instances jest informacja, że adres IP może się zmienić w przypadku przeładowania zasobu, co z kolei jest wymagane, aby pobrać najnowszą wersję obrazu aplikacji. Ryzyko zmiany adresu stuba sprawiało, że testy E2E nie mogły być częścią pipeline’u, ponieważ istniała możliwość, że będą fałszywie negatywne.

…i rozwiązanie tego problemu

Żeby nie wymuszać na kliencie serwera TCP pilnowania i zmieniania adresu IP po przeładowaniu zasobu, należy ten problem „schować” i obsłużyć wewnętrznie poprzez infrastrukturę. Na szczęście Azure zapewnia rozwiązania pozwalające to zrobić.

Docelowa architektura prezentuje się następująco:

I składa się z:

• Publicznego IP
• Load balancera
• Sieci wirtualnej (VNet)
• Container registry
• Container instances

Konfigurację w plikach Bicep podzieliłem na moduły per typ zasobu oraz jeden plik główny jako punkt startowy do postawienia wszystkich niezbędnych elementów.

Aby zmniejszyć liczbę adresów IP, jakie mogą zostać przydzielone do kontenera, zdefiniowana podsieć ma tylko 8 adresów, z czego 5 jest na wewnętrzne potrzeby Azure, co zostawia nas z 3 dostępnymi adresami.

resource virtualNetwork ‘Microsoft.Network/virtualNetworks@2022-05-01'  existing = { 

name:shared-vnet' 

} 

 

resource subnet ‘Microsoft.Network/virtualNetworks/subnets@2022-05-01' = { 

   name’tcp-server-sub' 

   parent: virtualNetwork 

   properties: { 

 	   	addressPrefix: ‘10.1.2.0/29 

delegations: [ 

   { 

name: ACIDelegationService’  

properties: {  

   serviceName: ‘Microsoft.ContainerInstance/containerGroups’  

type: ‘Microsoft.Network/virtualNetworks/subnets/delegations’ 

   } 

] 

privateEndpointNetworkPolicies: ‘Disabled’ 

privateLinkServiceNetworkPolicies: ‘Enabled’  

   } 

   	} 

 
output subnetId string = subnet.id 

Konfigurując load balancer, należy ustawić pulę dla dostępu do wewnętrznego zasobu.

backendAddressPools: [  

     {  

     name: ‘tcp-server-be' 

     properties: {  

     loadBalancerBackendAddresses: [  

     { 

     name: ‘tcp-server’ 

         properties: { 

         ipAddress: backendPrivateIPAddress 

  	     virtualNetwork: { 

         id:virtualNetworkId 

         } 

         } 

      } 

   ] 

 } 

 } 

] 

Gdzie „ipAddress” jest adresem dla Container Instances wewnątrz podsieci.

Dodatkowo zdefiniowałem sprawdzanie żywotności kontenera poprzez próbkowanie.

probes: [ 

{ 

name: ‘tcp-server-hc' 

properties: {  

   protocol: ‘Tcp’  

   port: tcpPort 

   intervalInSeconds: 5  

   numberOfProbes: 1  

          } 

     } 

]  

Wszystkie te ustawienia są niezbędne do ustalenia reguł przekierowywania ruchu z publicznego adresu IP na wewnętrzne.

loadBalancingRules: [ 

   { 

name:  ‘tcp-server-lb-rule' 

   properties: { 

frontendPort: tcpPort 

   protocol: ‘Tcp’ 

   backendPort: tcpPort 

   disableOutboundSnat: true 

   frontendIPConfiguration: { 

id: resourceId( ‘Microsoft.Network/loadBalancers/frontendIPConfigurations’, ‘tcp-server-lb', ‘tcp-server-fe' ) 

} 

backendAddressPool: { 

id: resourceId( ‘Microsoft.Network/loadBalancers/backendAddressPools’, ‘tcp-server-lb', ‘tcp-server-be' ) 

} 

probe: { 

   	id: resourceId(‘ Microsoft.Network/loadBalancers/probes’, ‘tcp-server-lb', ‘tcp-server-hc' ) 

     } 

    } 

 } 

] 

Jedyna zmiana w konfiguracji Container Instances dotyczy ustawień adresu IP, który teraz jest prywatny i przydzielony z podsieci.

ipAddress: {  

type: ‘Private’  

ports: [ 

   { 

port: port  

protocol : ‘TCP’ 

        } 

     ] 

} 

subnetIds:[ 

          {  

id: subnetId 

} 

]     

Taka konfiguracja dalej wymaga pilnowania adresu IP po restarcie kontenera i upewniania się, że jest taki sam jak ustawiony na load balancerze, ale staje się to problemem wewnętrznym.

Container Apps z TCP jako kolejny etap ewolucji

Pod koniec 2022 roku Azure dał możliwość skonfigurowania Container Apps dla komunikacji po TCP w wersji zapoznawczej.

Ponieważ Azure Container Apps ułatwia skalowanie oraz pozwala zautomatyzować podnoszenie wersji aplikacji po pojawieniu się nowego obrazu w rejestrze, postanowiłem się temu przyjrzeć.

Zgodnie z dokumentacją należy umieścić środowisko zarządzane wewnątrz podsieci. Istotne jest skonfigurowanie poprawnego zakresu CIDR – minimum /23.

resource virtualNetwork ‘Microsoft.Network/virtualNetworks@2055-05-01' existing = { 

name: ‘shared-vnet’ 

     } 

     resource subnet ‘Microsoft.Network/virtualNetworks/subnets@2022-05-01 = { 

         name: ‘tcp-server-ca-sub' 

         parent: virtualNetwork 

         properties: {  

          addressPrefix: ‘10.1.0.0/23’ 

           } 

      } 

output subnetId string = subnet.id  

Container Apps wymagają zdefiniowanego środowiska zarządzanego. Jak już wspomniałem, należy je umieścić wewnątrz podsieci, pamiętając o ustawieniu właściwości „internal” na false, aby aplikacja była dostępna z zewnątrz.

vnetConfiguration: { 

infrastructureSubnetId: subnetId 

internal: false 

} 

Sama konfiguracja Container Apps wymaga zdefiniowania:

1. Szablonu dla rewizji, którą chcemy uruchomić.

template: {  

containers: [  

{ 

          env: [ 

          { 

          name: ‘TcpServer_Port’ 

value: ‘${port}’ 

      } 

    ] 

    image: ‘${containerRegistryName}/tcp-server:latest’ 

    name: ‘tcp-server’ 

    probes: [ 

     { 

     periodseconds: 10 

     successThreshold: 1  

          tcpSocket: { 

         port: port 

     } 

     type: ‘Liveness’ 

    } 

] 

resources: { 

cpu: json(‘0.25’) 

memory: ‘0.5Gi’ 

} 
} 

] 

revisionSuffix: guid(‘tcp-server') 

}   

Dodałem, oczywiście, próbkowanie żywotności kontenera.

2. Punktu wejścia dla komunikacji zewnętrznej.

ingress: { 

allowInsecure: false 

     exposedPort: port 

     external: true 

     targetPort: port 

     transport: ‘tcp’ 

} 

3. Dostępu do Azure Container Registry, na którym znajduje się obraz aplikacji.

registries: [  

   {  

server: ascoding.azurecr.io’ 

username: registryUsername 

passwordSecretRef:  registryPasswordSecretId 

   } 

] 

secrets: [  

   { 

name: registryPasswordSecretId 

value: registryPassword 

  } 

]  

Przydatnym dodatkiem jest możliwość przechowywania informacji wrażliwych wewnątrz zasobu, bez konieczności podłączania zewnętrznego Key Vaulta.

Po zakończonym wdrożeniu okazało się, że rozwiązanie Azure jest bardzo podobne do mojego.

I również działa.

Podsumowanie

Azure Container Instances pozwala na szybkie uruchamianie skonteneryzowanych aplikacji, które umożliwia zewnętrzną komunikację po TCP. Niestety, nie jest to rozwiązanie pozbawione wad (przypomnijmy: zmieniające się IP, brak skalowania), które utrudniają skonfigurowanie środowiska i w przypadku prostych aplikacji mogą być powodem do jego odrzucenia. 

Na szczęście Azure wyszedł naprzeciw potrzebom użytkowników z nową usługą, jaką jest Container Apps, która jest relatywnie prosta do skonfigurowania i pozbawiona problemów, na jakie trafimy korzystając z Container Instances. Warto mieć to rozwiązanie na uwadze i śledzić nowe możliwości, jakie zespół developerów chmury Microsoft Azure będzie do niego dodawał.  

Przeczytaj także: Big Data w chmurze Azure

Spis treści

1. 1. Od programisty do DevOpsa
2. 2. Błądzenie w chmurze – czyli od czego zacząć?
3. 3. Narzędzia DevOps
4. 4. Zasoby – platforma Microsoft Learn
5. 5. A jak poznać proces DevOps?
6. 6. CI/CD (Continuous Integration / Continuous Delivery)
7. 7. IaaC (Infrastructure-as-a-Code)
8. 8. Podsumowanie

Od programisty do DevOpsa

W przypadku programowania wybierasz język, który wydaje się najbardziej interesujący i dostosowany do tego, co chcesz robić, albo… prosty w nauce. Kiedy poznasz podstawy składni, jedyne, co cię ogranicza, to twoja własna wyobraźnia. Na początku zastanawiasz się: „Co by tu napisać?”. Może kalkulator, może kółko i krzyżyk albo coś bardziej zaawansowanego z obsługą bazy danych lub zewnętrznych bibliotek?

Im więcej zrealizowanych projektów, tym więcej napotkanych wyzwań, a twoje umiejętności rosną z każdą kolejną linią kodu. Czujesz się biegle w składni, korzystasz już z zewnętrznych bibliotek, a na rozmowach o pracę możesz pochwalić się owocem swojej dotychczasowej nauki w postaci działających programów. Na kolejnym etapie zaczynasz obracać się w bardziej zaawansowanych projektach, które wymagają zastosowania i znajomości różnych podejść. Pojawiają się procesy, większy nacisk kładziony jest na jakość kodu, jego elastyczność, a z tym wiąże się nauka wzorców.

Błądzenie w chmurze – czyli od czego zacząć?

A jak to wygląda w przypadku chmury? Zarówno przy programowaniu, jak i tutaj możemy wyróżnić dwa główne etapy nauki. Pierwszym z nich jest nauka narzędzia (Azure), a drugim – wzorców i procesów. Jest to oczywiście uproszczenie, bo zarówno narzędzia, jak i wzorce można jeszcze precyzyjniej skategoryzować, ale wszystko to zależy od poszczególnych projektów i ich wymagań.

Usługa Azure DevOps – narzędzia

Zaczęliśmy od narzędzi i tutaj wybór może paść na dowolną chmurę: Microsoft Azure, AWS, GCP – to najwięksi obecnie dostawcy na rynku. To, którą chmurę wybierzesz, nie ma wielkiego znaczenia, gdyż oferują one podobne usługi i w większości przypadków rozwiązanie jednej firmy ma swój odpowiednik w rozwiązaniu oferowanym przez inną.

Od czego rozpocząć? Czyli „pakiet startowy” Azure DevOps

To, od czego możesz zacząć i co pozwoli ci rozwinąć skrzydła, to poznanie samej chmury i tego, co oferuje. Przykładami takich zasobów, które warto poznać w ramach Azure, mogą być np.:

Nie bez powodu podałem akurat te. Chciałem w ten sposób pokazać, że zasoby, poza realizowanymi przez nie odpowiedzialnościami, są również w pewien sposób od siebie zależne i ze sobą powiązane.

Na powyższym przykładzie możemy to zobrazować tak, że Virtual Machine należy do podsieci zdefiniowanej w Virtual Network, a dostęp do niej zdefiniowany jest poprzez skonfigurowany Network Security Group.

Zasoby Azure DevOps – usługa Microsoft Learn 

Kiedy poznasz poszczególne zasoby oferowane przez chmurę, będziesz już mieć świadomość tego, w jakich przypadkach możesz je wykorzystać i jak się ze sobą komunikują. A z pomocą w nauce przyjdzie ci platforma Microsoft Learn. Ma ona trzy ważne zalety, o których chciałbym wspomnieć.

1. Wybór ścieżki 

Po pierwsze, pozwala na wybór ścieżki, w której chcesz się kształcić. Może to być jedna z wielu, np.:

W zależności od tego, którą ścieżkę obierzesz, będziesz mieć dostęp do modułów, które zapoznają cię z poszczególnymi zagadnieniami potrzebnymi w pracy na danym stanowisku. Zaletą takiego rozwiązania jest to, że nie musisz się zastanawiać, na czym spośród wielu możliwości się skupić, i możesz od razu zająć się zagadnieniami, które są ze sobą powiązane. Poznasz w ten sposób również charakter pracy w danej roli, dowiesz, czy jest to praca bardziej administracyjna, koncepcyjna lub developerska.

2. Certyfikacja 

Po drugie – certyfikacja. Microsoft w zakresie wszystkich swoich rozwiązań oferuje ścieżkę certyfikacji. Nie jest ona darmowa, nie jest też prosta, a w wielu przypadkach wręcz można na niej pobłądzić. Jest to jednak najbardziej rozpoznawalne i uznawane potwierdzenie umiejętności na rynku pracy w zakresie technologii oferowanych przez Microsoft.

Jeżeli zależy ci na udokumentowaniu swojej wiedzy i umiejętności, możesz skorzystać z modułów, które przygotują cię do wybranego przez siebie certyfikatu, co na pewno ułatwi szukanie pracodawcy. Warto jest się dobrze zapoznać z dostępnymi ścieżkami certyfikacji i dowiedzieć, jaka wiedza jest sprawdzana na poszczególnych egzaminach. Na każdą ze ścieżek składa się kilka egzaminów o różnym zakresie i podziale tematycznym. W przypadku typowego DevOpsa w chmurze Azure (DevOps Engineer) polecam skupić się na AZ-900 Microsoft Azure Fundamentals. Certyfikat ten zapozna cię z koncepcją chmury oraz dostępnymi zasobami w Azure na podstawowym poziomie. Dalej możesz już obrać jedną z bardziej zaawansowanych ścieżek w zależności od tego, co cię interesuje. Wszystkie certyfikaty wraz z opisami dostępne są na oficjalnej stronie Microsoftu.

3. Ćwiczenie umiejętności  

Trzecią zaletą tej platformy jest jej funkcjonalność. Wszystkie moduły są pogrupowane w poszczególne kategorie ze względu na technologię lub certyfikację, którą wybierzesz. Dodatkowo twoja aktywność jest na bieżąco śledzona i zapisywana, dzięki czemu wiesz, które materiały już przerobiłeś. Bardzo często na końcu każdego modułu lub ważnego zagadnienia umieszczane są linki do dodatkowych zasobów, które pozwolą ci pogłębić wiedzę odnośnie opisywanych zagadnień. Nie są one wymagane, ale na pewno pozwalają zdobyć bardziej szczegółowe pojęcie o zasobach i poznać możliwości, jakie oferują.

Oprócz lekcji w formie tekstowej pojawiają się również laboratoria. Są one zintegrowane ze stroną i można w prosty sposób poćwiczyć tworzenie i konfigurowanie zasobów tak, jak byśmy to robili w codziennej pracy.

A jak poznać proces DevOps?

Chmurę, na przykładzie Azure, można zatem poznać w dość przystępnej formie, którą opisałem powyżej. Inaczej sytuacja wygląda natomiast z samym procesem DevOps. Niestety w tym przypadku, chyba w każdej firmie trafimy na odstępstwa od modelowych procesów i trudno szukać miejsca, gdzie wszystko byłoby idealne. Warto jest zatem mieć ogólne pojęcie o tym, jak powinny przebiegać poszczególne procesy, jakie dają nam realne korzyści oraz kiedy powinniśmy je stosować.

Reszta zależy już od wielu składowych, takich jak: specyfika projektu, oczekiwania klienta, budżet, zaangażowanie i wiedza zespołów ze sobą współpracujących, a nawet narzędzia, których używają.

Jak wdrażać projekty? Pomocne wzorce

Z pomocą przyjdą nam wzorce, czyli podobnie jak w programowaniu, szablony, które stosujemy i które w czysty, zorganizowany sposób pozwalają nam budować strukturę projektu, który będzie elastyczny i reużywalny. O jakich zatem wzorcach / praktykach mowa?

1. CI/CD
2. IaaC

Wymieniłem właśnie te, ponieważ uważam je za najważniejsze i podstawowe – bez nich żadna infrastruktura nie powinna funkcjonować. Jest ich oczywiście znacznie więcej, np.: SecOps, monitoring, konteneryzacja, orkiestracja, ale moim zdaniem są to bardziej złożone procesy wynikające z przyjętej technologii oraz specyfiki projektu. Przyjrzyjmy się zatem nieco bliżej dwóm wybranym przeze mnie wzorcom.]

CI/CD (Continuous Integration / Continuous Delivery)

CI/CD (Continuous Integration / Continuous Delivery) – to szablon przepływu procesów w projekcie od momentu zaplanowania, przez wdrożenie, ciągłe utrzymywanie i monitorowanie. CI/CD to esencja kultury DevOps i warto go poznać, aby zrozumieć, jakie niesie ze sobą korzyści. Do jego składowych należą procesy:

• Plan
• Code
• Build
• Test
• Release
• Deploy
• Operate
• Monitor

Na każdy z nich można poświęcić jeden artykuł, dlatego zachęcam do skupienia się na tym wzorcu, który niewątpliwie stanowić będzie solidny fundament w rozwoju jako DevOps.

IaaC (Infrastructure-as-a-Code)

IaaC (Infrastructure-as-a-Code) – czyli infrastruktura jako kod, jest to wzorzec, dzięki któremu jesteśmy w stanie budować skalowalną infrastrukturę w sposób zautomatyzowany. Istnieje wiele podejść do tego tematu. Dostawcy zasobów chmurowych oferują swoje rozwiązania, ale istnieją również na rynku narzędzia firm zewnętrznych. Możemy wyróżnić tutaj podejście deklaratywne, jak i imperatywne – oba są mniej lub bardziej świadomie stosowane. Warto zatem zapoznać się z różnicami między nimi (poruszę ten temat w kolejnym artykule) oraz z dostępnymi na rynku narzędziami do tworzenia IaaC, takimi jak:

• Bicep
• Terraform
• Ansible
• Pulumi
• Chef

W przypadku platformy Azure, Bicep jest dedykowanym językiem do pisania deklaratywnego kodu infrastruktury. Nie zastosujemy go w przypadku innych chmur (np. AWS czy GCP). Jeżeli zależy ci zatem na narzędziu opisującym infrastrukturę deklaratywnie i ze wsparciem dla pozostałych rozwiązań chmurowych, to polecam Terraform.

Metodyki DevOps – podsumowanie

W dobie zwinnego rozwoju oprogramowania i coraz szybszej transformacji cyfrowej już nikt nie kwestionuje potrzeby posiadania w zespole specjalisty, który może nie tylko budować aplikacje w chmurze, ale też je wdrażać. Warto zainteresować się kulturą DevOps – dla wielu programistów jest to naturalna droga rozwoju.

Mam nadzieję, że po lekturze tego artykułu łatwiej będzie ci zrobić pierwszy krok w stronę rozwoju jako Azure DevOps. Jak widać powyżej, rola ta jest złożona i wymaga cierpliwości, ale jak to w życiu bywa, na wszystko potrzeba czasu. Powodzenia!

Idź do:

1. 1. Mikroserwisy – ich popularność rośnie
2. 2. Jak architektura mikroserwisów odpowiada dziś na potrzeby rozwoju systemów?
3. 3. Bolączki monolitycznej aplikacji
4. 4. Zalety wykorzystania architektury mikroserwisów
5. 5. Wady mikroserwisów
6. 6. Mikrousługi a podejście DDD
7. 7. Mikroserwisy w praktyce – case study
8. 8. Podsumowując: czy architektura mikroserwisowa sprawdzi się w moim projekcie?

Mikroserwisy – ich popularność rośnie

Pojęcie architektury mikroserwisowej pojawiło się po raz pierwszy na scenie IT w okolicach roku 2013. Od tego czasu jej popularność wydaje się poruszać tylko w jednym kierunku – w górę! Potwierdzenie takiej hipotezy możemy znaleźć na przykład w raporcie „Microservices adoption” przygotowanym przez firmę O’Reilly w roku 2020, z którego wynika, że 77% firm, w których pracują respondenci, stosują taką architekturę. Jednocześnie aż 92% pytanych określiło zastosowanie mikroserwisów jako sukces  z perspektywy oczekiwanych zysków, które przynosi takie podejście.

W innej ankiecie przeprowadzonej przez IBM Market Development & Insights o opinię zapytanych zostało ponad 1200 osób z branży IT, w tym dyrektorzy techniczni, menedżerowie i programiści pracujący w firmach, które stosują lub planują zastosować architekturę mikroserwisową.

Wyniki są jednoznaczne:

• 87% użytkowników zgadza się, że wysiłek oraz koszty poniesione na wdrożenie architektury mikroserwisowej opłacały się.
• 84% użytkowników zgadza się, że stosowanie mikroserwisów ułatwia pracę obecnym pracownikom oraz pozwala na przyciągnięcie nowych.
• 77% użytkowników zgadza się, że mikroserwisy są sprawdzonym i niezawodnym modelem tworzenia aplikacji.

Chociaż jest to oczywiście bardzo wątpliwa miara, z własnej perspektywy programisty – sądząc po opisach projektów w ofertach pracy – mógłbym stwierdzić, że praktycznie większość projektów jest aktualnie tworzona w architekturze mikroserwisowej. Pomimo że na takie opisy musimy spojrzeć z przymrużeniem oka, widać, że mikroserwisy szybko stają się standardem w świecie IT.

Jak architektura mikroserwisów odpowiada dziś na potrzeby rozwoju systemów?

Jednym z największych wyzwań architektury mikroserwisowej jest silna zależność od infrastruktury (serwerowej, sieciowej itp.), a co za tym idzie – zwiększona potrzeba inwestycji w jej tworzenie. Jeszcze kilka lat temu było to jednak dużo większym wyzwaniem niż dzisiaj. W odpowiedzi na potrzeby nowego modelu powstał szeroki wachlarz narzędzi, które usprawniają pracę w rozproszonym środowisku.

• Kontenery – na potrzeby orkiestracji serwisami powstały rozwiązania do zarządzania, automatyzacji i skalowania aplikacji kontenerowych. Dzisiaj możemy wybierać spośród wielu narzędzi, od prostych i niewymagających, jak Docker Swarm, po zakrojone na największą skalę rozwiązania enterprise, jak chyba najpopularniejszy Kubernetes lub Openshift. Dodatkowo dostępne są rozwiązania chmurowe, jak AWS Fargate czy Google Cloud Run. Każda z platform chmurowych oferuje również zarządzane przez siebie serwisy Kubernetes, jak AWS EKS lub Google GKE. Wszystkie wymienione narzędzia w znacznym stopniu zmniejszają dzisiaj próg wejścia do projektów opartych na mikroserwisach pod względem infrastruktury serwerowej. Należy jednak liczyć się z kosztami ich utrzymywania.
• Service Mesh – w odpowiedzi na wyzwania związane z silną zależnością od infrastruktury sieciowej powstało wiele rozwiązań, z których najpopularniejszy jest obecnie model Service Mesh. Tutaj znowu mamy wybór pomiędzy lekkimi rozwiązaniami jak Linkerd, Kuma czy Maesh a bardziej wymagającymi, jak Istio, oraz rozwiązaniami chmurowymi, jak AWS App Mesh. Jak widać, stworzenie infrastruktury sieciowej dla swojej aplikacji mikroserwisowej nie stanowi dzisiaj tak dużego wyzwania jak kiedyś, chociaż sama zależność od sieci jest i zawsze pozostanie wyzwaniem.
• Narzędzia do monitorowania – cytując głównego inżyniera firmy Lyft, Matta Kleina, który brał udział w przejściu firmy z monolitu na mikroserwisy:

Inną istotną zmianą, która pojawia się wraz z rozwojem mikroserwisów, jest obecność sieci jako niestabilnego elementu, którego nie da się uniknąć. Każdy programista musi w końcu poradzić sobie z problemami sieciowymi, zarówno jeśli chodzi o transport, jak i o znacznie bardziej złożone narzędzia wymagane do debugowania.

Wspomniane wyżej narzędzia wspierające pracę i debugowanie aplikacji kontenerowej również przeżyły rozkwit i dzisiaj możemy wspierać się narzędziami do monitorowania, logowania i tracingu. Rozwiązania takie jak Prometheus, ELK czy AWS CloudWatch pozwalają sprostać wyzwaniom utrzymywania lub debugowania aplikacji w rozproszonym środowisku.

Bolączki monolitycznej aplikacji

Powstanie i ostateczny sukces mikroserwisów nie wziął się oczywiście z niczego. Jest to raczej odpowiedź na trudności związane z klasycznym podejściem, które w wielu przypadkach przeważają nad plusami podejścia monolitycznego.

Z perspektywy biznesu i użytkowników

Z perspektywy biznesowej możemy wymienić wiele wad, które mogą wpłynąć na doświadczenia użytkowników i tym samym – na ostateczny sukces aplikacji:

• Wprowadzanie nawet najmniejszej zmiany wymaga reinstalacji całej aplikacji, co prowadzi do tymczasowej niedostępności aplikacji, która w nowoczesnym świecie jest praktycznie niedopuszczalna dla komercyjnych rozwiązań.
• Poszczególne komponenty systemu są ze sobą ściśle powiązane, co oznacza, że nawet mała zmiana w kodzie może negatywnie wpłynąć na całą aplikację, a tym samym być odczuwalna dla 100% jej użytkowników.
• Trudności nastręcza skalowanie aplikacji w odpowiedzi na zmienny ruch. Niemożliwe jest też oczywiście skalowanie poszczególnych komponentów systemu, a tylko całej aplikacji. W momencie przeciążenia aplikacja może stać się niedostępna dla części użytkowników.
• Brak skalowalności może się przekładać na wyższe koszty utrzymania aplikacji.
• Spowolnienie prędkości rozwoju i udostępniania nowej funkcjonalności.
• Zdecydowanie zmniejszona możliwość zastosowania nowych technologii, których wprowadzenie byłoby zbyt kosztowne i wymagałoby poświęcenia więcej czasu przez programistów (czy nawet zatrudnienia nowych).

Z perspektywy developera

Patrząc z perspektywy developera pracującego nad monolitem, możemy dodatkowo wymienić jeszcze kilka wad:

• Spora baza kodu jest trudna w zrozumieniu, co od nowego programisty wymaga dużo czasu na poznanie i wdrożenie. Spowalnia ona również codzienny cykl wprowadzania zmian i ich testowania (pamiętajmy, że każda, nawet drobna zmiana, może mieć wpływ na całą aplikację).
• Rozmyta odpowiedzialność oraz brak poczucia własności kodu może wpływać demotywująco na programistę. W przeciwieństwie do całkowitej własności części systemu, którego czujemy się autorem w przypadku tworzenia i utrzymywania konkretnych mikrousług.
• Trudność we wdrożeniu nowych, interesujących technologii, ponieważ każda taka inicjatywa oznacza wprowadzenie zmian w całej bazie kodu aplikacji.
• Mniejsze możliwości rozwoju osobistego – w dynamicznie zmieniającym się świecie IT rozważne jest, aby developer ciągle się rozwijał i zawsze dysponował aktualną wiedzą. Praca nad aplikacją monolityczną może nie być najlepszym krokiem, gdyż nie ma się styczności z szeroką wiedzą wymaganą w świecie mikroserwisów.

Zalety wykorzystania architektury mikroserwisów

Przejdźmy teraz do możliwości i udogodnień dostępnych przy wykorzystaniu mikroserwisów.

Z perspektywy biznesu i użytkowników

• Łatwa redundancja elementów (czyli duplikowanie poszczególnych komponentów celem zapewnienia ciągłości pracy w razie awarii) i ich skalowanie, zgodnie z aktualnym zapotrzebowaniem, a tym samym większa dostępność systemu. Maleje tym samym ryzyko, że użytkownik nie będzie mógł skorzystać z naszej aplikacji.
• Luźne powiązanie poszczególnych serwisów pozwala na niezależny rozwój funkcjonalności i szybsze ich wdrożenie.
• Wdrożenia mogą następować niezależnie od siebie i praktycznie nie wpływają na dostępność całości systemu dla użytkowników.
• Mikroserwisy są idealnie dostosowane do wykorzystania architektury typu serverless, która w odpowiednich zastosowaniach pozwoli zaoszczędzić na kosztach infrastruktury.
• Łatwiejsze testowanie małych komponentów pozwala na uniknięcie wystąpienia uciążliwych dla użytkowników bugów.
• Wdrożenie nowych technologii, z korzyścią dla użytkownika, jest zdecydowanie łatwiejsze i może odbywać się na poziomie poszczególnych serwisów.

Z perspektywy developerów

Z zastosowaniem mikroserwisów łączy się też kilka pozytywów dla pracujących z nimi developerów:

• Pojedyncze usługi są łatwiejsze w zrozumieniu, ich baza kodu jest też odpowiednio mniejsza. Ułatwia to pracę nad nowymi funkcjonalnościami i ich testowaniem, ale również usprawnia wdrożenie nowej osoby w projekt.
• Każdy z twórców danej usługi czuje się za nią odpowiedzialny i dobrze zna domenę biznesową powierzonej mu części.
• Możliwość eksperymentowania i poszerzania wiedzy o nowych technologiach przy tworzeniu nowych funkcjonalności.
• Mniejsza koncentracja wiedzy wśród programistów, co pozwala uniknąć sytuacji, w której brak kluczowej osoby może okazać się poważnym problemem.
• Odpowiedzialność za poszczególne komponenty jest podzielona pomiędzy oddzielne zespoły, co pozwala na skuteczne dyżurowanie i szybką reakcję odpowiednich dla danego problemu osób.

Przeczytaj także: Mikroserwisy – Service Mesh z Istio. Poznaj Istio i możliwości jakie daje.

Wady mikroserwisów

Z perspektywy biznesu

• Początkowy koszt wykonania aplikacji w architekturze rozproszonej może być wyższy niż w przypadku monolitu. Podwyższony koszt to przede wszystkim wydatek na infrastrukturę oraz zaangażowanie odpowiednich specjalistów DevOps, odpowiedzialnych za jej utrzymanie.
• Ryzyko, że realizacja aplikacji będzie utrudniona lub nawet się nie powiedzie, jest większe z powodu nieodłącznej złożoności takiej architektury.
• Wdrożenie takiej architektury wymaga zmiany podejścia całego zespołu pracującego nad aplikacją. Decyzyjność przesuwa się od menedżerów i architektów w stronę poszczególnych zespołów. Z taką autonomią przychodzi większa potrzeba skutecznej komunikacji i współpracy pomiędzy zespołami.

Z perspektywy developera

• Funkcjonalność wymagająca bezwzględnej spójności danych (transakcje bankowe itp.) jest trudniejsza do implementacji, ponieważ wymaga dodatkowej koordynacji całego procesu, który może być realizowany w kliku usługach. W aplikacji monolitycznej taki problem byłby rozwiązany za pomocą transakcji na poziomie bazy danych.
• Debugowanie może być utrudnione z powodu rozproszenia logiki w wielu usługach, których logi mogą zawierać wskazówki o błędzie. Dodatkowymi źródłami błędów mogą okazać się punkty komunikacji pomiędzy poszczególnymi usługami.
• Testowanie integracyjne nowych funkcjonalności staje się bardziej skomplikowane, ponieważ nie ma możliwości przetestowania całego systemu rozproszonego.

Mikrousługi a podejście DDD

Większość korzyści płynących z zastosowania architektury rozproszonej jest efektem stworzenia prawidłowego podziału odpowiedzialności poszczególnych usług i wyznaczenia sposobu komunikacji między nimi. Celem jest stworzenie silnej spójności serwisów i jednocześnie luźnego powiązania pomiędzy nimi. Innymi słowy, rzeczy, które zwykle wymagają wspólnej zmiany, powinny należeć do jednego serwisu. Bez odpowiedniego podziału zamiast korzyści, jak niezależna implementacja czy skalowalność usług, możemy skończyć z niewydajnym lub trudnym w utrzymaniu projektem. W praktyce jest to oczywiście trudniejsze do zrealizowania niż w teorii – wstępne założenia lub późniejsze wymagania ulegają zmianie. Z tego powodu możliwość łatwego wprowadzania zmian jest kolejnym krytycznym aspektem podczas projektowania każdej aplikacji.

Podejście Domain-driven design (DDD) jest kluczowym narzędziem podczas projektowania architektury mikroserwisowej, tak przy rozbijaniu aplikacji monolitycznej, jak i tworzeniu aplikacji od zera.

Czym jest DDD? Czyli jak okiełznać system podczas tworzenia oprogramowania

DDD zapoczątkowane w książce Erica Evansa to zestaw zasad i wzorców, których celem jest wsparcie tworzenia aplikacji rozproszonych w oparciu o model domeny biznesowej będącej tematem tworzonego oprogramowania. Zespół programistów wraz z ekspertami domeny biznesowej tworzą model biznesowy w wypracowanym wspólnym języku, tzw. ubiquitous language. Następnie stworzony model jest tłumaczony na poszczególne usługi, ustalane są protokoły komunikacji między nimi oraz tworzone są zespoły odpowiedzialne za poszczególne serwisy. W całym procesie  pomocny może być dodatkowo event storming. Wzorce DDD mają na celu ułatwienie zrozumienia domeny i zależności w niej zachodzących. Od tego już niedaleko do wyznaczenia granic w domenie, a tym samym wypracowania podziału na usługi zmapowane na domenę biznesową.

Mikroserwisy w praktyce – case study

W istniejącej od wielu lat platformie e-commerce pojawiło się nowe wymaganie biznesowe, polegające na masowym tworzeniu nowych ofert na bazie plików. Narzędzie miało być głównie stosowane przez sprzedawców oferujących szeroki asortyment, którzy w ten sposób mogliby usprawnić i zautomatyzować interakcję z platformą w kwestii tworzenia i edycji swoich ofert.

Wspomniana platforma, chociaż została stworzona jako monolit, od dawna jest już rozbita i rozwijana w architekturze mikroserwisowej. Zadanie zlecone jednemu z zespołów Inetum polegało więc na stworzeniu nowej mikrousługi (ostatecznie powstało ich kilka) odpowiedzialnej za realizację tej funkcjonalności. Prace nad rozwiązaniem postępowały bez ingerencji w resztę usług aplikacji, której rozwój mógł postępować niezależnie. Jedynym punktem styku z resztą platformy stała się inna mikrousługa, a szczegóły komunikacji i implementacji zostały ustalone pomiędzy zespołami odpowiedzialnymi za obie usługi. Również decyzje o wyborze technologii (jak baza danych czy nawet język programowania) pozostawały w dużej mierze w gestii zespołu. Po wdrożeniu na produkcję zespół Inetum jest w stanie dynamicznie skalować ilość instancji usługi adekwatnie do liczby zapytań od użytkowników.

Taka autonomia jest kluczowa przy rozwoju aplikacji, nad którą kolektywnie pracują nawet setki zespołów. Trudno sobie wręcz wyobrazić skuteczne wdrożenie takiej funkcjonalności, gdyby cala platforma była nadal monolitem.

Podsumowując: czy architektura mikroserwisowa sprawdzi się w moim projekcie?

Odpowiedź na to pytanie musi być niestety wymijająca – to zależy. Decydując się na dany model, akceptujemy kompromis, czyli przyjmujemy go razem z jego mocnymi i słabymi stronami.

Gdy chcemy rozbić monolit

Jeżeli rozważamy rozbicie istniejącej aplikacji monolitycznej, decyzja jest może prostsza, zmotywowana wszystkimi bolączkami, które nastręcza monolit. W tym przypadku jednym ze sprawdzonych podejść jest odcinanie mniejszych serwisów z głównego bloku, aż w końcu nowe funkcjonalności będą mogły być tworzone w całkowitej izolacji, a mniejszy centralny monolit będzie stopniowo wygaszany.

Gdy tworzymy aplikację od podstaw

Jeżeli jednak rozpoczynamy tworzenie aplikacji od zera, jednym z kluczowych względów, na którym możemy oprzeć decyzję, jest rozmiar docelowej aplikacji. W przypadku tworzenia MVP aplikacji, najważniejsza jest szybkość dostarczenia funkcjonalności kosztem innych priorytetów. Zgodnie z zasadą YAGNI (You Ain’t Gonna Need It) nie ma sensu inwestować w zastosowanie zbyt wyszukanych narzędzi, jeśli nie mamy pewności, że aplikacja będzie się cieszyć odpowiednim poziomem zainteresowania.

Taka sytuacja przemawia więc za zastosowaniem monolitu, który dopiero w dalszej fazie zostanie podzielony – ciekawym rozwiązaniem może być zastosowanie architektury tzw. modularnego monolitu, w której funkcjonalności rozbite są na poszczególne moduły tworzone w ramach jednej aplikacji.

Jeśli jednak wiemy, że rozmiary docelowej aplikacji uzasadniają wstępną inwestycję, wtedy architektura mikroserwisowa jest jak najbardziej rozsądnym wyborem.

Przeczytaj także: Kim jest DevOps i jak wspiera projekty IT?