Gyak02

Egy menedzsment eszköz: GitLab

A GitLab egy nyílt forráskódú, end-to-end szoftverfejlesztési platform, amely beépített verziókezelést, hibakövetést, kódellenőrzést és CI/CD-t megoldást kínál. A rendszer támogatást ad a fejlesztési feladatok menedzsmentjére, úgy mint a feladatok, mérföldkövek kezelése, valamint biztosítja ezek kapcsolatát a forráskód megfelelő elemeivel. A rendszer biztosítja a szoftverfejlesztési folyamatok menedzsmentjét, de a projektmenedzsment támogatására csak korlátozott lehetőségekkel rendelkezik. E célból más szoftveres eszközök (pl. RedMine) alkalmazása javasolt.

Mi az a CI/CD?

A CI/CD rövidítés a Continuous Integration (folyamatos integráció) és a Continuous Deployment (folyamatos telepítés) kifejezésekből származik. Ezek a gyakorlatok a szoftverfejlesztési folyamat részét képezik.

• Continuous Integration (CI): A fejlesztők rendszeresen összefésülik a kódjaikat egy közös verzióval. Ez a gyakorlat lehetővé teszi, hogy a csapat folyamatosan ellenőrizze a kód minőségét és az integráció során fellépő hibákat. A CI rendszer automatizálja a kódfordítást, tesztelést és más folyamatokat.

• Continuous Deployment (CD): A CD azt jelenti, hogy a kód változásait automatikusan telepítik a termelési környezetbe. Ez a gyakorlat lehetővé teszi a gyors és megbízható szoftverkiadások elkészítését. A CD folyamata magában foglalja a tesztelést, a konfigurációkezelést és a verziókezelést is.

A belső hálózaton elérhető GitLab-ra történő első belépés után az oktatók hozzá tudják rendelni az azonosítókat a megfelelő (egy gyakorlati és egy csapatszintű projektmunkához tartozó) projektekhez.

Ezen a kurzuson a GitLab három főbb funkcióját kell majd használni.

Repository

A GitLab alapja a git, egy elosztott verziókezelő/követő rendszer. A projekcsapatok számára biztosított GitLab projekt git repository-jába fel kell tölteni a kiválasztott projekt forrását. A "hogyan"-t (fork pl. GitHub-ról, új repo-ba klónozás, kód átmásolása és újként feltöltése, ...) a csapatokra bízzuk. Azt mindenképpen jelezni kell, hogy a projektnek melyik verzió az alapja.

Elosztott vs központosított verziókezelés

A verziókezelés két fő modell szerint működhet: központosított és elosztott módon. Nézzük meg, mi a különbség közöttük:

1. Központosított verziókezelés (CVCS): Ebben a modellben egy központi szerveren tárolják a szoftver verzióit és változtatásait. A fejlesztők a szerverről töltik le a legfrissebb verziót, és a változtatásaikat is a szerverre küldik vissza. Konfliktusok kezelése szükséges, ha két fejlesztő ugyanazon állományon dolgozik egyszerre.

2. Elosztott verziókezelés (DVCS): Ebben a modellben minden fejlesztő saját lokális másolatot (repository) tart karban. A változtatásokat először a saját gépükön rögzítik (commit), majd a központi szerverre küldik. Nincs közvetlen konfliktus a fejlesztők között, mivel mindenki saját lokális repójában dolgozik.

Megjegyzés: Természetesen az elosztott rendszerekben is jelentkeznek konfliktusok a forrásváltozások körül, ezeket azonban lokálisan kell feloldani, illetőleg kiválasztani a megtartandó kódváltozatot.

Wiki

A GitLab felületén lehetőség van Wiki oldalak készítésére, és ezen keresztüli dokumentációra. Ide lehet például a tesztterveket, teszteseteket, futási jegyzőkönyveket, riportokat feltölteni.

Ha ezt használjátok, fontos, hogy átlátható struktúrát alakítsatok ki. Nem baj, ha vannak "sandbox" szerű oldalak, de a leadandók egyértelműek, könnyen elérhetőek legyenek.

Wiki

A wiki, vagy wiki oldal egy olyan webes platform, ahol a felhasználók közösen hoznak létre és szerkesztenek tartalmat. Ezek tartalmazhatnak konstans szövegeket, képeket és hiperhivatkozásokat. Céljuk általában az ismeretterjesztés és dokumentálás.

Issue

Az issue-k a projekttel kapcsolatos bug-ok és feladatok nyilvántartására szolgálnak.

