Kihagyás

SNAPSHOT kiadása

Előfordulhat, hogy az ügyfél számára már akkor át kell adni tesztelésre az alkalmazást, mikor még nem készült el minden fejlesztés, amit adott verzióban szeretnénk átadni. Ilyenkor lehetőség van úgynevezett SNAPSHOT release átadására.

SNAPSHOT vs Release Canditate

Felmerülhet a kérdés, hogy miért nem Release Candidate-nek (RC) nevezzük a fent említett release-eket. Ennek egyszerűen az az oka, hogy az RC-t inkább olyan release verziókra szokás mondani amelyekbe már leginkább csak hibajavítások kerülhetnek.

Ezzel szemben SNAPSHOT verzió esetén nem szeretnénk korlátozni, hogy milyen fejlesztések várhatóak még az adott verzióban. Ezt úgy kell érteni, hogy ha pl.: 5 nagyobb fejlesztést akarunk a verzióban átadni, amelyből 1 már elkészült és tesztelhető, akkor lehetőség legyen SNAPSHOT verziót adni, ne kelljen megvárni, míg minden fejlesztés elkészül/tesztelhetővé válik.

Ebből következően az egyszerűség kedvéért minden ügyfélnek átadott, nem production környezetre szánt verziót SNAPSHOT verziónak hívunk.

1. Előkészületek - SNAPSHOT release előtt

A SNAPSHOT release előkészületei alapvetően megegyeznek a release folyamatnál leírt lépésekkel.

A különbség csupán annyi lehet, hogy a projekt igényeinek megfelelően előfordulhat, hogy nem szükséges az összes normál release során átadandó dokumentumot SNAPSHOT esetén is átadni. (Pl.: Adatbázis dokumentáció)

A documentation project releaselése

Feltűnhet, hogy a documentation repository nem szerepel az alábbi parancsokban. Ez szándékos, a documentation repository-t nem kell az alkalmazással együtt releaselni, és az OBR folyamatnak sem része.

2. SNAPSHOT release nevezéktan

A SNAPSHOT release verziószámát két feltétel határozza meg:

  • A jövőben ténylegesen kiadásra szánt alkalmazás verziószáma.
  • Hányadik SNAPSHOT-ot adjuk át az említett alkalmazás verzióhoz.

SNAPSHOT névkonvenció: 

${alkalmazás-verziószám}-SNAPSHOT${hányadik-SNAPSHOT-adott-verzióhoz}

Példa

Tehát, ha a 2.0.0 verzió fejlesztése zajlik, amiből már 2 SNAPSHOT-ot is adtunk ki korábban, de most szeretnénk egy újabbat, akkor a SNAPSHOT verzió neve az alábbi lesz: 

2.0.0-SNAPSHOT3

3. SNAPSHOT release branch

A SNAPSHOT release branch valójában bármilyen branchből ágazhat (Pl.: develop, hotfix, release, epic stb.).

Az eddigi projekt tapasztalat azt mutatja, hogy leggyakrabban akkor szükséges SNAPSHOT verziót adni, ha már létezik hagyományos release branch az adott verzióhoz, de fontos, hogy ez nem kritérium, bármi lehetne a forrás branch.

Fontos, hogy bármi is a forrás branch mindenképp hozzuk létre a SNAPSHOT release branchet és ne a forrás branchből adjuk ki a SNAPSHOT tag-et.

SNAPSHOT release branch névkonvenció: 

release/${alkalmazás-verziószám}-SNAPSHOT${hányadik-SNAPSHOT-adott-verzióhoz}

Példa

Tehát, ha a 2.0.0 verzió fejlesztése zajlik, amiből már 2 SNAPSHOT-ot is adtunk ki korábban, de most szeretnénk egy újabbat, akkor a SNAPSHOT release branch neve az alábbi lesz: 

release/2.0.0-SNAPSHOT3

4. Absztrakt SNAPSHOT release folyamat leírása

  1. A megfelelő forrás branchből készítünk egy SNAPSHOT release branchet.
  2. Befrissítjük az API verziót, amennyiben szükséges.
  3. A SNAPSHOT release branchen elkészítjük a release-t.
  4. A tag-ekből docker imageket buildelünk és a container registrybe pusholjuk megfelelő verziózással ellátva. Lásd itt.
  5. Átadjuk az ügyfélnek a docker imageket és a szükséges fájlokat.

