Nástroje pre správu zdrojových kódov

Obsah práce

1.	Metodika vývoja softvéru
2.	Nástroje pre správu zdrojových kódov
3.	Implementácia nástrojov pre vývoj softvérového produktu

Systémy pre správu verzií

Systémy pre správu verzií (version control systems – VCS) patria do kategórie softvérových nástrojov, ktoré napomáhajú vývojárom spolupracovať a spracovávať zmeny v zdrojovom kóde počas celej doby vývoja. Takéto nástroje špeciálnymi spôsobmi sledujú a ukladajú každú zmenu kódu do určeného úložiska. Ak počas vývoja nastanú nečakané problémy s aktuálnou verziou projektu, každý člen tímu prepojený cez systém určený na správu verzií dokáže prehľadávať a porovnať predchádzajúce verzie kódu, čím sa dopomôže a častokrát docieli oprava chýb. Najväčšia výhoda týchto systémov je, že sa uchováva a ochraňuje vyvíjaný zdrojový kód programátorov pred ich chybami a taktiež inými vonkajšími vplyvmi.
Vývojári sa často delia na skupiny, kedy každá z nich sa zameriava na iné časti vývoja prípadne odstránenie chýb v už hotových častiach. V prípadoch kedy pracujú vývojári na rôznych častiach programu súčasne je vhodné použiť tzv. vetvenie (branching). Vytvorením vetiev sa udržiava nezávislosť viacerých skupín pracujúcich na rôznych úlohách súčasne. Vetvy sa po dokončení daných častí vývoja dokážu zlúčiť (merge) a tak umožňuje vývojárom overiť, či sa následkom zmien v jednotlivých vetvách nevytvorili problémy. Správne fungujúci softvér pre správu zdrojových kódov funguje na každej platforme a operačnom systéme, tým sa uľahčí práca programátorov, keďže nie je potrebné sa adaptovať na iné, častokrát neznáme prostredia.
Hlavnou úlohou očakávanou od systému pre správu verzií je kompletná a dlhodobá história každej vykonanej zmeny počas celej doby vývoja. Zmenou sa rozumie vytvorenie a vymazanie súborov a taktiež aj ich editácia osobou. Každá zmena vykonaná na projekte sa priradí jednotlivcovi, ktorý danú zmenu vykonal. Presne sa zobrazí teda podiel vývojárov a vývojových tímov na práci. História obsahuje údaje o autorovi, dátumu vytvorenia a písomné poznámky o účele každej vykonanej zmeny. Vďaka úplnej histórii sa vývojári dokážu vrátiť k predchádzajúcim verziám projektu na ktorom pracujú. Umožňuje to rýchlejšie a jednoduchšie odstránenie chýb a vytvorí sa celkový prehľad o projekte. V súčasnosti sú systémy pre správu verzií neoddeliteľnou súčasťou moderných softvérových tímov a vývojárov.

Z hľadiska architektúry poznáme dva druhy systémov pre správu verzií – distribuované a centrálne. Centrálna architektúra sa zakladá na jednom centrálnom repozitári, s ktorými sa klienti synchronizujú. Vývojári majú lokálne pracovné kópie nad ktorými vykonávajú zmeny tie posielajú do hlavného repozitára. Počas jeho prípadného výpadku sú uložené údaje a verzie nedostupné pre žiadneho z klientov. V prípade ak sa údaje v tomto repozitári stratia, môže to viesť k strate údajov a všetkých verzií.
Obr. 2.1 zobrazuje spojenie zariadení v centrálnej architektúre.

Obr. 2.1 Centrálna architektúra
Zdroj: [1]

Distribuovaná architektúra bráni výskytu podobných situácií. Udržiava kompletnú kópiu daného repozitára u každého z klientov (vývojárov). Tieto kópie sú plnohodnotné kópie obsahujúce všetok obsah, vrátane histórie. Ak teda nastane chyba v hlavnom repozitári, môže byť jeho úloha nahradená ktorýmkoľvek klientom. Mať k dispozícii celý obsah repozitára u každého z klientov má výhodu pri práci, keďže je možné prezerať históriu a zaznamenávať vykonané zmeny lokálne aj bez pripojenia na internet. V prípade ak niektorý vývojár vytvorí nechcenú chybu vo vyvíjanom kóde u ostatných sa to neprejaví, keďže každý pokračuje prácu na vlastnom lokálnom repozitári. Distribuovaná architektúra má množstvo ďalších výhod v porovnaní s centralizovanou.
Obr. 2.2 zobrazuje spojenie zariadení v distribuovanej architektúre.

Obr 2.2 Distribuovaná architektúra
Zdroj: [2]

Systém pre správu verzií CVS

