Üdv a csapatban!
Szia, üdv a Gránit Guru projekten! Ezen az oldalon minden információt, ami ahhoz kell, hogy megismerd a projektet és hogy nekiláthass a feladatoknak.
Mik ezek a megjegyzések?
Az alkalmazott megjegyzés blokkok (mint amilyen ez is) jellegéről információt találsz itt.
Ezeket nyisd ki mindenképp!
Az ilyen típusú blokkok az onboarding szócikkekben gyakori pitfall-okra figyelmeztetnek, melyek elkerülésével jóval gördülékenyebben tudsz majd a projektbe beépülni.
Mi az a Gránit Guru?
A Guru alapjaiban véve egy chat-bot mely a következő egyszerűen megfogalmazható, de annál bonyolultabb feladatot látja el:
Válaszoljunk pontosan, hitelesen egy felhasználó Gránit Bankkal kapcsolatos kérdéseire.
Ennek megvalósítása egy RAG-gal megtámogatott Generatív LLM segítségével történik. Ha nem teljesen világos, hogy ezek a fogalmak mit jelentenek, ne félj, a Generatív AI koncepcionális szócikkben segítségre lelsz. Röviden és tömören viszont arról van szó, hogy a Guru nem előre megírt válaszokat ad, és nem is egy kicsinyített információhalmazból válaszol, hanem az összes rendelkezésre álló (nagy mennyiségű) forrásból meghatározza azokat, melyek érdekesek egy kérdéshez, és ezekből szerkeszti meg a választ.
A válaszadási rendszeren kívül a Guru rendelkezik egy tartalomkezelő és felügyeleti felülettel, ez az admin. Itt lehet megmondani, hogy mit is jelentsen az „összes rendelkezésre álló forrás“, azaz itt dől el, miket tekint a Guru tényeknek. Emellett az üzenetváltások nyomon követésére is itt nyílik lehetőségünk.
A Guruban zajló különböző folyamatok átfogó működéséről a Flow oldalon tudsz többet olvasni, ezt mindenképp nézd végig. Emellett Modulok szekcióban a különböző lépésekben alkalmazott eszközök mélyebb, technikaibb leírását találod, szóval amennyiben érdekel, hogy adott komponens hogy valósul meg, itt keresd.
Koncepciók
Itt fontos megemlíteni a Koncepciók szekciót is. Az itt található információk magas szintű rálátást hivatottak biztosítani egy-egy fogalomra vagy problémára. Az aloldalak célja nem az, hogy egy megoldás technikai részleteibe mélyedjenek, hanem hogy azt formálják, tisztítsák, ahogy egy kérdéskörre gondolunk.
Feladatok ütemezése – JIRA
A projekten a Delivery 360 néven ismert termékfejlesztési módszertant követjük. 2 hetes sprintekben dolgozunk, amelyeket előre egy Planning keretében tervezünk meg az azt megelőző Sprint során.
Ezen folyamat szervezésére a JIRA rendszert használjuk. Itt egy-egy feladatot jegyek („Ticket“) reprezentálnak. A projekten alkalmazott jegyek létrehozásáról, élettartamáról és kezeléséről itt találsz egy részletesebb leírást.
Fejlesztői jegyek elnevezése
A fejlesztői jegyeket „FS:“ előtaggal látjuk el, ha full-stack feladatot definiálnak (vagy csak backend, csak frontend), illetve „Data:“ előtaggal, ha Python-os/datás feladatról van szó.
Amire mindenképp érdemes figyelned a folyamatok gördülékenysége érdekében:
Figyelj a Git elnevezési konvenciókra!
Figyelj a git-es elnevezési konvenciókra. Fejlesztés során branch-ek, MR-ek és commit-ok nevei tartalmazzák a jegy számát. Az elnevezésekről bővebben itt olvashatsz: branch, MR, commit.
A helyes formátum így írható le:
Módosítsd a megfelelő státuszba a jegyeket!
Ne felejtsd el a megfelelő státuszba módosítani a jegyeket! Amennyiben befejezted a fejlesztést, review-t, bármilyen jeggyel kapcsolatos műveletet, módosítsd a státuszt. Így a következő lépésért felelős is látja, ha már foglalkozhat a jeggyel.
Várd meg, amíg lefutnak a CI pipeline-ok!
Ha fejlesztesz egy jegy keretei között, akkor várd meg, amíg a CI pipeline-ok lefutnak, mielőtt WFR státuszba helyeznéd. A CI pipeline hibák javítása is a fejlesztés része.
Adj hozzá QA instrukciókat!
Ha jegyet készítesz vagy fejlesztesz, a leírásba próbáld beleírni, hogy a QA hogyan és mit fog tudni tesztelni rajta. Ez nem vonatkozik a „Non-functional“ típusú jegyekre.
Javítás után helyezd újra WFR-be a jegyet!
Ha review során a review-er problémát talál, akkor a jegyet visszahelyezi „Selected for Development“ vagy „In Progress“ státuszba. Miután nekiállsz a problémák javításnak, ügyelj rá, hogy befejezés után ismét WFR-re módosítod a státuszt.
Kutatási jegytípus hiánya
Néha előfordul, hogy egy jegy valamiféle kutatási feladatra vonatkozik. Jelenleg erre nincs külön jegytípus, így a státuszok sem mindig túl értelmezhetők.
Környezetek és SSH hozzáférés
A jelenleg használt környezeteket a Környezetek oldalon találod. Itt lokális összeállítás nélkül is lehet kérdezni a Guru kitelepített verzióitól, illetve kezelni azokat admin-on keresztül. Új funkciók, javítások AWS-en való tesztelésére alapvetően a Dev környezetet használjuk.
Mind tesztelőknek, mind fejlesztőknek fontos lehet, hogy a kitelepített környezetek adatbázisához hozzáférjen. Ebben ugyanis például egy válaszadási folyamat köztes lépéseit is meg lehet vizsgálni, ami egy probléma nyomozását jelentősen megegyszerűsíti. Az adatbázishoz SSH kapcsolat segítségével tudsz hozzáférni, melynek beállításához itt találsz segítséget. Az adatbázisokhoz való hozzáférést IntelliJ-ben így tudod beállítani (természetesen más adatbáziskezelő eszköz is használható, a beállítás menete hasonló lesz).
Fejlesztőként hasznos lehet maguknak a folyamatoknak a log-jai is, hiszen ide jóval bővebb információmennyiséget írunk ki a futó folyamatokra vonatkozóan, mint ami az adatbázisban megjelenik. Ezek SSH-zva a megfelelő szerverre, általában az /opt/project/infrastructure/logs mappában találhatók. Innen akár ki is másolhatjuk őket az scp paranccsal.
Lokális futtatás
Ezt a szekciót akkor kövesd, ha a saját gépeden is szeretnéd futtatni a Gurut. A fejlesztői környezetek összeállításához a következő oldalak nyújtanak segítséget:
Run configok
Az asszisztens újratanulásának és szükség esetén az adatbázis eldobásával indításának gördülékenysége érdekében érdemes beállítani ezeket a Run configokat és hozzáadni a Services-hez.
Fejlesztés vs. futtatás
Amennyiben csak lokális futtatásra van szükségünk, elméletileg nem lenne szükség a teljes fejlesztői környezetek összeállítására. Ugyanakkor a projekt jelenleg nincs felkészítve arra, hogy valaki kizárólag futtatási szándékkal kezelje a kódbázist. Ilyen célra a kihelyezett környezetek, kifejezetten a dev környezet használata a szokás.
Mindhárom útmutató közös eleme, hogy be kell állítanod a GitLab hozzáférésed, és a megfelelő repo-kat egy közös könyvtárba kell lehúznod. Továbbá ügyelj az OpenAI API kulcs megszerzésére is, enélkül nem fogod tudni futtatni a rendszert.
Fejlesztés
Ez a szekció rád vonatkozik, ha fejlesztőnek érkeztél a projektre. Mindenképp hajtsd végre a lokális futtatáshoz szükséges lépéseket. A backend és frontend repo-k esetén ezek a leírások tartalmazzák a fejlesztői eszközök összeállítását is. Ha python fejlesztő vagy, érdemes a Python-os onboarding leírásnál folytatnod.
Ismerkedj meg a Git workflow-val!
A projekten egy az átláthatóság érdekében egy specifikus workflow-val dolgozunk. Ennek leírása itt található, ezzel mindenképp ismerkedj meg, hogy minimalizáljuk az ebből adódó hibákkal eltöltött időt.
Kifejezetten fontos, hogy ismerkedj meg a git rebase fogalmával, ugyanis a projekten nem merge-ekkel, hanem rebase-ekkel dolgozunk (merge kizárólag MR esetén történik, GitLab-en). A git push --force-with-lease parancs ismerete elengedhetetlen, ezzel tudjuk egy rebase után firssíteni GitLab-en is a branch-ünket.
Egy rebase szokásos menete
Amennyiben a rebase-t Git CLI-vel végzed, ennek egy szokásos lefolyása a következő:
# Lehúzzuk a develop legfrissebb verzióját és visszamegyünk a saját branch-re
git checkout develop
git fetch
git pull
git checkout sajat_branch
# Opcionális: squash-oljuk a commitjainkat
# itt N a commitjaink száma a branch-en
git rebase -i HEAD~N
# Rebase-elünk develop-ra
git rebase develop
# Frissítjük a branch-et GitLab-en
git push --force-with-lease
Közös Backend és Python service fejlesztések koordinálása
Előfordul, hogy egy feladatnak van Backend és Python oldali vonzata is. Ilyen lehet például egy új Python-alapú modul bekötése, vagy az eddigi működés módosítása. Ilyenkor nagyon fontos, hogy kommunikáljatok megfelelően a másik oldali fejlesztővel. Emellett ha API módosítás történik, akkor azt mindenképp rögzítsétek az api repó pythonservice.yml fájljában, hiszen mindkét service ebből generálja a megfelelő adatleírókat.
Tesztelés
Projektenként eltérő lehet a tesztelés menete, módszertana, illetve az, hogy a release-ek során milyen tesztelési dokumentumokat kell átadni az ügyfélnek.
Ennek kialakítása a projekten elvégzendő feladat, amihez segítséget nyújtanak az itt található teszteléssel kapcsolatos általános információk.