Kihagyás

GitLab CI Jobok

A CI folyamat során számos különböző, általunk definiált jobot futtat a GitLab. Ezek közül vannak automatikusan, illetve manuálisan futtatott/futtatható jobok.

Az alábbi pontokban részletesen kifejtjük, hogy az egyes projekteken milyen jobok vannak, mi a feladatuk és hogyan működnek.

Runner gépek méretezése

Jelenleg a jobok futtatásához 2 féle gép áll rendelkezése. t3.medium(2vcpu, 4gb ram) és t3.large(2vcpu, 8gb ram). Hogy az adott job mekkora gépen fusson le, az a job alatt a tagnél konfigurálható. Az alapértelmezett érték a medium gép, de adott jobnál ez felülbírálható, mert tag alapján dől el, hogy melyik gépen fut le.

A CI jobok és branch elnevezések közti kapcsolat

A buildelést is végző jobok mindegyikében konfigurálva van egy mechanizmus, amivel képes a backend és frontend projektek feature branch-jeit, a hozzájuk tartozó api feature branchet használva buildelni.

Fontos, hogy a CI jobok csak abban az esetben találják meg a különböző projekteken az összetartozó brancheket, ha azokat ugyanazzal a névvel hoztuk létre. A feature branchek elnevezési konvencióiról részletesebben itt olvashatsz.

1. api projekt

1.1 validate_open-api job

A validate_open-api job feladata, hogy ellenőrizze a Swagger OpenaAPI definíciós fájl megfelel-e az OpenAPI szabványnak. A Swagger használatáról részletesebben itt olvashatsz.

Ez a job automatikusan lefut minden egyes merge_request, develop, illetve main branch commit esetén.

1.2 Release jobok

Az api release jobokat az alábbi módon lehet elindítani:

  1. Az api projektbe navigálva a baloldali menüsorból válasszuk ki a Build -> Pipelines menüpontot.
  2. A jobb felső sarokban kattintsunk a Run pipeline gombra.
  3. A megnyíló Run pipeline képernyőn a legördülő menüből válasszuk ki az aktuális release branchet (amiből a release-t adjuk), ha az még nem létezik, akkor pedig a develop branchet.

  4. A Variables szekcióban:

    1. Vegyük fel a TAG változót, az értéke pedig legyen az aktuális release verziószáma.

    Példa a release változókra

    ReleaseVariables

  5. Ha ez kész, kattintsunk a Run pipeline gombra.

  6. A megnyíló pipeline képernyőről tudjuk elindítani a release jobokat.

1.2.1 release-create-package job

  • Létrehozza (amennyiben még nem létezik) a release branchet a develop branchből.
  • Létrehozza a tag-et.
  • Pusholja az openapi-backend.yml, openapi-web.yml és openapi-web.yml fájlokat a backend repository GitLab package registry-jébe.

1.2.2 release-rollback job

  • Amennyiben a release-create-package stage sikeres futása után a projekten törölni szeretnénk a kiadott tag-eket, akkor ezzel a jobbal tudjuk megtenni. (Pl.: Szeretnénk újra kiadni ugyanazon verziójú tag-eket, mert javításokat pusholtunk a release branchekre.)
  • A job manuálisan indítható.
  • Előfeltétele, az release-create-package sikeres futása.

1.2.3 release-merge job

  • Amennyiben a release-create-package job sikeres futása után a projekten mergelni szeretnénk a release branchet a main és develop branchekbe, akkor az ezzel a jobbal tehető meg automatizáltan.
  • A job manuálisan indítható.
  • Előfeltétele, az release-create-package job sikeres futása.

2. backend projekt

2.1 build-checkstyle-test-backend-1 job

A build-checkstyle-test-backend-1 job végzi a backend projekthez kapcsolódó legfontosabb kódellenőrző feladatokat.

Ez a job automatikusan lefut minden egyes merge_request, develop, illetve main branch commit esetén.

Három lépésből áll:

  1. Projekt kód buildelése.
  2. Checkstyle szabályok validálása.
  3. Automata tesztek futtatása.

2.2 merge-jacoco-report job

Amennyiben a projektek a tesztek számossága miatt jelentősen megnő a build-checkstyle-test-backend-1 futási ideje, akkor lehetőség van több build-checkstyle-test-backend jobot definiálni.

