Szerkesztés alatt!

Az oldal további része szerkesztés alatt áll, a tartalma minden további értesítés nélkül többször, gyakran, jelentősen megváltozhat!

1. gyakorlat: GitLab¶

A gyakorlat során a Szoftverfejlesztés Tanszék Hallgatói Demonstrációs GitLab Szerverét fogjuk használni. Erre a szerverre elméletileg mindenki jogosult belépni, akinek az Informatika Intézet rendszereiben h-s azonosítója és hozzá tartozó jelszava van (vagyis például a géptermekben fel tudja mountolni a home-ját, be tud lépni a Bíróra vagy Concierge-re). Maga a GitLab az első belépés után fogja felhasználóként felismerni és számon tartani az adott azonosítót, így erre a szerverre mindenkinek be kell lépnie még lehetőleg az óra előtt.

Feladat: GitLab belépés

A h-s azonosítód és a géptermekben használt jelszavad segítségével lépj be a Szoftverfejlesztés Tanszék Hallgatói Demonstrációs GitLab Szerverére a https://git-okt.sed.inf.szte.hu/ címen!

A szerveren a kurzusnak fenntartott csoportban, azon belül is a saját gyakorlatnak fenntartott alcsoportban lehet majd (módjával) garázdálkodni.

Gyakorlatvezetői feladat: Jogosultságok

Ezen a ponton a gyakorlatvezetőnek lesz feladata: az adott gyakorlatokra járó hallgatókat hozzá kell adnia a gyakorlati csoporthoz. A jogosultsági szint DEVELOPER, a lejárati dátum pedig valamikor a vizsgaidőszak vége után a nem túl távoli jövőben legyen.

A megfelelő GitLab szervert válaszd!

Az inf.szte.hu domain-en belül több GitLab szerver is üzemel, amelyekre a h-s azonosítóval be tudsz lépni. Ezen az órán a https://git-okt.sed.inf.szte.hu szervert kell használnod, erre kell belépned! Ha nem látod a csoportot, pedig a gyakorlatvezető megadta a jogokat, vagy a gyakorlatvezető nem talál téged a felhasználók között, pedig te be vagy lépve, akkor gyanús, hogy éppen másik szervert nézel.

Verziókövetés¶

A verziókövetés lényegében valamilyen információ - például a forráskód - több változatának menedzselése.

A verziókövető rendszerekről (mint amilyen a Git is) egyelőre annyit említünk meg, hogy egy-egy repository-ban tudjuk tipikusan fájlok, mappák verzióit tárolni, és ezen verziók bármelyikéhez hozzá tudunk férni. Ez gyakorlatilag még egy dimenziót hozzátesz a könyvtárszerkezetünkhöz (vagy bejárhatóvá teszi az idő dimenziót, kinek hogyan tetszik).

Ez most csak ezért és annyira fontos, merthogy a GitLab (és hasonló, verziókövetőkre épülő feladat- vagy issue-kezelő rendszerek, pl. GitHub, BitBucket) alapja a Git (vagy valamely más verziókövető), ehhez nyújt egy felületet és további szolgáltatásokat. Ezen rendszerek lényege, hogy egyszerre biztosítják a Git (vagy valamely más verziókövető) általi verziókövetést, illetve számos egyéb, a csapatmunkát elősegítő funkciót is, többek között feladat és hibakövetést, wiki oldalakat, vagy a projekt build-elését, deploy-olását elősegítő eszközöket is.

Git repository és GitLab projekt

Ami a Git-ben egy repository, az a GitLab-on egy projekt alapja, egy GitLab projekt egy konkrét Git repository-hoz nyújt kiegészítő támogatást.

Feladat és hibakövető rendszer¶

A feladat és hibakövető (vagy ahogy manapság elterjedt, issue-kezelő) rendszerben (többek között) fejlesztési projektek feladatait, információit, meta-adatait tudjuk tárolni és kezelni.