CVS (Concurrent Versions System) je systém pre správu verzií. Používaním tohto systému sa vytvára história z vyvíjaného projektu. Vzniknú tzv. verzie, ktoré dokáže používateľ kedykoľvek prezerať a vrátiť sa k častiam vývoja. CVS vznikol v roku 1986, teda patrí k starším systémom. Z hľadiska architektúry je CVS centralizovaný, teda sa všetci klienti pripájajú na hlavný server, kde sa nachádza repozitár. Repozitár systému CVS v sebe ukladá kompletnú kópiu súborov a priečinkov. So súbormi sa pracuje lokálne u klienta v pracovnom repozitári, kde sa nachádza kópia celého repozitára. Pri vykonaní zmien vo vybraných súboroch, teda nie vo všetkých súboroch v pracovnom priečinku, CVS ukladá do repozitára len súbory na ktorých sa vykonala istá zmena. CVS umožňuje vytváranie a spájanie vetiev, teda odbočenie od hlavnej línii vývoja. Tento proces je však v porovnaní so systémom Git zložitý.

Systém pre správu verzií Git

Git je softvér šírený pod licenciou GNU/GPLv2 používaný pre správu verzií. V súčasnosti je jeden z najpoužívanejších v oblasti. Git patrí do skupiny systémov pre správu verzií s distribuovanou architektúrou.
História systému Git sa viaže k roku 2005, kedy ho vytvorila skupina vývojárov na čele z hlavným vývojárom Linusom Torvaldsom, ktorý stojí za vytvorením aj známeho jadra (kernelu) systému GNU/Linux. GNU/Linux kernel bol pôvodne vyvíjaný za pomoci systému pre správu verzií nazývaný Bitkeeper, s ktorou však v roku 2005 vývojári GNU/Linux kernelu prestali spolupracovať. Rozhodli sa teda vytvoriť si svoj vlastný systém pre manažovanie zdrojových kódov jadra GNU/Linux . Pri vývoji sa zameriavali na rýchlosť systému, vytvorenie jednoduchého rozhrania a širokú možnosť vetvenia. Dôležitosť sa kládlo na schopnosť dokonalo pracovať s veľkými projektmi (veľké množstvo dát), čoho je dôkazom aj samotné jadro Linux-u.
Git funguje a pracuje s informáciami rozličným spôsobom ako to robia iné softvéry na správu verzií. Z konceptuálneho hľadiska väčšina systémov ukladá celé súbory pri každej vykonanej zmene. Na rozdiel od ostatných, Git pri každej zmene vykonanej v súboroch ukladá tzv. snímky (snapshoty). Ak sa vytvára záznam (commit) novej verzie súborov Git vytvorí snímku súborov v danom okamihu a uloží referenciu na túto snímku. Z dôvodu efektívnosti Git neukladá súbory na ktorých sa nevykonali žiadne zmeny, len odkáže na poslednú identickú verziu daných súborov. Okrem toho Git ukladá súbory binárne, dokáže teda spracovávať aj netextové súbory ako napríklad obrázky.
Takmer všetky operácie pri práci s Git sú lokálne. Väčšina operácií v systéme Git si postačí pri svojej činnosti s lokálnymi súbormi bez potreby kontaktovať iné počítače či serveri v sieti. To umožní systému takmer okamžitú odozvu pri práci. Na rozdiel od systémov s centrálnou architektúrou, kde sú všetky súbory dostupné po sieti, je prítomné určité oneskorenie. Celá história repozitára, teda priečinka s projektom pod správou systému Git, je dostupná lokálne. Úpravy a prezeranie údajov je teda možné vykonať bez pripojenia na web. V podstate je systém Git plne použiteľný v prípade, ak je jediná kópia repozitára dostupné lokálne u klienta. Pripojenie na internet potrebuje len v prípade ak ide používateľ publikovať prípadne pri získaní novej verzii repozitára. Git všeobecne len pridáva dáta. Môže sa zo súboru vymazať riadok, Git dostane informáciu len o pridaní zmeny v súbore.
Vlastnosťou systému Git je úplnú integrita uložených dát. Všetky zmeny v repozitári sú overené kontrolným súčtom. Každá potvrdená zmena je identifikovateľná týmto kontrolným súčtom. Používa sa kontrolný súčet typu SHA-1. Vďaka zabezpečeniu pomocou kontrolnému súčtu SHA-1 je obsah súborov, záznamov, jednotlivých verzií aj histórie, chránený pred škodlivými aj náhodnými nechcenými zmenami. Je to 40-miestny reťazec zložený z hexadecimálnych znakov (0-9 a A-F) a vypočítaný je na základe obsahu súboru. Git interne neukladá súbory podľa mena, ale práve podľa vygenerovaného kontrolného súčtu. Dôležité pre prácu so systémom Git je porozumenie jeho rozdeleniu na tri základné stavy dát, ktoré systém používa pri práci so spracovanými súbormi:

• Zmenené súbory (modified)– vykonali sa zmeny na súbore v pracovnom adresári, avšak zmeny neboli zaznamenané do repozitára.
• Pripravené (staged) – presunuté dáta do prípravnej oblasti (staging area), ktoré sú následne pripravené na záznam (commit) ako nová verzia.
• Zaznamenané (commited) – dáta, ktoré sú uložené v lokálnej databáze repozitára.