Mivel a GiLab issuekezelő rendszere nem egy kifejezetten bug reporting rendszer, a bug-ok bejelentése esetén a megfelelő szerkezetről és tartalomról nektek kell gondoskodnotok (érdemes valahol egy sablont definiálni). Nyilván nem árt, ha esetleg a feladatokra is vannak ilyen sablonjaitok.

Az issue-khoz kapcsolódóan rendelkezésre áll egy alapszintű életciklus-menedzsment (státusz: open/closed; felelős; mérföldkő; határidő; és címkék), ezt az életciklus-menedzsment rendszert, illetőleg annak elemeit majd használni kell.

Mérföldkövek

A mérföldköveket valamilyen állapot, cél megfogalmazása céljából alkalmazzák. Egy mérföldkőhöz lehet határidőt rendelni, de maga a mérföldkő nem pusztán a határidő, hanem a teljesítendő feltételek összessége. Vagyis a mérföldkő akkor teljesül, ha az összes hozzá rendelt issue meg lett oldva és le lett zárva. Mérföldköveket a GitLab oldalon a Plan/Milestones menüben a NEW MILESTONE nyomógombra történő kattintással tudunk létrehozni.

Példa mérföldkő: M0 - Előkészítés

Ez a mérföldkő akkor teljesül, ha a minden feltétel rendelkezésre áll ahhoz, hogy a projekt elindulhasson, vagyis

• a kódbázis bekerült a csapat GitLab projektjébe,
• minden csapattag hozzá lett rendelve a projekthez,
• meg lettek határozva a címkék,
• meg lettek határozva a mérföldkövek, és
• elkészült a tesztterv.

A határidő Október 3.

Címkék

A címkék az egyes issue-k megkülönböztetését, csoportosítását, állapotának jelzését teszik lehetővé. A GitLab felületén a Manage/Labels menüpontban tudunk címkéket definiálni a NEW LABEL nyomógombra történő kattintás segítségével.

Mit lehet címkékkel jelezni/jelölni?

• Az issue típusát: pl. type:bug vagy type:task.
• Az issue részletesebb státuszát, így a címkék és az Issues::Board menüpont segítségével jobban követhető, hogy egy-egy feladattal hogyan állunk. Például:
• status:new: új, nem ellenőrzött, nem jóváhagyott feladat
• status:confirmed: ellenőrzött, jóváhagyott feladat
• status:in_progress: fejlesztés/javítás alatt álló feladat
• status:testing: tesztelés alatt lévő feladat
• status:done: sikeresen tesztelve, kész
• Severity, egyfajta technikai súlyosság, nehézség hozzárendelése, pl. sev:cosmetic, sev:minor, sev:normal, sev:major, sev:critical.
• Prioritás, vagyis (üzleti) fontosság hozzárendelése, pl. pri:deferred, pri:low, pri:medium, pri:high, pri:critical.
• Modul, amellyel az adott issue kapcsolatban van, pl. mod:backend, mod:frontend, mod:API, mod:database
• Becsült ráfordítás értékét tartalmazó story pontok storypoint:1, storypoint:2, storypoint:3,storypoint:5, storypoint:8,...
• és még sokminden más is definiálható.

A GitLab eszközben a címkék segítségével hozhatók létre (CREATE LIST nyomógombra történő kattintással a Plan/Issue boards menüben) a Kanban/Scrum táblák is, amelyeket az agilis fejlesztési projektekben a könnyű átláthatóság és kezelhetőség érdekében gyakran használnak.

Bug riport

Egy bug riport elsődleges célja, hogy értesítsük a fejlesztőket arról, hogy hol, és milyen hibát találtunk annak érdekében, hogy ezt a hibát azután ki tudják javítani. A hibajavítás úgy lehetséges, ha a fejlesztők meg tudják vizsgálni a hibajelenséget, és meg tudják határozni a kiváltó okát. A bug riportnak tehát olyannak kell lennie, hogy a hibajelenséget reprodukálni lehessen, ehhez minden szükséges információt tartalmaznia kell. Ezen felül persze adminisztratív jellegű elemeket is elő lehet írni, illetve elvárás, hogy a hibajavítás folyamata és aktuális állapota is leolvasható legyen.

A hibajelentések egy lehetséges tartalma az alábbi pontokban foglalható össze:

• Egyedi azonosító
• Célszerű felvenni olyan azonosítót, amely alkalmas a tesztelési feladat azonosítására. A követhetőség és a teszttermékek kapcsolatának nyilvántartása alapvető fontosságú. Legegyszerűbb esetben ezt a kapcsolatot az azonosítók útján lehet megvalósítani. Célszerű, ha az azonosító tartalmazza a projekt azonosítóját, az érintett tesztver típusának megjelölését, egy sorszámot és a dátumot.
• Cím és rövid leírás
• Dátum, szerző, jóváhagyó
• Tesztelem
• Konkrétan meg kell jelölni melyik az a szoftverelem (dokumentáció), amelynek tesztelése során a hibát tapasztaltuk. A konkrétum azt jelenti, hogy a pontos megnevezést, verziószámot és a pontos funkcionalitást is meg kell jelölni.
• A hibát a szoftver életciklusának mely szakaszában észleltük.
• Reprodukáláshoz szükséges információk:
• mely lépések vezettek a hibához;
• hibaüzenetek leírása;
• szoftver- és hardverkörnyezet specifikációja;
• a tesztelés alatt lévő szoftver konfigurációja.
• A kapcsolódó naplóadatokat (logokat) mellékelni kell.
• Elvárt és kapott eredmények
• Pontosan definiált tesztesetet kell adni, ahol az elvárt és a ténylegesen kapott eredményeket is feltüntetjük.
• Hatályosság és súlyosság
• Gazdasági és műszaki hatásokat egyaránt fel lehet tüntetni.
• A javítás sürgőssége, prioritása
• Esemény állapota (nyitott, ellenőrzés alatt, lezárt, stb...)
• Globális hatások (pl. kapcsolódó szoftverekre nézve)
• Változások naplózása (change history)
• Konklúzió, összefoglalás

1. Feladat

Jelents be hibákat a Gitlab issuek alkalmazásával a HR portál kalkulátoraival kapcsolatban!

Felhasználói történetek (User stories)

Az agilis fejlesztési módszertanokban, különösen a Scrum esetében az egyes fejlesztési feladatokat önálló felhasználói történetekre, user storykra bontják. A user storykat minden esetben a megrendelő szemszögéből fogalmazzák meg. Általában egyszerű, egy inkremensként fejleszthető feladatot tartalmaznak. A felhasználói történetek formális szerkezettel rendelkeznek:

• As a [end user role], I want [the desire] so that [the rationale].
• A felhasználói történetből kiindulva a fejlesztési feladatot munkafeladatok szintjére (task) bontjuk le.
• Elfogadási feltételek (acceptance criteria) azok a feltételek (követelmények), amelyeket a fejlesztett funkcionalitásnak teljesítenie kell annak érdekében, hogy azt a Product Owner (PO) elfogadja és a fejlesztés eredményét átvegye. Az elfogadási feltételek a felhasználói történetekhez kapcsolódnak, de külön is megfogalmazhatók. Lényegében követelmények listájaként lehet rájuk tekinteni.

Product Owner

Az agilis fejlesztési módszertanokban a Product Owner (PO) képviseli az üzleti oldalt. Az ő szerepe a kapcsolattartás az üzlettel, az üzleti követelmények epic formájában történő megfogalmazása, annak finomítása felhasználói történetek szintjére. Az egyes fejlesztési ciklusok részére az egyes feladatokat (backlog) az üzleti oldali követelmények alapján priorizálja. A Product Owner feladata az egyes inkrementumok üzleti oldali ellenőrzése és átvétele.

A felhasználói történetek tehát olyan funkciókat reprezentálnak, ami a rendszer vagy szoftver felhasználójának lesz értékes. Ugyan a fentiek alapján azt mondtuk, hogy a Product Owner felelőssége a felhasználói történetek megírása, a valóságban ez a csapattal együtt végzett közös kreatív tevékenység.

Kritikus szempontok (3C)

A felhasználói történetek megírása, illetőleg az üzleti követelmények felhasználói történetekre való felbontása során az alábbi pontokban megfogalmazott szempontokat kell figyelembe venni:

• Kártya (Card) - a felhasználói történeteket egy tényleges kártyára (fizikai kártya vagy bejegyzés egy elektronikus táblán) írják fel.
• Beszélgetés (Conversation) - a felhasználói történet készítése során a szoftver várt funkcionalitását be kell mutatni (lehet szóban vagy dokumentáltan).
• Megerősítés (Confirmation) - az elfogadási feltételekben kerülnek rögzítésre.

Egy felhasználói történet elfogadási feltételei azok a feltételek, amelyeknek a felhasználói történet megvalósítása során teljesülniük kell ahhoz, hogy a teljesítést az érdekelt felek elfogadják. Az elfogadási feltételeket tekinthetjük tesztfeltételeknek, amelyeket a teszteknek ki kell elégíteniük, vagyis a teszteseteket az elfogadási feltételekből származtatják (Acceptance Test Driven Development ATDD). A teszteket manuálisan és automatizált módon is végrehajthatják. Az elfogadási kritériumok általában funkcionálisak, azonban figyelni kell arra is, hogy a nemfunkcionális követelményekről és az azokhoz kapcsolódó tesztesetekről se feledkezzünk meg. A tesztesetek definiálása során arra kell törekedni, hogy azokat minden érintett egyformán értelmezze.