Pl.:

  • build-checkstyle-test-backend-1
  • build-checkstyle-test-backend-2
  • build-checkstyle-test-backend-3

Ahhoz, hogy a GitLab felületén a tesztlefedettség helyesen jelenjen meg, a build-checkstyle-test-backend jobok lefutása után, a merge-jacoco-report összefésüli a tesztek futásának eredményét egyetlen jacoco report-ba.

2.3 validate-code-style job

A validate-code-style job ellenőrzi, hogy a kód az IntelliJ Code Style-nak megfelelően van-e formázva.

Ehhez ugyanazt az intellij_codestyle.xml-t használja, amit a fejlesztők a saját fejlesztői környezetükön is importálnak az IntelliJ-be. Ez a fájl alapértelmezetten a backend projekt build-tools/codestyle mappájában található.

2.4 build-test-sql job

A build-test-sql job ellenőrzi, hogy nem módosultak-e a korábbi verzióban már kiadott SQL scriptek.

Ez a job automatikusan lefut minden egyes merge_request, illetve develop branch commit esetén.

Erre a jobra azért van szükség, mert az alkalmazás indítása során ezt a Liquibase is ellenőrzi és amennyiben módosítást észlel a korábbi changeSet-ek scriptjeiben, úgy hibát jelez és nem indul el az alkalmazás. A Liquibase projekten történő használatáról itt olvashatsz részletesebben.

Működése:

  1. A backend projekt backend-service/src/main/resources/db mappájába checkoutolja a main branch állapotát.
  2. Megfelelően paraméterezve kiadja a ./mvnw liquibase:update parancsot ami lefuttatja a changeSet-eket az adatbázison.
  3. Ezzel előáll a production környezettel (changeSet-ek tekintetében) megegyező adatbázis állapot.
  4. A backend projekt backend-service/src/main/resources/db mappáját visszaállítja az aktuális branch állapotára.
  5. Megfelelően paraméterezve újra kiadja a ./mvnw liquibase:update parancsot.
  6. Amennyiben a Liquibase nem jelez hibát, úgy az aktuális branchen a fejlesztés során nem módosultak a main branchen már megtalálható changeSet-ek scriptjei. Ellenkező esetben hibát dob.

2.5 deploy-to-aws job

A deploy-to-aws job segítségével, a branchez tartozó alkalmazás verzióból utoljára GitLab / Container Registry-be pusholt alkalmazás verzió telepíthető az AWS tesztkörnyezetre.

Ez a job manuálisan indítható a GitLab felületén.

A gyakorlatban ez a job SSH-n keresztül csatlakozik az AWS környezethez és egy úgynevezett appuser technikai felhasználó nevében deployolja mind a backend, mind pedig a frontend alkalmazásokat.

Ennek előfeltétele a GitLab CI változók konfigurálása és az AWS környezeten az appuser felhasználó itt leírt módon történő létrehozása.

2.6 push-docker-image-backend job

A push-docker-image-backend job segítségével állíthatóak elő és pusholhatóak a GitLab / Container Registry-be, a branchez tartozó verziószámmal ellátott docker image-ek a backend alkalmazásokból.

Ez a job manuálisan indítható a GitLab felületén.

Fontos

Amennyiben már létezik a GitLab / Container Registry-ben a branchez tartozó verziószámmal docker image, úgy push-docker-image-backend job hatására az felül lesz írva az új image-el.

A job sikeres futásának előfeltétele a GitLab CI változók konfigurálása.

2.7 release-docker-images-backend job

A release-docker-images-backend job segítségével állíthatóak elő és pusholhatóak a GitLab / Container Registry-be, a tag-ek nevével verziózott docker image-ek a backend alkalmazásokból. Ebből következően ez a job csak tag-ek esetén indítható.

A projekten a tag-ek neve az éppen aktuális alkalmazás verziószámmal egyezik meg. Ebből következik, hogy ha a tag-ünk neve 1.0.0, akkor a backend alkalmazásokból GitLab / Container Registry-be pusholt image-ek az alábbiak lesznek:

  • backend-service:1.0.0
  • backend-emulator:1.0.0