Obr. 2.3 Tri stavy pri práci s Git
Zdroj: [3]

Obr. 2.3 opisuje tri stavy medzi ktorými so súbormi pracuje. V pracovnom priečinku sa nachádzajú súbory získané z git repozitára. Získané súbory sa v pracovnom priečinku upravujú, mažú prípadne pridávajú. Vybrané zmenené súbory sa posunú do prípravnej oblasti. Z tejto oblasti sa vytvorené snímky permanentne uložia do Git priečinka. Lokálny priečinok systému Git sa skladá zo súborov, ktoré sa ukladajú pri prvotnom kopírovaní (clone) vzdialeného repozitára.
Existuje viacero spôsobov ako pracovať so systémom Git. Dá sa využívať pomocou príkazov, ktoré sa zadávajú do terminálu (príkazového riadku) operačného systému. Ďalší spôsob používania je cez grafické používateľské rozhranie vytvorené na tento účel. Pri použití príkazového riadku nie sú žiadne obmedzenia týkajúce sa funkcionality a použiteľných príkazov. Väčšina grafických rozhraní implementuje iba čiastočnú podmnožinu funkcií a príkazov systému Git pre zjednodušenie.
Hlavné výhody systému Git:
Systém Git je najrozšírenejší a najmodernejší systém pre správu verzií v súčasnosti. Okrem hlavnej výhody spočívajúcej sa v distribuovanej architektúre, je git veľmi výkonný, rýchly a bezpečný systém. Je kompatibilný s obrovským množstvom existujúcich systémov a protokolov, tým pádom ponúka širokú kompatibilitu pre každého používateľa. Pri vytvorení systému Git brali vývojári veľký ohľad na sprístupnenie a zjednodušenie vetvenia v systéme. Preto je jedna z najväčších výhod systému Git práve jeho možnosti vetvenia. Viaceré predchádzajúce systémy na správu verzií možnosť vetvenia ponúkali, avšak vo veľmi komplikovanom a neprehľadnom tvare. Vetva predstavuje odbočenie od hlavnej línie vývoja repozitára. Pri založení projektu Git automaticky vytvorí hlavnú vývojovú vetvu s názvom master. Každá ďalšia vytvorená vetva je presnou kópiou tej hlavnej v čase, kedy bola vytvorená. Každá vykonaná zmena na vetve je od hlavnej vetvy nezávislá až do momentu kedy sa vetvy znova spoja do jednej hlavnej.

Vytvorená vetva systému Git je ukazovateľ (pointer) na záznamy (commits), teda nevytvára sa nová kópia súborov a priečinkov. Hlavný ukazovateľ je teda master, ktorý ukazuje na poslednú zaznamenanú zmenu v repozitári.

Obr. 2.4 Repozitár s jednou vytvorenou vetvou s názvom Vetva
Zdroj: [4]

Na Obr. 2.4 bola vytvorená jedna vedľajšia vetva okrem hlavnej, avšak stále sa nachádzame na hlavnej vetve s názvom master. Git rozpoznáva na ktorej vetve sa momentálne používateľ nachádza pomocou ďalšieho pointra s názvom Head. Ten ukazuje vždy na vetvu na ktorej používateľ aktuálne pracuje. Teda v prípade ak sa nepreplo na vedľajšiu vetvu, tak pointer Head ukazuje na vetvu Master. Po presunutí na vetvu s názvom Vetva sa môže pracovať na nezávislej línii. Je to výhodné ak si jeden z vývojárov pracujúcich na projekte potrebuje vykonať zmenu v kóde a v súboroch, bez toho aby ovplyvňoval prácu ostatných. Po zaznamenaní zmien vetva pokračuje vo vývoji (Obr. 125) až dovtedy, kým ju vývojár nezmaže alebo nespojí s inou vetvou.

Obr. 2.5 Repozitár s jednou vetvou (Vetva) po vytvorení záznamov
Zdroj: [5]

Git sa ovláda základnými príkazmi cez terminál prostredia. Základné príkazy sú opísané v oficiálnej dokumentácii o systému Git .

Založenie nového repozitára služby Git:

    git init

Vytvoriť repozitár sa odporúča do existujúceho pracovného priečinka. Po presmerovaní do daného priečinka príkazom git init sa vytvára nový lokálny repozitár služby git. V tomto stave sa vykonávajú zmeny len lokálne na zariadení používateľa.

Získanie lokálnej kópii existujúceho repozitára:
V prípade, kedy je už repozitár vytvorený a zmeny sú zaznamenané do online repozitára, Git dovoľuje vytvorenie kópie existujúceho vzdialeného repozitára. Po presmerovaní do požadovaného adresára kde bude pracovná kópia vzdialeného repozitára sa príkazom:

    git clone <URL repozitara>