Célja a fejlesztés nyomonkövetése
Fejlesztési igényeket, feladatokat lehet megfogalmazni
A szoftverrel, annak egyes verzióival kapcsolatos hibákat lehet bejelenteni (és a verzióhoz kötni)
Az egyes issue-kat tudjuk menedzselni, megvitatni, fejlesztőkhöz hozzárendelni, jelezni, ha megjavult és a javítást össze tudjuk kötni a szoftver valamely verziójával
A csapat munkáját teljes kontextusban láthatjuk, látjuk az előrehaladás mértékét, a várható befejezést, hátralévő munkát, stb.

A félév során mi a GitLab Issue Board-ját fogjuk használni, de több szoftveres megoldás is létezik.

A gyakorlat során használandó GitLab¶

A GitLab-on csoportokat, alcsoportokat, és projekteket lehet létrehozni (többek között). A félév során a tárgy kurzusai az SDP25-SzoftverfejlesztesiFolymatok csoport alatt lesznek elérhetők, ezen belül pedig minden gyakorlathoz tartozik egy-egy külön alcsoport (SDP25-IBNa1017L-% névvel, ahol a % helyére a gyakorlat sorszámát kell behelyettesíteni). Ezen alcsoportokhoz az adott kurzusra járó hallgatók lesznek hozzárendelve (az első belépésük után). Az alcsoportokban lesz egy-egy közös folyamatok nevű projekt, és a gyakorlat során mindenki kap (készít magának) egy saját, SDP25-hxxxxxx nevű projektet is (ahol természetesen a hxxxxxx helyére a saját h-s azonosítót kell beilleszteni).

Feladat: Saját projekt létrehozása

Lépj be a Hallgatói Demonstrációs GitLab Szerveren a SDP25-SzoftverfejlesztesiFolymatok csoport saját gyakorlatodhoz rendelt SDP25-IBNa1017L-% nevű alcsoportjába!
Készíts egy új üres (blank) projektet, amelynek a neve (Project name) SDP25-hxxxxxx, ahol a hxxxxxx helyére a saját h-s azonosítódat helyettesíted! A projekt url-je (Project slug) ugyanez legyen, kisbetű-nagybetű pontosan!

Jogosultságok

A GitLab-on ötféle jogosultsági szint van, növekvő sorrendben: GUEST (vendég), REPORTER (bejelentő), DEVELOPER (fejlesztő), MAINTAINER (karbantartó), és OWNER (tulajdonos). A jogosultsági szintek a csoportokból az alcsoportokra illetve projektekre öröklődnek. Így a fentiek szerint létrehozott saját projekthez a csoporttársainknak DEVELOPER joga van, cserébe mi is DEVELOPER jogokkal rendelkezünk az ő projektjeikben. Ezt próbáljuk meg komolyan venni, és nem beletrollkodni mások projektjeibe, hogy a mienkbe se trollkodjon bele senki.

A megfelelő helyen tevékenykedj!

DEVELOPER jogokkal elég sok mindent tudsz csinálni. Figyelj arra, hogy mindig a megfelelő csoportban vagy projektben tevékenykedj!

Projektet például létre tudsz hozni magadnak a csoporton kívül, de ezt alapesetben a gyakorlatvezető -- és senki más -- nem fogja látni, így nem tudja ellenőrizni sem.

Milestone-t, label-t fel tudsz venni a projekthez, de a csoporthoz is. Ha a csoporthoz veszed fel (vagy a projektedből promote-álod a csoportba), az öröklődik a csoporton belül mindenki más projektjére is, így ők nem lesznek képesek ugyanezt az elemet még egyszer létrehozni (csak használni tudják majd).

Milestone, Issue, Label¶

Egy Milestone (mérföldkő) a fejlesztési folyamatnak egy meghatározott pontja, valamilyen célok, állapot elérése.

Egy Issue az valamilyen követelmény, ötlet, probléma, bug, feladat, vagy bármi, amihez kapcsolódóan a fejlesztés során tennivalónk van/lesz. Az issue-kat általában milestone-okhoz rendeljük, és az issue-k készültségi állapota határozza meg a milestone készültségi állapotát.

A Label-ök (címkék) segítségével a különböző issue-kat tudjuk jellemezni, kategorizálni.

Milestone¶

