CICD pipeline w QA, jak to dokladnie wyglada

Generalnie bardziej mi chodzi o samo CI anizeli CICD.

Mam problem ze zrozumieniem jednego elementu.. Wszedzie, gdzie patrze tutoriale ,pipeline jest triggerowany commitem od QA co dla mnie jest po prostu niezrozumiale, przeciez devi tworza nowe wersje aplikacji i to one powinny triggerowac zbudowanie sie aplikacji i uruchomienie testow, a nie commit od testera. Dobrze mowie czy nie?
Kazdy jeden tutorial pokazuje triggerowanie pipelina po commicie od testera. Nie ogarniam tego ...

WG mojego wyborazenia pipeline powinien bazowac na repozytoriach > 1 devowo do zbudowania aplikacji oraz 2 > do pobrania testow ktore beda uruchomienie na zbudowanej nowej wersji aplikacji z punktu 1

Czyli

JOB1 = GITLAB(commit triggeruje budowanie kodu) >
JOB2 = deploy na jakims serwerze/wirtualce

JOB3 = GITLAB(testy z repo od testerow wykonuja sie na zbudowanej najnowszej wersji aplikacji i zdeployowanej w JOB2 )

Elementem, ktorego nigdzie nie widzialem jest bazowanie na dwoch repo czyli od DEV i od QA

Jesli to wyglada inaczej, wytlumaczcie mi prosze. Zeby bylo smieszniej tlumacze w robocie u siebie ludziom pipeliny na jenkinsie ale w embedded i wyglada to calkowicie inaczej, chcialbym sie dowiedziec jak wyglada to na innym stacku wlasnie z selenium bo robota do ktorej bede chcial sie dostac wymaga wlasnie GITLAB CI i chcialbym to dobrze zrozumiec.

jkb91 napisał(a):

Wszedzie, gdzie patrze tutoriale ,pipeline jest triggerowany commitem od QA co dla mnie jest po prostu niezrozumiale, przeciez devi tworza nowe wersje aplikacji i to one powinny triggerowac zbudowanie sie aplikacji i uruchomienie testow, a nie commit od testera.

Elementem, ktorego nigdzie nie widzialem jest bazowanie na dwoch repo czyli od DEV i od QA

Ale który pipe line jest triggerowany? Pipeline dla ktorego repo? I jak rozpoznajesz deva od testera od strony jenkinsa?

No bo mozesz mieć dwie różne sytuacja (z oboma się spotkałem)

1. testy (akceptacyjne?, systemowe?, integracyjne duże?) od testerów są w osobnym repo
2. testy (akceptacyjne?, systemowe?, integracyjne duże?) od testerów są w tym samym repo

W przypadku pierwszym czy możesz rozróżnic commit od testera od commitu od programisty?

Ale te wszystkie moje pytania to i tak zasłona dymna do tego że nigdy nie spotkałem żeby QA puszczało testy commitem :D :D :D

Albo testy od testerów są w pięte w główny pipeline, albo są puszczane ręcznie lub okresowo, np co godzinę. Co to za dziwny tutorial znalazłeś?

Dzieki za odpowiedz.... no wlasnie jak popatrzysz sobie na tutoriale od CI pod QA to jest tragedia jak to tlumacza i to dodatkowo daja przyklad gdzie testy leca przykladowo na jakiejs stronce Online co jest tragedia bo odzwierciedla to testy na produkcji ....

Ale te wszystkie moje pytania to i tak zasłona dymna do tego że nigdy nie spotkałem żeby QA puszczało testy commitem :D :D :D

Wlasnie o to mi sie rozchodzi, ze na tych tragicznych tutorialach jest tak jak napisalem .....

Elementem, ktorego nigdzie nie widzialem jest bazowanie na dwoch repo czyli od DEV i od QA
Ale który pipe line jest triggerowany? Pipeline dla ktorego repo? I jak rozpoznajesz deva od testera od strony jenkinsa?

To wlasnie bym sie chcial dowiedziec jak powinno to wygladac w praktyce.

testy (akceptacyjne?, systemowe?, integracyjne duże?) od testerów są w osobnym repo
testy (akceptacyjne?, systemowe?, integracyjne duże?) od testerów są w tym samym repo
W przypadku pierwszym czy możesz rozróżnic commit od testera od commitu od programisty?

Czy to nie powinno byc tak>podalem 2 przyklady na podstawie tego cytatu powyzej

1.Commit od dev triggeruje pipeline >budowanie>deploy aplikacji>uruchomienie testow QA ze wspolnego REPO << Czy to jest ok?