spustí klonovanie (vytváranie kópie) vzdialeného repozitára. URL je vo formáte HTTP/HTTPS alebo SSH a získava sa priamo z web rozhrania existujúceho repozitára. Po naštudovaní ďalších možností Git dovoľuje kopírovanie len zvolených častí repozitára. Jedným príkladom je klonovanie zvolenej vetvy, kedy sa príkaz zmení na:

    git clone -branch <nazov vetvy>

Výpis súborov na ktorých sa vykonala zmena:

    git status

Zoznam súborov na ktorých bola vykonaná zmena a neboli pridané do prípravnej oblasti (add) a neboli zaznamenané (commit) sa zobrazí príkazom git status.

Priradenie súborov do prípravnej oblasti:
Pridanie súborov do prípravnej oblasti sa realizuje príkazom:

    git add

Súbory sa pridávajú hromadne pomocou príkazu:

    git add -A

a pre presunutie len vybraných súborov sa príkaz využíva v tvare:

    git add <nazov suboru>

Záznam zmien do repozitára:

    git commit

Ak sú zvolené vykonané zmeny v prípravnej oblasti, samotný záznam vykonáva príkaz git commit. Pre priradenie popisu k záznamu je potrebné použiť príkaz v tvare:

    git commit -m <popis zaznamu>

Nový repozitár je vytvorený fyzicky až pri prvom zázname.
Nahranie zmien do vzdialeného repozitára:

    git push

Odoslanie zaznamenaných zmien lokálneho repozitára do vzdialeného (online) sa realizuje pomocou git push príkazu a jeho variáciami. Pre odoslanie zmien do hlavnej vetvy master sa použije príkaz v základnom tvare, prípadne pomocou príkazu:

    git push origin master

kde origin je premenná s hodnotou adresy ktorá sa použila pri git clone a master značí názov vetvy do ktorej sa zmeny odosielajú. Hlavná vetva má automaticky pridelený názov master. V prípade kedy je potrebné zmeny odoslať do inej ako hlavnej vetvy, sa jednoducho vetva master nahradí názvom zvolenej vetvy.

Vytvorenie vetvy:
Vetvenie, teda odbočenie od hlavnej línie vývoja, je dôležitou funkciou systémov pre správu verzií. Vetvenie podporujú takmer všetky systémy. Nie je to však jednoduchý proces, niektoré softvéri vyžadujú vytvorenie novej kópie adresára so zdrojovým kódom, čo je pri veľkých projektoch časovo neefektívne. Vytváranie vetiev v systéme git je jednoduché, keďže neukladá dáta ako sériu zmien, ale ako sériu snímok. Ak sa v súboroch vykonajú zmeny a zapíšu sa (commit), potom ďalší zápis uloží ukazovateľ na predchádzajúci zápis. Vetva v systéme Git je premiestniteľný ukazovateľ na jeden zo záznamov. Postupným vytváraním záznamov sa vetva master posúva s novými verziami. Vytváranie novej vetvy sa koná príkazom:

    git checkout -b <nazov vetvy>

Vytvorí sa tak nová vetva a automaticky nás systém na vytvorenú vetvu presunie. Ďalším spôsobom vytvorenia vetvy je príkazom:

    git branch <nazov vetvy>

avšak tento príkaz vetvu len vytvorí a nepresunie nás na ňu. Prepnutie na zvolenú existujúcu vetvu sa vykonáva príkazom:

    git checkout <nazov vetvy>

Vetva má v sebe vo východzom stave rovnaké súbory a informácie ako hlavná línia. Použitím git branch príkazu sa vypíšu všetky existujúce vetvy repozitára.
Git sleduje vetvu, na ktorej sa momentálne nachádza používateľ pomocou ukazovateľa nazývaného HEAD. Pridaním nového záznamu v tejto vetve sa vytvorí záznam len na zvolenej vetve, pričom pôvodná vetva master ukazuje stále na predošlý záznam. Teda zmeny vykonané v novej vetve sa neviažu na hlavnú vetvu (master). Odstránenie vetvy sa vykoná:

    git branch -d <nazov vetvy>

Spojenie vetiev do jednej:
Spájanie vedľajších vetiev medzi sebou, prípadne spájanie do hlavnej sa realizuje príkazom:

    git merge
    git merge <nazov vetvy>

kde druhá možnosť s označenou vetvou slúži pre zlúčenie označenej vetvy s aktívnou, teda práve využívanou.

Vyzdvihnutie nových verzií vzdialeného repozitára:
Pre vyzdvihnutie nových dát zo vzdialeného repozitára, ktoré sa ešte nenachádzajú na lokálnom slúžia dva príkazy:

    git fetch
    git pull

Bezpečnejšie je využívanie príkazu git fetch, pretože vzdialený obsah stiahne, ale neaktualizuje sa stav miestneho pracovného priečinka. Príkaz fetch nevykoná automatické zlúčenie s rozpracovanou prácou. Zlúčenie je treba robiť ručne pomocou príkazu git merge.
Príkaz git pull načíta všetky zmeny zo vzdialeného repozitára používateľa. Tento príkaz je teda kombináciou dvoch príkazov a to git fetch a následne git merge.