Egy-egy mérföldkő a projekt fejlesztésének egy-egy jelentősebb állomása, amelyhez határidőt rendelhetünk. Fontos, hogy a mérföldkövet nem a határidő határozza meg, hanem a hozzárendelt feladatok, az állapotát, készültségi fokát pedig a hozzárendelt feladatok állapota.

Feladat: Példa projekt és mérföldkövek

Találjunk ki egy nagyobb (nem feltétlenül szoftverfejlesztési) projektet, majd határozzunk meg hozzá mérföldköveket!

Feladat: Milestone-ok létrehozása

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben hozd létre a következő mérföldkövet:

MS1: Saját GitLab projekt létrehozása (határidő: 2025-03-02)

Gyakorlatvezetői feladat: Mérföldkövek

Amíg a hallgatók elkészítik a saját projektjük első mérföldkövét, a gyakorlatvezető vigyen fel párat a megbeszélt mérföldkövek közül a gyakorlati csoport közös folyamatok nevű projektjéhez!

Issue¶

A projekt során elvégzendő ilyen-olyan fejlesztési feladatokat a GitLab-on (és hasonló eszközökben) issue-k formájában tudjuk dokumentálni. Egy-egy issue általában egy feladat (azért általában, mert egy issue felbontható több különálló alfeladatra, amelyeket további issue-kban tudunk megadni). Az issue-knak van egy rövid, de kifejező címe, és egy részletes leírása. Egy-egy issue-t általában mérföldkövekhez rendelünk (bár lehetnek olyan, már ismert de később megvalósítandó feladatok, amik egyelőre nincsenek mérföldkőhöz rendelve), és lehet saját határidejük (ami nem későbbi, mint a mérföldkövük határideje). Az issue hozzárendelhető személyekhez, ez történhet előre (speciális feladatok vagy lineáris fejlesztési modell esetén), vagy akkor, amikor valaki elkezd dolgozni az adott issue-n. Az issue-t elláthatjuk címkékkel is, ezzel jelezhető például egy-egy issue állapota.

Feladat: Példa projekt feladatok

A korábban kitalált projekt mérföldköveihez találjunk ki pár issue-t! Ezek után mindenki vigyen fel egy-egy issue-t a gyakorlati csoport közös folyamatok nevű projektjéhez, és rendelje is magához azt! Az issue-hoz adjunk egy rövidebb, 2-3 mondatos értelmes leírást is!

Feladat: Issue-k létrehozása

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben hozz létre egy issue-t arról, hogy létre kell hozni egy saját projektet! Az issue-t rendeld hozzá a korábban létrehozott MS1 mérföldkőhöz!

Label¶

A Label-ök (címkék) segítségével a különböző issue-kat tudjuk jellemezni, kategorizálni. Az issue-k tipikus jellemzői, amiket a GitLab-on címkékkel szokás jelölni:

State (állapot): Az issue állapota; pl. új, elkészítendő, fejlesztés alatt, tesztelés alatt, javítandó, ...
Priority (prioritás): Az issue (üzleti) fontossága; általában ötszintű skála, a P1 a legmagasabb, a P5 a legalacsonyabb
Severity (súlyosság): Az issue hatása a projektre; általában ötszintű skála a legmagasabb S1-től a legalacsonyabb S5-ig

Gyakorlatvezetői feladat: Címkék

A gyakorlatvezető készítsen a gyakorlati csoport közös folyamatok nevű projektjéhez egy To Do és egy Doing címkét!

Feladat: Label-ök létrehozása

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben hozz létre címkéket az issue-k állapotának kezelésére! (Készíts legalább egy To Do és egy Doing címkét!)

Fejlesztési projekt állapotának nyomonkövetése¶

Issue Board¶

A fejlesztés folyamatát, állapotát az Issue Board-ok segítségével követhetjük nyomon. A GitLab által nyújtott alapértelmezett board-on a nyitott (még nem kész) és zárt (kész vagy elutasított) issue-kat láthatjuk, de egy-egy táblán új listákat is megjeleníthetünk. Ezekhez a listákhoz az adott címkékkel ellátott issue-kat tudjuk hozzárendelni. Ezek után az adott címkével ellátott issue-k az adott listában fognak megjelenni. A listák között (elvileg) át tudunk mozgatni issue-kat, ilyen esetben a mozgatott issue-k címkéi a megfelelő módon frissülnek.