A SNAPSHOT release brancheken észlelt bug-ok javítása

Fontos, hogy a SNAPSHOT release brancheken észlelt bugokat ne ott, hanem a forrás branchen javítsuk, ugyanis a SNAPSHOT release branch a SNAPSHOT kiadás után nem kerül visszamergelésre a forrás branchbe.

Ebből az is következik, hogy:

  • amennyiben még nem adtuk át a SNAPSHOT verziót, akkor egyszerűen rebaseljük a SNAPSHOT release branchet a forrás branchre (a hibajavítások után), és ezt követően adjuk ki a SNAPSHOT-ot.
  • Ha már átadtuk a SNAPSHOT verziót, akkor amennyiben szükséges, a hibajavításokkal új SNAPSHOT verziót adjunk ki.

5. SNAPSHOT release folyamat a gyakorlatban

Jelenleg a normál release során minden projektet releaselünk, hogy szinkronban tartsuk az egyes projektek verziószámait. Ezáltal pedig az ügyfelek számára is követhetőbb lesz milyen verziót kapnak és telepítenek.

Ez a gyakorlatban azt jelenti, hogy abban az esetben is releaselni kell például az api és frontend projekteket, ha csak a backend-ben volt tényleges módosítás stb.

Placeholderek behelyettesítése

  • Az x.y.z helyére a megfelelő verziószámot kell írni.
  • a ${forras-branch} placeholder helyére a releaselendő SNAPSHOT verzió forrás branch-ének nevét kell behelyettesíteni.
  • a ${SNAPSHOT-counter} placeholder helyére azt a számot kell írni amely leírja hányadik SNAPSHOT-ot adjuk adott verzióhoz.

Példa a placeholderek behelyettesítésére

Ha

  • a verziószám 2.0.0,
  • a forrás branch release/2.0.0
  • korábban pedig 2 db SNAPSHOT-ot adtunk már a 2.0.0 verzióhoz

Akkor az api SNAPSHOT release branch létrehozás parancsok az alábbi módon kell kinézzenek: 

$ git status
$ git checkout release/2.0.0
$ git pull
$ git checkout -b release/2.0.0-SNAPSHOT3
$ git push --set-upstream origin release/2.0.0-SNAPSHOT3

5.1 api release

Az api szeparált releaselése

Előfordulhat, hogy a projekten korábban elkészül a kontrakt az alkalmazások között és pl.: a mobil számára már előre kiadtuk a megfelelő api verziót.

Ilyenkor értelemszerűen nem szükséges ezen a ponton releaselni az api-t, amennyiben azóta nem történt benne a frontend és backend projekteket érintő módosítás.

Továbbá, ilyenkor a backend és frontend projektek release-e során, a pom.xml-ben és package.json-ben is a korábban releaselt api verziószámát kell megadni.

Az api projekt releaseléséhez az alábbi parancsokat kell parancssorból kiadni:

5.1.1 Release branch nyitása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout ${forras-branch} # Álljunk rá a megfelelő forrás branchre.
$ git pull # Álljunk rá a friss forrás branchre.
$ git checkout -b release/x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push --set-upstream origin release/x.y.z-SNAPSHOT${SNAPSHOT-counter}

5.1.2 Release kiadása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout release/x.y.z-SNAPSHOT${SNAPSHOT-counter} # Álljunk rá a SNAPSHOT release branchre.
$ git pull # Álljunk rá a friss SNAPSHOT release branchre.

A common/meta mappában található meta-data.yml fájlban frissítsük a ‘version:’ értékét az x.y.z verziószámra: 

openapi: 3.0.0
info:
  ...
  version: x.y.z-SNAPSHOT${SNAPSHOT-counter}
  ...