Odloženie zmien bez zaznamenania:
Ak vykonal používateľ zmeny na svojej pracovnej kópii projektu a nechce tieto zmeny zaznamenať do repozitára, príkaz:

    git stash

umožňuje tieto zmeny uložiť (odložiť) bez zaznamenania do repozitára. Odložená práca pomocou git stash sa ďalej nezobrazí, teda je možné pokračovať prácu na inej časti, prípadne si stiahnuť (pull) nové zmeny z repozitára, bez straty predošlých zmien. V prípade kedy chce používateľ zmeny odložené príkazom stash vrátiť do repozitára použije príkaz:

    git stash apply

Zahodiť nepotrebné odložené záznamy sa realizuje pridaním časti príkazu

    git stash drop

Nástroje/služby pre prácu s Git

Nástroje pre prácu s Git vytvárajú isté grafické prostredie pre Git repozitár. Práca so súbormi umiestnené v repozitári je odlišná ako pri práci s Git cez terminál. Navigácia a práca nie je vykonaná príkazmi, avšak používatelia služieb na prácu používajú lokálne pracovné kópie repozitára, kde sa práca vykonáva klasickým spôsobom, teda príkazmi. Najdôležitejšia úloha služieb zobrazujúce Git repozitár je zjednodušená spolupráca medzi vývojármi. Taktiež služby zaznamenávajú a zobrazujú užitočné informácie o súboroch, používateľoch a taktiež vývojároch. Dokonale sledujú každú zmenu v repozitári. Dokážu využívať nástroje softvérového inžinierstva, čo je dôležitá funkcia z hľadiska užitočnosti. Najznámejšie služby pre prácu s Git sú: GitLab, GitHub, Bitbucket, Gogs a mnoho ďalších. Väčšina služieb má podobné vlastnosti, avšak niektoré majú funkcie navyše, ktoré iné neposkytujú. V ďalších častiach práce sú opísané web rozhrania pre prácu s git, ktoré počas realizácie práce využijeme. Zameriame sa hlavne na rozhrania Gogs a Gitlab.

Nástroj pre prácu s Git - Gogs

Gogs (Go Git Service) je jeden z najjednoduchších služieb pre prácu s nástrojom pre správu verzií Git, šírený pod licenciou MIT. Gogs funguje ako aplikačný web server, ktorý je možné nainštalovať na vlastný server (táto vlastnosť sa označuje ako self-hosting). Je vyvinutý v programovacom jazyku Go, čo docieli použiteľnosť takmer na každej platforme a dokonca, na dnešné pomery, veľmi slabom hardvéri. Pre používanie služby Gogs postačí aj zariadenie so slabšími komponentmi ako je napríklad cenovo dostupný mini počítač Raspberry Pi. Pre tímovú prácu sa predpokladá použitie zariadenia s aspoň 512MB RAM pamäťou a s dvojjadrovým procesorom.
Gogs má užitočné funkcie využívané vývojármi. Vytvára harmonogram aktivít, kde môžu vývojári kontrolovať svoje vykonané záznamy do repozitára, zoznam vytvorených vetiev a tiež vypustené (released) verzie projektu. Na získanie lokálnej kópie repozitára (clone) ponúka Gogs protokoly SSH a HTTP/HTTPS. Zabezpečená vrstva SSH zaisťuje bezpečné spojenie medzi jednotlivými vzdialenými stranami.

Gogs ponúka užitočnú funkciu softvérového inžinierstva nazývaný Issues (zoznam problémov). Issues implementuje možnosti nástroja Kanban Board, ktorý usporadúva úlohy súvisiace s vývojom softvéru do zoznamov so zodpovedajúcimi názvami a farebnými označeniami. Ponúka tak spôsob ako sebe a tímu spojeného cez repozitár zadeliť úlohy. Issues sú v samej podstate úlohy vytvorené vývojármi, na ktorých je potrebné pracovať. Môže obsahovať úlohy napríklad na pridanie novej funkcie, odstránenie zistenej chyby z vyvíjaného projektu a mnohé ďalšie, ktoré vývojári potrebujú vyriešiť. Jednotlivé Issues majú pri vytvorení pridelený názov a krátky popis, ktorým sa objasní obsah úlohy. Využívané sú aj tzv. farebné štítky, ktoré napomáhajú zakategorizovať a filtrovať úlohy. Míľniky (milestones) sú tiež medzi funkciou Issues. Udávajú hlavné znaky spojené s úlohou. Issues majú aj dostupný priestor pre komentáre, kde sa každý vývojár s prístupom do repozitára môže vyjadriť k úlohám. Služba Gogs ponúka používateľom aj jednoduché nastavenia svojich účtov.

Obr. 2.6 Repozitár vo web rozhraní Gogs