Jesli to powyzej by sie zgadzalo to wlasnie jak bedzie wygladala druga wersja? tak moze>>

2.Commit od dev triggeruje pipeline(job triggerowany przez commit do REPO1) >budowanie>deploy aplikacji>uruchomienie testow QA z innego REPO(REPO2) << Czy to jest ok?

jeszcze co do tego

Albo testy od testerów są w pięte w główny pipeline, albo są puszczane ręcznie lub okresowo, np co godzinę. Co to za dziwny tutorial znalazłeś?

robie to wlasnie obecnie w firmie ale wyobrazam sobie taka sytuacje ze jesli mamy aplikacje i jest wiele commitow dziennie to te testy powinny chyba sie uruchamiac/byc triggerowane same, gdy commit od devow zostanie dodany.

Jesli myle sie gdzies to prosze popraw mnie. Chodzi mi o to ze jak zmienie robote i beda mi kazali zrobic pipeline to bede wiedzial o co im chodzi :) Obecnie pipeline puszczam, gdy zainstaluje soft wiec manualnie ale tak jak mowie u mnie nie ma innej opcji :)

Albo testy od testerów są w pięte w główny pipeline, albo są puszczane ręcznie lub okresowo, np co godzinę. Co to za dziwny tutorial znalazłeś?

Co masz na mysli mowiac glowny pipeline? Moglbys to opisac... moze wlasnie o to mi chodzi a nie wiem jak to napisac.

jkb91 napisał(a):

Dzieki za odpowiedz.... no wlasnie jak popatrzysz sobie na tutoriale od CI pod QA to jest tragedia jak to tlumacza i to dodatkowo daja przyklad gdzie testy leca przykladowo na jakiejs stronce Online co jest tragedia bo odzwierciedla to testy na produkcji ....

Testy często automatyczne mogą też być dodatkowo uruchamiane na produkcji

W jednym projekcie mieliśmy osobne testy read only które zawsze można było puścić na produkcji w jako duży check czy bardziej testy smoke'owe
W innym projekcie mieliśmy osobnego tenanta na którym puszczaliśmy testy zmeinaijące stan aplikacji

robie to wlasnie obecnie w firmie ale wyobrazam sobie taka sytuacje ze jesli mamy aplikacje i jest wiele commitow dziennie to te testy powinny chyba sie uruchamiac/byc triggerowane same, gdy commit od devow zostanie dodany.

Tak mi się jeszcze przypomniało że testy od testerów mogą długo trwać więc czasem są uruchamiane nie po każdym commicie od developera. Wtedy mogą chodzić w pętli lub cronie co pewien okres czasu lub być puszczane na specjalne okazje.
Podobnie jest z testami wydajnościowymy. W jednej firmie mieliśmy osobnych testerów wydajnościowych i zawsze musiałem ich prosić o puszczenie dodatkowe puszczenie testów. Normalnie testy wydajnościowe uruchamiali tylko przed releasem.
Wtedy właśnie masz sytuację że cały czas stoi sobie aplikacja gdzieś na serwerze w wersji testowej a ty ją mielisz długo trwającymi testami akceptacyjnymi

Testy powinny odpalać się po tym, jak programista zmerguje do mastera.
Jeśli nie będą odpalane za każdym razem, to nie osiągniemy CD.

Commit QA do repozytorium testowego też pewnie powinien coś odpalać, tylko to jest jakby mniej ważne, bo dotyczy nowych testów nowego ficzera, a celem odpalenia po mergu deweloperskim sprawdza już istniejące ficzery.

Przez ostatnie parę lat pracy widziałem taki wzorzec:

• Pipeline odpala się gdy ktoś tworzy lub zmienia (nowe commity) Pull Request albo Merge Request.
• Pipeline odpala się, gdy PR/MR zostaje zmergowany do głównego brancha.
• Pipeline odpala się, gdy pojawią się nowy tag, który symbolizuje wersję produktu.
• Na master/main są inne zadania, które dodatkowo robią na przykład publikację obrazów dockera.

Co do deploya - git ops. Konfiguracja jest trzymana w gicie, coś tego gita obserwuje (np ArgoCD). Zmieni się konfiguracja na gicie to następuję update deploymentu.

Dobrze kombinujesz, testy powinny się odpalać po zmianie w kodzie aplikacji. Problemem jest Gitlab, w którym uruchomienie pipeliny z innej pipeliny było dość trudne, Dlatego masz tutoriale do rzeczy, które zrobić łatwo, a nie do tych, które mają sens.