04. gyakorlat

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!

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: 2024-09-02 12:56:34