Na Obr. 2.6 je zobrazený repozitár web rozhrania Gogs. V hornej časti okna sa vždy zobrazí názov aktuálneho projektu s menom používateľa. Nižšie umožňuje prostredie prezerať rôzne jeho funkcie ako sú Issues prípadne zobraziť predošlé záznamy a prepnúť na inú vetvu. V tomto repozitári boli zaznamenané súbory, ktoré sa zobrazia v spodnej časti okna s krátkym popisom záznamov (ako napr. "Pridal c++ hello") a údaje o čase zaznamenaní súborov do vzdialeného repozitára.

Nástroj pre prácu s Git - Gitlab

Gitlab je softvér šírený pod licenciou MIT, ktorá umožňuje vzdialený prístup k repozitárom systému pre správu verzií Git. Je to rozsiahla služba, ktorá umožňuje používateľom využívať množstvo jeho zabudovaných funkcií pre správny vývoj softvéru. Okrem základných operácií s Git repozitárom ako je vetvenie a spájanie ponúka aj ďalšie užitočné možnosti a uľahčenia pre vývojárov softvéru. Práve komplexnosť a množstvo funkcií radí Gitlab medzi najpoužívanejšie a najkvalitnejšie služby pre správu verzií. Medzi hlavné funkcie patria: spolupráca vývojárov a vývojového tímu, kontrola verzií vyvíjaného kódu, Issue Board, DevOps, CI/CD a ďalšie. Poskytovaná je cez web rozhranie, kedy je služba dostupná online a taktiež je možné službu nainštalovať na vlastnom hardvéri, čím umožňuje vytvárať privátne repozitáre. V porovnaní však so službou Gogs je Gitlab náročnejší na použité hardvérové komponenty, čo je zapríčinené komplexnosťou služby. Pre manipuláciu s repozitárom a súbormi daného projektu cez terminál sa používajú všetky dostupné príkazy systému pre správu verzií Git ako je napr.: git clone, git push, git commit, git merge atď. Rovnako ako iné služby, aj Gitlab ponúka získanie lokálnej kópie repozitára pomocou protokolov HTTP/HTTPS a SSH.
Pre stiahnutie obsahu repozitára môžu používatelia použiť aj formát zip prípadne tar, kedy sa web rozhranie postará o zabalenie obsahu do spomínaných formátov a tým je možný prístup aj pre používateľov bez použitia služby git.
Pre používateľov Gitlab umožňuje vytvorenie jedinečných účtov a následnú prácu so svojimi pracovnými priečinkami, prípadne po spojení do vývojárskeho tímu aj s pracovnými repozitármi iných vývojárov. Jednotlivý používatelia majú v zdieľanom projekte rôzne práva prístupu k funkciám a manipulácie so súbormi. Používateľom (vývojárom pre daný projekt) umožňuje Gitlab pridelenie rôznej úrovne prístupu. Prvá úroveň je Hosť (Guest), ktorým dostanú základné prístupové právo k verejnému obsahu repozitára a taktiež im umožní pridávať komentáre a issues. Ďalší v poradí používateľov s právami je tzv. Reporter. Používatelia s týmto prístupovým právom dokážu okrem rovnakých postupov aké má Guest aj prezerať súbory a stiahnuť si repozitár (clone). Ďalšie právo majú pridelené vývojári, ktorý na projekte pracujú - právo Developer, teda vývojár má okrem predošlých práv možnosť plným nasadením sa podieľať na práce s projektom, teda vytvárať a pridávať súbory a zdrojové kódy, vytvárať a spájať vetvy, pridávať tagy a míľniky a ďalšie. Hlavným používateľským právom v Gitlabe je vlastník projektu (Owner), tým sa stáva používateľ, ktorý projekt vytvoril. Vlastník dokáže vykonávať akúkoľvek operáciu súvisiacu s daným projektom a práve vlastník projektu udeľuje vymenované práva ostatným používateľom a vývojárom. Vlastník vytvára repozitár verejný (public) alebo súkromný (private).

Obr 2.7 Repozitár vo web rozhraní Gitlab

Ukážka repozitára vo web rozhraní Gitlab zobrazuje Obr. 2.7. Po presunutí do projektu Gitlab sa v ľavej časti rozhrania zobrazia okná, pomocou ktorých je umožnená orientácia v prostredí projektu. V strede okna sa zobrazia súbory uložené v projekte a základné údaje o záznamoch.

Nástroje softvérového inžinierstva - CI/CD

