A release menete

Amikor az alkalmazás technikai release-je elkészül (beleértve a docker image-ek pusholását is a container registry-be) az még önmagában nem elengedő ahhoz, hogy az ügyfél számára átadhatónak tekinthető legyen az új alkalmazás verzió.

Ahhoz, hogy a release késznek tekinthető legyen:

1. el kell készíteni alkalmazás verzió telepítéséhez szükséges összes fájlt és dokumentumot.
2. el kell juttatni az ügyfél által kijelölt tárhelyre/környezetre.
3. értesíteni kell az ügyfelet a telepítő fájlok elérhetőségéről, és az új verzióban szállított fejlesztésekről.
4. a projekt JIRA-ban is állítsuk az aktuális verziót RELEASED státuszba.

Automata OBR release folyamat

A fentiek közül az 1. pontot teljes mértékben lefedi a SEMI Product által kínált OBR (One Button Release) release folyamat. Az OBR használatáról itt olvashatsz részletesebben.

1. Átadandó dokumentumok/fájlok

Az ügyfél számára átadandó fájlok és dokumentumokat az alábbi lista tartalmazza:

• Release changelog a verzióban leszállított fejlesztésekről.
• Telepítési útmutató az alkalmazáshoz (Deployment guide).
• Az alkalmazás docker image-jei.
• A verzió telepítésekor lefutó SQL scriptek a futás sorrendjében aggregálva egy fájlban.
• Adatbázis dokumentáció.

1.1 Release changelog

Minden release esetén szükséges, hogy tételesen fel tudjuk tüntetni, milyen fejlesztéseket tartalmaz az adott release.

Ennek összegyűjtésére használjuk a JIRA boardunkat, ahol az adott verzióra szűrve kigyűjthetőek vagy akár exportálhatóak is a verzióban elkészült ticketek.

1.2 Telepítési útmutató

A telepítési útmutató karbantartása, bővítése egyformán minden fejlesztő kötelességei közé tartozik.

Akkor kell létrehozni és commitolni a Telepítési Útmutatót, amikor az adott fejlesztő olyan fejlesztést készít ami az ügyfél oldali üzemeltetők részéről is manuális konfigurációt igényel.

Az útmutató írásakor az elvégzendő üzemeltetői feladatok részletes és érthető leírása szükséges.

Külön figyeljünk arra, hogy karban tartunk egy teljes és egy verziónkénti telepítési útmutatót is.

• A teljes telepítési útmutató tartalmaz minden konfigurációt és üzemeltetői feladatot amit elvégezni szükséges amennyiben az alkalmazást egy teljesen új környezetre telepítik.
• A verziónkénti telepítési útmutató pedig csak az előző verzióhoz képesti új konfigurációkat és üzemeltetői feladatokat tartalmazza.

Az egyes telepítési útmutatókról és azok konvencióiról részletesebben itt olvashatsz.

Az alkalmazás verziók átadásakor csak a verziónkénti telepítési útmutató átadása szükséges. A verziónkénti telepítési útmutató minta itt található.

Fontos

Előfordulhat, hogy nincs olyan fejlesztés adott verzióban ami a korábbi verzióhoz képest extra konfigurációt igényelne. Természetesen telepítési útmutatót ilyenkor is adni kell a normál telepítési lépésekről.

Ilyen esetben a telepítési útmutató nem lesz létrehozva a fejlesztések során így annak elkészítése a releaset adó fejlesztő feladata.

Telepítési útmutató az OBR és a Teams Bot release folyamatban

Az OBR és a Teams Bot release folyamat az init-release job részeként automatikusan bemásolja a release csomagba a telepítési útmutatót. Az init release job-ról bővebben olvashatsz itt

Ennek előfeltétele, hogy a verzióhoz tartozó telepítési útmutatót bemásoljuk a documentation repository-ban a megfelelő helyre az elvárt nevezéktannal.

A documentation repositoryn belül, a docs/devops/deployment/specific-version-guides/versions mappába kell elhelyezni a telepítési útmutatót.

Az útmutató neve az alábbi módon nézzen ki: deployment-guide-for-version-{verziószám}.md. Pl.: deployment-guide-for-version-1.0.0.md.

1.3 Docker Image-ek

A docker image-eket a technikai release során létrehozott tag-ekből pusholjuk a GitLab container registrybe az itt leírt módon.

Ezt követően a container registryből tudjuk az image-eket letölteni, illetve igény szerint átnevezni az itt leírt módon.

Fontos

A release-elt image-eket mindenképpen teszteljük az AWS DEV környezetünkön, mielőtt átadjuk az ügyfélnek UAT-re (User Acceptance Testing).
Előfordulhat, hogy a projekten nincs internal DEV környezetünk, de minden más esetben győződjünk meg róla legalább
egy smoke test formájában, hogy az átadott image-ek el tudnak indulni, az alapvető funkcionalitás működik, stb.

Tipp

Amennyiben a Teams Bot alkalmazással deployolunk az AWS DEV környezetre, használjuk a no-dockerize kapcsolót, hogy a Bot ne buildeljen új docker image-et a tag-ekből.

1.4 SQL scriptek aggregált fájlja

Bár az alkalmazás verzióhoz tartozó SQL scripteket nem manulásian futtatjuk, különböző adminisztációs indokok miatt az ügyfél igény szerint elkérheti a scripteket amik az adott verzió telepítésekor le fognak futni az adatbázison.

Ehhez hozzunk létre egy fájlt, amibe a lefutás sorrendje (Liquibase DatabaseChangeLog-ban definiált sorrend) alapján aggregálva gyűjtsük össze a scripteket.

A fájl neve legyen: x.y.z_ne_futtasd.sql. Akkor is adjunk át fájlt, ha nincs SQL adott verzióban, ilyenkor a fájl neve x.y.z_nincs_sql_utasitas.sql és a fajl tartalma legyen üres.

Az x.y.z helyére az adott verziószámot kell írni. Pl.: 1.0.0.

Fontos

Már a technikai release átadásánál is kötelező lépés az SQL scriptek szemrevételezése, de az aggregált SQL fájl összeállítása közben is fussuk át a scripteket.

Ellenőrizzük, hogy biztosan minden környezeten le tudnak-e futni majd a scriptek, nem maradt-e ki migrációs script stb.

1.5 Adatbázis dokumentáció

Az adatbázis dokumentáció HTML formátumban kerül átadásra az ügyfélnek amit automatikusan generálunk az itt leírt módon.

Adatbázis kommentek

A jó dokumentáció előfeltétele, hogy az adatbázis objektumok létrehozásakor készüljenek el az adatbázis kommentek a táblákra, oszlopokra stb. Ezen kommentek meglétének ellenőrzése a review folyamat része.

2. Verzió átadása

Amennyiben az Átadandó dokumentumok/fájlok szekcióban leírt minden dokumentumot és fájlt előkészítettünk, átadható a release az ügyfélnek.

Ennek lépései a következők:

1. Másoljuk fel a telepítési útmutató-t, a docker image-eket, az aggregált SQL script fájlt és az adatbázis dokumentációt az ügyfél által kijelölt helyre.
2. Írjunk egy emailt az ügyfélnek arról, hogy hol érhetőek el pontosan az új verzió telepítőfájljai és csatoljuk az email-hez a Release changelog-ot is.

3. JIRA verzió releaselése

Fontos, hogy a release folyamat során a JIRA-ban is frissítsük a korábban definiált verziók státuszát, amennyiben azok releaselve lettek.

Ezt az itt leírt módon tehetjük meg.