A felhasználói történetek a projekthez kapcsolódó epicekből (az epic olyan komplex projektfeladat, amely az üzleti követelmények összességét tartalmazza) származnak, és az egy fejlesztési ciklusban (például sprint során a SCRUM-ban) megoldandó feladatokat tartalmazzák. Mikor a feladattervezés történik, a csapatnak becslést kell adni a feladat komplexitására, illetőleg a fejlesztéshez szükséges ráfordításokra. A becslés eredménye egy olyan mérőszám, amely tükrözi a feladat megoldásához szükséges erőfeszítés mértékét és a csapattagok számára ugyanazt jelenti. Nincs konkrét definíciója, minden csapatnál más és más a jelentése. Legegyszerűbb esetben a fejlesztésre fordított időt jelenti, viszont ahogy a csapat tapasztalata nő, a mérőszám egyre inkább egy absztrakt jelentéssel fog bírni.

Miért nem jó mérőszám a szükséges idő?

Azért, mert a csapattagok eltérő tapasztalattal, ismerettel és készségekkel rendelkeznek. Ugyanazt a feladatot valaki gyorsabban tudja megoldani, mint más, egy másik feladat esetében meg fordított a helyzet. A gyakorlatban a csapatok szinte mindig az időből indulnak ki, de ahogy a tapasztalat nő, úgy a mérőszám is inkább egy absztrakt komplexitást fog jelenteni, amelyben a csapattagok egyetértenek, bár nem biztos hogy pontosan meg tudják fogalmazni mi is van mögötte.

Becslések megadása a projektmunka feladataihoz

Ahogy ezt általában minden agilis csapat teszi kezdetben, a kurzusban összeállt csapatok is alkalmazhatják a szükséges időt, mint a szükséges ráfordítás mértékét.

A komplexitás becsléséről érdekes és hasznos információk találhatók ezen a blogon.

Adjunk becslést a következő feladatra!

Felhasználói történet: Könyvtári tagként szeretném a könyveket online megújítani, hogy hosszabb ideig megőrizhessem őket anélkül, hogy a könyvtárba kellene mennem.

Elfogadási kritérium: A rendszernek lehetőséget kell adnia arra, hogy a könyvtári tag olyan könyvet újítson meg, amely nem késedelmes, és amelyet nem foglalt le időközben egy másik tag. A megújítás után az esedékességi időnek meg kell hosszabbodnia.

Tételezzük fel, hogy a könyvtári rendszer fejlesztői vagyunk, de nem minden modulját ismerjük kielégítően (azaz a feladat része, hogy az érintett modulok szerkezetét és működését megismerjük).

Planning poker

A technika a Wideband Delphi becslési eljárásból fejlődött ki. A csoport tagjai úgy készítenek becsléseket, hogy a számozott kártyákat képpel lefelé az asztalra dobják, ahelyett, hogy hangosan kimondanák azokat. A kártyákat felfedik, majd megvitatják a becsléseket. A számok ilyen módon történő elrejtésével a csoport elkerülheti a lehorgonyzás kognitív torzítását, amikor az első hangosan kimondott szám precedenst teremt a későbbi becslések számára.

Egy tipikus pakliban a Fibonacci-sorozatot tartalmazó számozott kártyák találhatók, beleértve a nullát is: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; más paklik hasonló sorrendet használnak, az egyes értékek között meghatározott arányban. A Fibonacci-sorozat használata azért indokolt ahelyett, hogy egyszerűen megdupláznánk minden egyes egymást követő értéket, mert egy feladatot pontosan kétszer akkora erőfeszítésre becsülni, mint egy másik feladatot, félrevezető pontosságú. Egy olyan feladatot, amely körülbelül kétszer akkora erőfeszítéssel jár, mint egy 5-ös, vagy a duplájánál valamivel kevesebbre (8), vagy a duplájánál valamivel többre (13) kell értékelni.

A planning póker online is játszható

Nem feltétlenül kell fizikai formában beszerezni a kártyákat, hogy a becsléshez használjuk a technikát. Számos online, ingyenesen használható lehetőség is rendelkezésre áll. A gyakorlaton használható például a PlanningPokerOnline.

Teszttervezés