Gyakorlatvezetői feladat: Issue Board

A gyakorlatvezető a gyakorlati csoport közös folyamatok nevű projektjében egészítse ki az alap Issue Board-ot egy To Do és egy Doing listával!

Feladat: Példa projekt feladatok

Nézzük meg a gyakorlati csoport közös folyamatok nevű projektjében az Issue Board-ot! Most mindenki állítsa a be a saját issue-ját To Do állapotúra, és nézze meg megint a board-ot.

Projektmunka

A félév során mindenkinek kötelezően vezetnie kell a saját projektjének feladatait issue-k formájában. Vezetés alatt az adott feladat/hiba teljes életciklusát értjük, amely során a feladatokat mérföldkövekhez rendeljük, a korábban részletezett állapotokat folyamatosan megjelöljük, a feladat megoldásához tartozó commit-okat tag-eljük, a fellépő hibákat rögzítjük.

Mérföldkövek lezárása¶

Optimális esetben egy adott mérföldkő határidejére már minden hozzá tartozó issue állapota Closed, azaz a mérföldkőben vállalt összes feladat elvégzésre került. Ennek állapotát szintén nyomon lehet követni, vagyis a mérföldkövet ilyenkor le lehet zárni.

Mérföldkő lezárása

Többféle módszertan mást és mást mond arról, hogy egy mérföldkő mikor és hogyan zárható le, ha a határidő lejártakor még vannak hozzárendelt nyitott issue-k. Van, amikor a mérföldkő ilyenkor is lezárható (de a még nyitott issue nem), vagyis nem lesz 100%-ban teljesítve. Van, amikor a még nyitott issue-kat először át kell mozgatni egy másik mérföldkő alá, és az eredeti mérföldkő csak ekkor lesz lezárható. És olyan is akad, hogy a mérföldkő csak az összes issue lezárása (és ezzel együtt az eredetileg beállított határidő) után zárható le.

Markdown¶

A Git menedzselő szolgáltatások (pl. GitLab) és a Markdown jelölőnyelv között szoros kapcsolat van. Könnyen olvasható és könnyen írható sima szöveges formátum, amelyet a menedzselő szolgáltatások könnyen meg tudnak jeleníteni.

Talán a legtipikusabb megjelenési formátuma a README.md fájlok (a Markdown fájlok .md kiterjesztésűek). A README fájlokról bővebben a https://www.makeareadme.com/-on olvashatsz.

A Markdown szintaxisát összefoglaló dokumentáció a https://www.markdownguide.org/basic-syntax/ oldalon érhető el, táblázat készítéséhez pedig a https://www.tablesgenerator.com/markdown_tables oldalt ajánljuk.

Házi feladatok¶

Feladat: Milestone-ok létrehozása

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben hozd létre a következő mérföldköveket:

MS2: Projekt és tervezett funkciók kiválasztása és dokumentálása (határidő: 2025-03-16)
MS3: Tervezett funkciók megvalósítása (határidő: 2025-04-13)
MS4: Tesztelés, hibajavítás (határidő: 2025-04-20)
MS5: CI rendszer beüzemelése (határidő: 2025-05-11)
MS6: A projekt bemutatása a gyakorlatvezetőnek (határidő: az utolsó gyakoraltod napja a 2025-05-19-i héten)

Feladat: Issue-k létrehozása

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben hozz létre egy-egy issue-t a következőkről, és rendeld őket magadhoz, illetve a megfelelő mérföldkőhöz (ha van ilyen).

Gyakorlati projekt kiválasztása.
Fejlesztési feladatok kiválasztása a választott gyakorlati projekthez.
A projektfeladatok dokumentálása GitLab-on.

Feladat: Projekt állapotának nyomonkövetése

A Hallgatói Demonstrációs GitLab Szerveren a gyakorlati csoporthoz tartozó saját SDP25-hxxxxxx projektedben állítsd be az issue-k megfelelő állapotát (ha kell, zárd le őket). Készítsd fel az Issue Board-ot, hogy a címkéknek megfelelően láthasd a projekt állapotát! Ha van lezárható mérföldkő, zárd le azt is!