Ez a job manuálisan indítható a GitLab felületén (kizárólag tag-eknél).

A job sikeres futásának előfeltétele a GitLab CI változók konfigurálása.

2.8 OBR release jobok

A backend projektben vannak definiálva az OBR release folyamathoz szükséges jobok is.

Ezekről a jobokról itt olvashatsz részletesebben.

2.9 recreate-caches job

Annak érdekében, hogy ne kelljen minden egyes job futása során letölteni ugyanazokat a maven/npm függőségeket, a recreate-caches job naponta egyszer lefut, és feltölti ezeket a függőségeket egy .zip archív fájlban a GitLab szerverre. Ezt a fájlt a megfelelő jobok induláskor letöltik és felhasználják.

A recreate-caches job működéséhez az itt található GitLab konfigurációs lépéseket el kell végezni a backend repositoryn.

2.10 push-intellij-image job

A push-intellij-image jobot tudjuk arra használni, hogy egy feltelepített IntelliJ Community Editiont tartalmazó docker image-et pusholjunk a Semi Product container registry-jébe.

Ez a job alapértelmezetten nem jelenik meg a projekteken, és nem is szükséges használni.

A push-intellij-image jobot az alábbi módon lehet Semi Product-on elindítani:

  1. A backend projektbe navigálva a baloldali menüsorból válasszuk ki a Build -> Pipelines menüpontot.
  2. A jobb felső sarokban kattintsunk a Run pipeline gombra.
  3. A megnyíló Run pipeline képernyőn a legördülő menüből válasszuk ki a develop branchet.
  4. A Variables szekcióban vegyük fel az INTELLIJ_VERSION változót. Pl.: 2023.1.1.
  5. Ha ez kész, kattintsunk a Run pipeline gombra.
  6. A megnyíló pipeline képernyőről tudjuk elindítani a push-intellij-image jobot.

2.11 create-schema job

A create-schema job segítségével hozhatunk létre az AWS dev környezetünkön egy új adatbázis sémát.

Indítása: Ezt a jobot elsősorban a Teams Bot deploy funkciója miatt hoztuk létre, de kézzel indítva is létrehozhatunk vele sémát az AWS teszt adatbázisunkban:

  1. A backend projektbe navigálva a baloldali menüsorból válasszuk ki a Build -> Pipelines menüpontot.
  2. A jobb felső sarokban kattintsunk a Run pipeline gombra.
  3. A megnyíló Run pipeline képernyőn a legördülő menüből válasszuk ki a develop branchet.
  4. A Variables szekcióban vegyük fel az TARGET_SCHEMA változót. Az itt megadott néven fogja a job létrehozni az új sémát.
  5. (Opcionális) A Variables szekcióban vegyük fel az SOURCE_SCHEMA változót. Az itt megadott nevű séma adataival fogja feltölteni a job az új sémát. Értelemszerűen, ennek a sémának léteznie kell. Amennyiben ezt a változót nem adjuk meg, egy üres séma fog létrejönni.
  6. Ha ez kész, kattintsunk a Run pipeline gombra.

  7. A megnyíló pipeline képernyőről tudjuk elindítani a create-schema jobot.

    CreateSchemaJob

Működése:

  • Ha nincs megadva a TARGET_SCHEMA változó akkor a job hibára fut és kilép.
  • Ha a TARGET_SCHEMA változóban megadott névvel már létezik séma, akkor a job egyszerűen kilép. (Nincs teendője.)
  • Ha nincs megadva a SOURCE_SCHEMA változó, akkor egy új üres sémát hoz létre, a TARGET_SCHEMA változóban megadott névvel.
  • Ha meg van adva a SOURCE_SCHEMA változó, de nem létezik a megadott névvel séma, akkor a job hibára fut és kilép.
  • Ha meg van adva a SOURCE_SCHEMA változó, és létezik a megadott névvel séma, akkor a job egy új sémát hoz létre a TARGET_SCHEMA változóban megadott névvel, feltöltve a SOURCE_SCHEMA adataival.

3. A frontend projekt

3.1 frontend-admin, frontend-client és frontend-partner job

A frontend-admin, frontend-client és frontend-partner jobok végzik a frontend projekthez kapcsolódó legfontosabb kódellenőrző feladatokat.

