Środowisko testowe dla mikroserwisów

Przypuśćmy, że pewne zadanie wymaga zmian w dwóch (lub więcej) mikroserwisach. Fajnie by było wdrożyć te zmiany na jakieś środowisko testowe aby ktoś mógł to przeklikać i potestować. Chyba jedyne sensowne rozwiązanie to tworzenie izolowanego środowiska (AWS, Azure czy GCP) dla każdego zadania na JIRA czy też pull requesta tak aby dostępny był pod jakąś subdomeną.

Tylko zastanawiam się skąd serwer CI/CD ma wiedzieć który branch wdrożyć... Może gdyby nazwa brancha była taka sama w różnych repo?

Jak to wygląda u Was w firmie?

U mnie wygląda to tak:

caly zestaw mikroserwisów jest skonfigurowany jako Helm chart

nazywamy branche używając konwencji: feature/X/jakis_opis gdzie X to id zadania ze ździry

CI zajmuje się m.in budowaniem obrazów dockerowych i wrzucaniem ich do Nexusa

Mamy osobne repo do deploymentu który buduje środowisko na podstawie chartu Helm. W tym repo branchujemy tak samo jak na innych feature branchach tyle że nie dajemy żadnych zmian jeśli sam chart nie ulega zmianie. Po jednrazowym wypushowaniu na jenkinsie tworzy się job, który może być potem odpalany dowolną ilość razy.

Ten job buduje środowisko na bazie tego co ma w charcie. Jeśli znajdzie w nexusie jakieś obrazy mające label odpowiadający identyfikatorowi zadania to używa obrazu zbudowanego na feature branchu. Jeśli nie ma takiego to bierze najnowszy obraz zbudowany z mastera.

Wszystko to jest deployowane na k8s do osobnego namespace (1 branch - 1 namespace)

Oprócz tego ten job zajmuje się konfiguracją SqlServera (ten mamy poza k8s) tworząc wszystkie potrzebne bazy z odpowiednim postfixem (którym jest numer zadania)

var napisał(a):

U mnie wygląda to tak:

caly zestaw mikroserwisów jest skonfigurowany jako Helm chart

nazywamy branche używając konwencji: feature/X/jakis_opis gdzie X to id zadania ze ździry

CI zajmuje się m.in budowaniem obrazów dockerowych i wrzucaniem ich do Nexusa

Mamy osobne repo do deploymentu który buduje środowisko na podstawie chartu Helm. W tym repo branchujemy tak samo jak na innych feature branchach tyle że nie dajemy żadnych zmian jeśli sam chart nie ulega zmianie. Po jednrazowym wypushowaniu na jenkinsie tworzy się job, który może być potem odpalany dowolną ilość razy.

Czyli jednym słowem, aby postawić środowisko testowe, musicie w tym repo również utworzyć nowy branch feature/X/jakis_opis?

A co z aktualizacją podów w k8s? Mikroserwis dostaje poprawki po testach, obraz jest od nowa budowany. Jaki proces inicjuje podmianę obrazu w podzie?

Tak, tworzymy feature branch zarówno w repozytoriach z serwisami jak i tym, w którym jest konfiguracja chartu Helm.

Żeby zaktualizaować namespace trzeba odpalić ręcznie joba jenkinsowego o którym napisałem w poprzednim poście.
Mieliśmy to do jakiegoś czasu wpięte jako ostatni krok CI i wdrażało się automatycznie po każdym buildzie ale jak dla nas to generowało więcej problemów niż dawało korzyści więc przeszliśmy na ręczne zarządzanie wdrożaniami

@var: Robicie deployment tylko tych serwisów nad którymi pracujecie jako część feature-a czy całego środowiska?

Dobrze zrozumiałem, że macie osobne środowisko na każdy nowy feature?

Robimy deployment dla całego systemu. Ale nie jest on też przesadnie wielki więc nie sprawia to żadnych problemów.

Co do drugiego pytania - tak. Każdy feature jest deployowany do dedykowanego namespace'a na kubernetesie.

Robimy tak samo jak @var z tym, że my dodatkowo stawiamy też całą infrę pod spodem bo w trakcie developmentu aplikacji trwa też development części cloudowej. Oczywiście po skończonej robocie wszystko jest niszczone.

Mamy środowiska testowe. Zmiany idą tam kolejno, kawałkami. Czyli jeżeli mamy wprowadzić jakąś nową usługę, to lecą tam najpierw rozszerzenia poszczególnych usług, na sam koniec usługa którą widać, a która potrzebuje do swojego działania tych wypchniętych wcześniej zależności. Sytuacja, w której trzeba zmienić więcej niż 1 element systemu, bo inaczej system się wyzajączkuje, to moim zdaniem proszenie się o kłopoty.

Przykład: całość deployje się na jeden klaster w GKE
zmieniając po prostu dane klastra wrzucamy na inny. Mamy środowisko testowe do zabawy. I mamy ich tyle ile chcemy - doputy nam karta płatnicza się nie wyczerpie.
Koniec.

A który branch wdrożyć - np. w github actions można sobie podpiąć, że musi być odpowiednia nazwa release/* , tag. lub cokolwiek innego.
Do tego można zrobić jeszcze schemat nazewniczy sekretów (gdzie trzymamy na jaki klaster to wpada) i odpowiednio to obrobić w skryptach do deploja.
(Teraz naprawdę koniec)

Każdy serwis wdraża zmianę niezależnie na staging i prod.
Zmiana oczywiście kompatybilna wstecznie. Może być też ukryta za feature flag.
Gdy wszystkie zmiany są już wdrożone to ktoś sobie może przeklikać staging po aktywacji featura (dla kilku użytkowników przykładowo).

Z definicji mikro serwisy powinny być niezależne. Każda próba robienia E2E testów, integracyjnych środowisk to IMHO przerost formy nad treścią. Staging powienien wystarczyć dla historyjek, które dotyczą wielu serwisów / domen

@nie100sowny: hmm, a nie macie środowiska testowego? czyli jak rozumiem testy odbywają się po prostu na staging, tak? co jeżeli dwie osoby pracują równocześnie nad dwiema różnymi funkcjonalnościami? Pracują na feature branchach i kto wcześniej testuje te feature branche przed zrobieniem merge do staging?

W poprzednim projekcje miałem tak, że mieliśmy na to dwa środowiska testowe na AWS. Jeśli ktoś potrzebował testować zmianę zależną między X-Y testował to na jednym które akurat "było mniej zajęte". Wdrożenie robione pół manualnie. - ustawialo się tag taki sam na projektach zależnych i wygrywało się Jenkinsem. Nigdy nie było potrzeby posiadania większej ilości takich środowisk. Jak coś przetestowane i zaakceptowane to na staging i do deva. Pewnie zależy co robią te projekty współpracujące, bo nie raz ciężko stawiać bazy od zera, zapełniać je danymi żeby to można było przetestować jak po pełnym destructive deployment.

Zazwyczaj po prostu wdraża się zmianę w swoim serwisie i ją testuje, nie ma znaczenia, do czego ona komu jest potrzebna ani jak to ktoś potem testuje. Ale gdybym chciał przetestować zmiany w dwóch serwisach, to po prostu na środowisko testowe wrzuciłbym bym każdy z nich z wybranego przez siebie brancha.