Gyakorlatvezetői feladat: Jogosultságok saját projektekhez

Ezen a ponton a gyakorlatvezetőnek is lesz egy feladata: a hallgatók által létrehozott projektekben (és nem a csoportban) át kell állítani a projektet létrehozó hallgató (és csak az Ő) jogosultsági szintjét OWNER-re. A feladatok nagy része DEVELOPER jogokkal is abszolválható, de van pár olyan hiba (például rossz projektnév, vagy több projekt létrehozása), aminek a javítása (projektnév megváltoztatás, projekt törlése) csak OWNER jogokkal lehetséges.

Feladat: Hibák javítása

Ha a projekt létrehozása során valamilyen hibát vétettél (rossz lett a neve, nem a csoport alatt hoztad létre vagy több projektet is csináltál), azt javítsd ki. Ha ehhez magasabb szintű jogok kellenek, kérd meg a gyakorlatvezetődet, hogy adjon ilyet (ha még nem tette meg). A projekt ilyen jellegű kezelésének funkcióit a Settings > General menüpont alól érheted el.

OWNER jogok

Ha a saját projektedben vannak hibák, de még nincsenek OWNER jogaid, akkor kérd meg a gyakorlatvezetődet, hogy adjon ilyen jogot, hogy kijavíthasd a hibákat!

A megnyíló General Settings oldal tetején van egy Naming, description, topics rész, amelyben át tudod írni a GitLab projekt nevét. Ez a GitLab-on módosítja a projekt nevét, de nincs hatása a projekt és a repository URL-jére. Ha a böngésző fejlécében az URL-ben SDP25-hxxxxxx van, de a projekt neve máshogyan, mondjuk SDP25 Hxxxxxx-ként jelenik meg, akkor itt kell módosítanod.

A General Settings oldal alján van egy Advanced rész, amelyben a következő műveleteket tudod elvégezni:

Git repository nevének (és URL-jének) módosítása: a Change path dobozkában át tudod írni a Path mező utolsó részét. Ha ez nem SPD25-hxxxxxx alakú, akkor itt tudod átírni. Ez meg fogja változtatni a GitLab projekt és a Git repository URL-jét is.
GitLab projekt csoportjának megváltoztatása: a Transfer Project dobozkában át tudod tenni a saját projektedet egy másik csoportba (aminek megfelelő jogosultságú tagja vagy). Egyszerűen a Select a new namespace legördülő menüben kiválasztod a megfelelő csoportot. Ha eredetileg nem jó csoportban, vagy saját namespace-ben hoztad létre a projektet (esetleg közben csoportot váltottál és még mindkét csoportban vannak megfelelő jogaid), akkor itt tudod átrakni a megfelelő helyre. Ez meg fogja változtatni a GitLab projekt és a Git repository URL-jét is.

Elképzelhető, hogy itt nem lesznek megfelelő jogaid (a "befogadó" csoportban lévő jogaid is számítanak), ez esetben kérd a gyakorlatvezetőd segítségét.

URL változtatás hatása

Ha már leklónoztad valahová a Git repository-t, akkor körültekintően kell bánni az URL (projektnév vagy csoport) megváltoztatásával, mert a klónozott repóban az eredeti URL fog szerepelni, amíg kézzel át nem írod. Vagyis, amíg át nem írod, nem leszel képes szinkronizálni a saját és a GitLab által kezelt repository-k között.

GitLab projekt és Git repository törlése: a Delete this project dobozkában. Ha véletlenül (vagy szándékosan, mert mondjuk az elsőt elrontottad és hirtelen csak így tudtad korrigálni) több projektet hoztál létre, a feleslegeseket itt tudod törölni.

Projekt/Repository törlése

Ha törlöd a projektet, a GitLab projekt véglegesen törlődik, nem lesz visszaállítható! Ha törlés előtt klónoztad a Git repository-t, akkor azt a saját verziódból természetesen vissza tudod állítani (ha ez nem volt szinkronban a GitLab-on lévő verzióval, így jártál), de a GitLab projekt többi adata mindenképpen elveszik!