Ezek a jobok automatikusan lefutnak minden egyes merge_request, develop, illetve main branch commit esetén, amennyiben kódmódosítás történt az admin és/vagy client frontend projektek valamelyikében. Értelemszerűen, ha csak az egyik projektben történt kódmódosítás, úgy csak az egyik job, ha mindkét projektben történt kódmódosítás, akkor mindkét job automatikusan lefut.

Két lépésből állnak:

  1. Projekt kód buildelése.
  2. Prettier és ESLint szabályok validálása.

3.2 push-docker-image-frontend-admin, push-docker-image-frontend-client és push-docker-image-frontend-partner

A push-docker-image-frontend-admin, push-docker-image-frontend-client és push-docker-image-frontend-partner jobok segítségével állíthatóak elő és pusholhatóak a GitLab / Container Registry-be, a branchez tartozó verziószámmal ellátott docker image-ek a frontend alkalmazásokból.

Ez a job manuálisan indítható a GitLab felületén.

Fontos

Amennyiben már létezik a GitLab / Container Registry-ben a branchez tartozó verziószámmal docker image, úgy push-docker-image-frontend-admin, push-docker-image-frontend-client és push-docker-image-frontend-partner jobok hatására az felül lesz írva az új image-el.

A job sikeres futásának előfeltétele a GitLab CI változók konfigurálása.

3.3 release-docker-images-frontend-admin, release-docker-images-frontend-client és release-docker-images-frontend-partner

A release-docker-images-frontend-admin, release-docker-images-frontend-client és release-docker-images-frontend-partner jobok segítségével állíthatóak elő és pusholhatóak a GitLab / Container Registry-be, a tag-ek nevével verziózott docker image-ek a frontend alkalmazásokból. Ebből következően ez a job csak tag-ek esetén indítható.

A projekten a tag-ek neve az éppen aktuális alkalmazás verziószámmal egyezik meg. Ebből következik, hogy ha a tag-ünk neve 1.0.0, akkor a frontend alkalmazásokból GitLab / Container Registry-be pusholt image-ek az alábbiak lesznek:

  • admin-spa:1.0.0
  • client-spa:1.0.0
  • partner-spa:1.0.0

Ez a job manuálisan indítható a GitLab felületén (kizárólag tag-eknél).

A job sikeres futásának előfeltétele a GitLab CI változók konfigurálása.

3.4 recreate-caches job

Annak érdekében, hogy ne kelljen minden egyes job futása során letölteni ugyanazokat a maven/npm függőségeket, a recreate-caches job naponta egyszer lefut, és feltölti ezeket a függőségeket egy .zip archív fájlban a GitLab szerverre. Ezt a fájlt a megfelelő jobok induláskor letöltik és felhasználják.

A recreate-caches job működéséhez az itt található GitLab konfigurációs lépéseket el kell végezni a frontend repositoryn.

4. A documentation projekt

4.1 build job

A build job végzi a documentation projekt buildelését. Erre azért van szükség, hogy lássuk nem törtük-e el a dokumentációt, azaz továbbra is elállítható-e a statikus weboldal a dokumentációból.

Ez a job automatikusan lefut minden egyes merge_request, develop, illetve main branch commit esetén.

4.2 pages job

A pages job szerepe, hogy a documentation projektből buildelt statikus weboldalt publikálja a GitLab pages szolgáltatását használva.

Ez a job automatikusan lefut minden egyes develop branch commit esetén.

4.3 deploy job

A deploy job feladat, hogy documentation projektből előállítsa és pusholja a latest verzióval ellátott image-et a GitLab / Container Registry-be, majd pedig deployolja is azt az AWS környezetre.

Ez a job jelenleg manuálisan futtatható a GitLab felületén, de igény szerint módosítható, hogy minden develop branch commit esetén automatikusan lefusson.

A gyakorlatban ez a job SSH-n keresztül csatlakozik az AWS környezethez és egy úgynevezett appuser technikai felhasználó nevében deployolja a dokumentáció docker image-jét.

Ennek előfeltétele a GitLab CI változók konfigurálása és az AWS környezeten az appuser felhasználó itt leírt módon történő létrehozása.