CI a CD sú skratky pre nástroje softvérového inžinierstva, ktoré boli vytvorené za účelom zavedenia automatizácie do fáz vývoja softvérových projektov. Pred využívaním automatizačných nástrojov boli vývojári odkázaní na manuálne vykonávanie procesov počas vývoja softvéru. Hotové časti programu boli spustené a odoslané na testovanie. Testovanie bolo vykonávané manuálne tímom určeným na zistenie prípadných nedostatkov vo fungovaní. Tento proces bol časovo náročný a často neefektívny v procese overovania správnej funkčnosti, čo spôsobovalo dlhšie dodacie doby hotového výrobku.
Continuous integration (CI) predstavuje v preklade nepretržitú integráciu. Hlavným cieľom tohto procesu je uľahčenie prípravy a vydania softvéru. Pomocou CI sa vytvára automatizovaný proces, ktorý dokáže spustiť a otestovať vyvíjaný projekt pri každej zmene. Uľahčí a urýchli sa tak celkový proces vývoja. Ak sa vykoná zmena v kóde, automaticky sú overené automatickým spustením a následným vykonaním testov na jednotlivých častiach kódu, prípadne aj ako celok. Zaistí sa tým, že vykonané zmeny neporušili funkčnosť a správne fungovanie projektu.
Ďalej je CI nesmierne užitočný pri používaní vetiev, teda pri súčasnej práci na rôznych častiach kódu rôznymi vývojármi. Odporúčané je využívať nástroj CI na každej vetve. Tým sa skontroluje funkčnosť každej vetvy jednotlivo pred ich spojením. Rozdelené vetvy je potom jednoduchšie spájať do hlavnej vetvy.
CD odkazuje na anglické výrazy continuous delivery a continuous deployment. Continuous delivery je rozšírením CI, ktorý zaisťuje publikovanie (release) novej verzie softvéru do repozitára. Takže popri automatickom testovaní zacieleným pomocou CI, je vytvorená aj automatizácia procesu uvoľnenia. Výsledkom continuous delivery je softvér, ktorý je možné kedykoľvek vypustiť do produkcie. Continuous deployment je poslednou fázou pri procese automatizácie nasadenia projektu. Tento proces je rozšírením procesu continuous delivery, ktorý pripravil vyvíjaný softvér do fázy kedy je pripravený na nasadenie do produkcie. Continuous deployment vytvára automatický proces nasadenia projektu na trh. Pomocou správne nakonfigurovaného nástroja je vypustený produkt schopný pracovať v priebehu pár minút. Na vytvorenie automatizovaného CI/CD nástroja sa používa takzvaný CI/CD pipeline. Význam výrazu pipeline je nasledovný: vykonávajú sa automatizované procesy vývoja ako spustenie kódu, beh testov a nasadenie projektu (Obr. 2.8).

Obr. 2.8 Automatizácia pomocou CI/CD pipeline
Zdroj: [6]

Nástroj pre vytváranie CI/CD pipeline - Jenkins

Jenkins je nástroj používaný za účelom vytvárania CI/CD pipelinov, šírený pod licenciou MIT. Je vytvorený v programovacom jazyku Java a patrí medzi najpopulárnejšie nástroje súčasnosti používané v praxi. Pomocou nástroja Jenkins dokážu vývojári využívať automatizované procesy počas celej doby vývoja softvéru. Používa sa na spustenie a otestovanie softvérových projektov, čím sa uľahčí manuálna práca vývojárov. Prostredníctvom tohto nástroja sa urýchli proces vývoja softvéru pomocou automatizovaných procesov. Jenkins dosahuje dokonalú funkčnosť ako nástroj pre CI/CD pomocou tzv. Pluginov (rozšírení). Pluginy slúžia na prepojenie a využívanie iných služieb v automatizovanom procese nástroja Jenkins. V súčasnosti Jenkins podporuje veľké množstvo pluginov pre integráciu ďalších služieb za účelom úspešného vývoja, testovania a nasadenia projektov.
Použitie Jenkinsu s nástrojom pre správu verzií Git je efektívny spôsob ako otestovať každý záznam v repozitári. Nasledovný vývojový diagram znázorňuje príklad využitia Jenkinsu s pomocou Git repozitára:

Obr 2.9 Príklad vývojového diagramu procesov nástroja Jenkins
Zdroj: [7]