A tesztelés nemcsak annyiból áll, hogy elkezdjük futtatgatni a programot és nézzük, hogy olyan eredményt ad-e amire számítunk. Ezt megelőzően és utána is vannak tevékenységek, például a tesztek meghatározása, tesztkörnyezet felállítása, vagy a teszteredmények összegzése, és persze az egész folyamatnak a megtervezése, amely tevékebységek szerves részét képezik a tesztelésnek.

Egy példa szituáció

Adott egy fejlesztési projekt (QualitySoftware), amely a következő összetevőkből áll össze:

• Java statikus elemző mint "3rd party tool"
  • java programokat elemez és adatokat állít elő
  • linux/windows 32/64 bites verziók
• Vezérlő felület (web)
  • be lehet állítani, hogy mikor, milyen elemzések fussanak (milyen git repókat elemezzen)
  • egy központi gépen adott ütemezéssel futtatja a méréseket
  • az előállt adatokat feltölti az adatbázisba (egy web API-n keresztül), vagy jelzi az elemzés sikertelenségét
  • linux/windows 32/64 bites verziók
• Webszolgáltatás
  • adattárolásért felelős réteg, az adatbázis megvalósítást elrejti (web API-t ad)
  • lefelé standard sql; postgres, mysql, oracle -lel kompatibilis
• Webes felület az eredmények nézegetésére böngészőn keresztül
  • azonosított felhasználók, egyszerre többen
  • saját és publikus projektek
  • normális válaszidő
  • több projekt
  • táblázatok
  • grafikonok
  • timelineok
  • riportok

Rendelkezésre álló információk:

• Vázlatos specifikáció
• Felhasználói kézikönyv
• Példa rendszerek elemzéshez (inputok)
• Futtatható program, telepítő
• Forráskód (kivéve az elemzőt)

2. Feladat

Írjunk egy Fő teszttervet (benne csapatösszeállítással)!

3. Feladat

Készítsünk tesztterveket az egyes szintekhez és típusokhoz (nem biztos, hogy mindre szükség lesz):

• felderítő tesztelés
• egységtesztelés
• integrációs tesztelés
• rendszertesztelés
• átvételi tesztelés
• funkcionális tesztek (black box)
• nemfunkcionális tesztelés
• struktúra tesztek (white box)
• ellenőrző és regressziós tesztek
• karbantartási tesztek

GitLab és teszttervezés

Néhány szempont a projekthez:

• A tesztterveket a GitLab-ra kell felvinni.
• Lehet több tervet (egy átfogó, magas szintű, és több alacsonyabb szintű résztervet) is készíteni.
• A munka legalább 40%-át be kell ütemezni az első mérföldkő elé.
• Az ütemezés legalább heti részletességű legyen.
• A tervet a tartalma és formája alapján vizsgáljuk. Az elkészítéséhez javasolt az ezen az oldalon közzétett szempontokat alkalmazni, és az ebben a példában bemutatott sablon alapján azokat a projektünknek megfelelően alkalmazni.
• A terveknek tartalmazni kell a csapattagok személyre szabott részfeladatait.
• Az egyes részfeladatokban minden csapattag vegyen részt, de az elsődleges felelőst meg kell jelölni.
• A tervekben tüntessük fel az eredménytermékeket is, ezek legyenek egyértelműek.
• A terveket a GitLab Wiki oldalára kell feltölteni.
• A feladatokat majd a GitLab-on kell issue formájában nyilvántartani.
• A feladatleírást és a követelmények megfogalmazását (elfogadási kritériumok) a felhasználói történetek (user story) alapján adjuk meg.
• Végezzük el szükséges becsléseket is a szükséges ráfordításokra nézve, és adjuk meg annak mértékét story point formában!
• A feladatok kijelölésében a címkéket alkalmas módon használni kell.
• Ügyeljünk arra, hogy a munkamegosztás a csapattagok között egyenletes legyen, és az elvégzett munka az egyes issuek esetében követhető legyen.
• Mindenféle kapcsolódó tevékenységnek legyen nyoma, mert ez alapján lesz ellenőrizve az elvégzett munka.
• Az elkészült munkatermékeknek (teszttervek, tesztesetek, konfigurációk, teszt szkriptek, tesztjegyzőkönyvek, riportok, ...) -- típusuktól függően -- a GitLab Wiki-ben, az issuek mellékleteként, vagy a repóban meg kell jelenniük.
• A projekt értékelése a tesztterv alapján történik, a teljesítéseknek a tervvel összhangban kell lenniük.

---

Utolsó frissítés: 2025-09-11 13:01:16