$ git commit --allow-empty -a -m "[release] prepare release x.y.z-SNAPSHOT${SNAPSHOT-counter}"
$ git push
$ git tag x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push origin x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ cd generate
$ npm run generate:api
$ cd ..
$ curl --user "$DOCKER_REGISTRY_USERNAME:$DOCKER_REGISTRY_PASSWORD" --upload-file openapi-backend.yml "https://gitlab.com/api/v4/projects/$BACKEND_PROJECT_ID/packages/generic/api/x.y.z-SNAPSHOT${SNAPSHOT-counter}/openapi-backend.yml"
$ curl --user "$DOCKER_REGISTRY_USERNAME:$DOCKER_REGISTRY_PASSWORD" --upload-file openapi-web.yml "https://gitlab.com/api/v4/projects/$BACKEND_PROJECT_ID/packages/generic/api/x.y.z-SNAPSHOT${SNAPSHOT-counter}/openapi-web.yml"
$ curl --user "$DOCKER_REGISTRY_USERNAME:$DOCKER_REGISTRY_PASSWORD" --upload-file openapi-mbl.yml "https://gitlab.com/api/v4/projects/$BACKEND_PROJECT_ID/packages/generic/api/x.y.z-SNAPSHOT${SNAPSHOT-counter}/openapi-mbl.yml"

A fenti curl parancsokban:

  • A $DOCKER_REGISTRY_USERNAME placeholder helyére a GitLab deploy token username-et kell behelyettesíteni.
  • A $DOCKER_REGISTRY_PASSWORD placeholder helyére a GitLab deploy token password-ot kell behelyettesíteni.
  • A $BACKEND_PROJECT_ID placeholder helyére a backend projekt GitLab-os project id-ját kell behelyettesíteni.
  • Az x.y.z placeholder helyére a verziószámot kell behelyettesíteni.

5.2 backend release

Az backend projekt releaseléséhez az alábbi parancsokat kell parancssorból kiadni:

5.2.1 Release branch nyitása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout ${forras-branch} # Álljunk rá a megfelelő forrás branchre.
$ git pull # Álljunk rá a friss forrás branchre.
$ git checkout -b release/x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push --set-upstream origin release/x.y.z-SNAPSHOT${SNAPSHOT-counter}

5.2.2 Release kiadása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout release/x.y.z-SNAPSHOT${SNAPSHOT-counter} # Álljunk rá a SNAPSHOT release branchre.
$ git pull # Álljunk rá a friss SNAPSHOT release branchre.

Frissítsük az API verziót a backend-service mappában található pom.xml-ben: 

    <properties>
        ...
        <project-api.version>x.y.z-SNAPSHOT${SNAPSHOT-counter}</project-api.version>
    </properties>


$ git commit --allow-empty -a -m "[release] prepare release x.y.z-SNAPSHOT${SNAPSHOT-counter}"
$ git push

$ git tag x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push origin x.y.z-SNAPSHOT${SNAPSHOT-counter}

5.3 frontend release

Az frontend projekt releaseléséhez az alábbi parancsokat kell parancssorból kiadni:

5.3.1 Release branch nyitása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout ${forras-branch} # Álljunk rá a megfelelő forrás branchre.
$ git pull # Álljunk rá a forrás branchre.
$ git checkout -b release/x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push --set-upstream origin release/x.y.z-SNAPSHOT${SNAPSHOT-counter}

5.3.2 Release kiadása

$ git status  # Ellenőrizzük hogy nincs változtatás azon a branchen ahol állunk.
$ git checkout release/x.y.z-SNAPSHOT${SNAPSHOT-counter} # Álljunk rá a SNAPSHOT release branchre.
$ git pull # Álljunk rá a friss SNAPSHOT release branchre.

Frissítsük az API verziót a package.json fájlban: 

 {
  ...
   "config": {
    ...
    "project_api_version": "x.y.z-SNAPSHOT${SNAPSHOT-counter}",
    ...
  },
  ...
}


$ git commit --allow-empty -a -m "[release] prepare release x.y.z-SNAPSHOT${SNAPSHOT-counter}"
$ git push

$ git tag x.y.z-SNAPSHOT${SNAPSHOT-counter}
$ git push origin x.y.z-SNAPSHOT${SNAPSHOT-counter}

Utolsó lépésként pusholjuk a docker image-eket!