Pri použití nástroja Jenkins v spojení s Git repozitárom je proces automatizácie CI/CD zobrazený na Obr. 2.9. Vývojár vykoná zmenu v zdrojovom kóde softvéru, ktorý vyvíja. Zmeny zaznamená do repozitára služby Git. Nástroj Jenkins sleduje tento repozitár podľa nakonfigurovania v istých časových intervaloch, prípadne čaká na záznam od vývojára, na ktorý zareaguje. Akonáhle Jenkins zaznamená vykonanú zmenu v repozitári, pripraví sa na vykonanie automatizovaného procesu, ktorý je nakonfigurovaný používateľom. V príklade uvedenom na obrázku Jenkins si prevezme zmeny z repozitári a spustí ich. V prípade ak sa spustenie nepodarí, vývojár ktorý zmenu vykonal je upozornený. Upozornenie môže byť nakonfigurované napríklad prostredníctvom e-mail správy. Ak spustenie prebehne v poriadku, Jenkins ho presunie na testovaciu fázu. Počas testov vykoná záznamy a po dokončení overovania oznámi vývojárovi získané výsledky.
Jenkins počas celej doby vývoja pokračuje v pozorovaní repozitára a pri každej vykonanej zmene sa proces opakuje. Jenkins používa tzv. Master-Slave (riadiaci a podriadený) architektúru na správu distribuovaných buildov. V takejto architektúre sa komunikuje pomocou TCP/IP protokolu. Riadiaci (Master) je vždy hlavý server na ktorom je nástroj Jenkins nakonfigurovaný. Jeho úlohou je sledovanie záznamov v repozitári, plánovanie buildov a tiež priradenie buildov pre podriadených (slaves) na skutočné vykonanie. Master dokáže vykonávať spustenie programov aj samostatne. Tiež sleduje podriadených a zaznamenáva výsledky jednotlivých buildov. Podriadený (slave) je vzdialené zariadenie, môže fungovať s rôznymi operačnými systémami. Podriadení vykonávajú všetky úlohy zadané riadiacim systémom Jenkinsu. Podriadení môžu byť využívaní napr. na testovanie projektu na rôznych operačných systémoch. Podriadené zariadenia používajú rôzne prostredia a otestuje sa funkčnosť na všetkých z nich.
Kľúčovou funkciou Jenkins pipeline-ov je možnosť definovať kroky nasadenia prostredníctvom kódu. Jednotlivé kroky sú tak manuálne nastavené pomocou skriptu, ktorý je možné ukladať priamo v repozitári služby na správu verzií, ako je napr. Git. Namiesto vytvorenia viacerých prác na vykonanie každej fázy po jednom, dokáže vývojár nakódovať celý postup naraz v jednom súbore nazývaný Jenkinsfile. Jenkinsfile je textový súbor, ktorý je automaticky vyvolaný z repozitára a určuje úlohy, ktoré sa vykonajú. Hlavným blokom súboru Jenkinsfile je blok pipeline. Obsahuje všetky procesy, ktoré potrebuje vývojár, aby boli vykonané počas automatizovanom procese nasadenia. Jednotlivé procesy sa definujú do fáz, teda Stages. Vo vnútri fáz sa definujú kroky Steps. Kroky sa vykonávajú postupne až do dokončenia fázy. Jenkinsfile obsahuje ešte údaj nazývaný Agent s priradeným parametrom. Agent je z pravidla zariadenie, ktoré je pripojené k Jenkins.
Agent môže mať parameter Any (ktorýkoľvek), kedy vykoná Jenkins každú fázu na ktoromkoľvek pripojenom zariadení (agente). Pre vykonanie fáz len na zvolených agentoch sa používa parameter label, kedy sa vykoná len na správne nazvaných agentoch.

Nasledujúci príklad zobrazuje syntax JenkinsFile s troma krokmi:

pipeline {
   agent any
   stages {
      stage('Krok 1 - Spustenie') {
         steps {    ...
         }
      }
      stage('Krok 2 - Test') {
         steps {    ...
         }
      }
      stage('Krok 3 - Nasadenie') {
         steps {    ...
         }
      } 
   }
}

Nástroj pre vytváranie CI/CD pipeline - Gitlab CI/CD

Gitlab Runner je open source projekt, ktorý sa používa na spúšťanie projektov a vyvíjaných zdrojových kódov a následné zobrazenie výsledkov v prostredí Gitlabu. Gitlab Runner sa používa v spojení s Gitlab CI t.j. open source službou pre Continous Integration a Continout Deployment, ktorá je súčasťou samotného nástroja pre správu verzií Gitlab. Gitlab Runner, ktorým sa Gitlab CI pripája k pracovnému repozitáru, je napísaný v jazyku Go a je voľne šíriteľný na operačných systémoch GNU/Linux, macOS a Windows. Taktiež sa dá spustiť samostatne ako Docker kontajner.
Po inštalácii Gitlab Runnera je potrebné ho spojiť so samotným Gitlab repozitárom, pre vzájomnú spoluprácu nástrojov. Gitlab runner má implementovaných viacero executorov ako Shell, Docker, SSH a použiteľných v rôznych prípadoch. Executor Shell dokáže použiť skripty vytvorené pre rozhranie terminálu všetky systémy pre ktoré je Gitlab Runner dostupný, teda Bash v prípade operačného systému GNU/Linux a Windows Powershell. Gitlab Runner dokáže využiť Docker image pre spustenie skriptu, pomocou executora s názvom Docker. Pri použití Gitlab CI v spojení s Docker executorom sa udáva docker image, ktorý si runner prevezme a pomocou neho vykoná zadané inštrukcie. Executor SSH sa používa na vzdialený prístup Runnera k repozitáru pomocou príkazov cez SSH.
Gitlab CI pipeline skript je nakonfigurovaný pomocou YAML súboru s názvom .gitlab-ci.yml a je uložený v repozitároch služby Gitlab v ktorých je runner zaregistrovaný. Gitlab CI spúšťa YAML skript automaticky pri každej pridanej zmene (git push) a zlučovaní vetiev do hlavnej vetvy (git merge).