Implementácia nástrojov pre vývoj softvérového produktu

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

Po naštudovaní a osvojení všetkých potrebných teoretických informácií sme pristúpili k praktickému spracovaniu našej práce. V tejto kapitole sú opísané postupy, ktorými sme vykonali praktické overenie ponúkaných možností jednotlivých systémov a nástrojov pre podporu vývoja softvérov ako sú nástroje pre správu zdrojových kódov a nástroje pre CI/CD. Cieľom praktickej časti práce bolo nasadiť dané nástroje pri vývoji softvérov a iných zdrojových kódov a zabezpečiť správne fungovanie nakonfigurovaním menovaných nástrojov softvérového inžinierstva. Nástroje CI/CD boli reálne spojené s repozitármi služby Gitlab, pomocou ktorého sme vykonali reálne nasadenie aktualizácií web rozhrania, ktoré pracuje zo serveru umiestneného na Ústave aplikovanej informatiky, automatizácie a mechatroniky MTF STU. Tento server je v správe vedúceho bakalárskeho projektu. Adresa servera je gitlab.nsoric.com a primárne obsahuje zdrojové kódy študentov, ktoré sú súčasťou riešení bakalárskych a diplomových prác.

Inštalácia a konfigurácia služby pre správu verzií Git

Pred začatím používania služby Git, si ju používatelia musia zaobstarať do zariadenia s ktorým budú službu využívať. Inštaláciu Git je možné previesť rôznymi spôsobmi v závislosti od operačného systému zariadenia. Najjednoduchším spôsobom je inštalácia pomocou preferovaného správcu inštalačných balíkov danej distribúcie operačného systému. Na oficiálnej stránke prevádzkovateľa služby nájdeme príkazy na stiahnutie a tiež inštalačné balíky služby na každú dostupnú platformu ako sú Windows, Mac OS a Linux distribúcie. V našom prípade sme použili na inštaláciu balík pre distribúciu Linux pre zariadenie s OS Linux Mint. Stiahnutie a inštalácia prebehla zadaním príkazu do terminálu:

    apt-get install git

Pre odskúšanie sme previedli inštaláciu aj na platforme OS Windows, kde prebehla inštalácia cez inštalačný balík dostupný na spomínanej web-stránke poskytovateľa služby. Pre prípad kedy je už služba nainštalovaná a beží na zariadeniach, je vhodné službu aktualizovať v pravidelných časových intervaloch. Po nainštalovaní služby Git na svojom systéme, je potrebné vykonať základnú konfiguráciu prostredia. Vykonané nastavenia sa uložia na danom počítači a pretrvajú aj po aktualizáciách služby. Tieto nastavenia je možné dodatočne zmeniť. Git má zabudovaný nástroj s názvom git config, ktorý umožňuje získať a uložiť konfiguráciu do premenných. Tieto premenné sú uložené v konfiguračných súboroch služby a kontrolujú fungovanie a vzhľad prostredia Git. Základnou konfiguráciou Git po jej inštalácii je udelenie údajov o používateľovi služby na danom zariadení. Údajmi sa rozumie meno a e-mail adresa používateľa. Príkazom:

    git config --global user.name "Meno Priezvisko"

služba Git uloží pridelené meno používateľa a na pridelenie e-mailovej adresy používateľa sa použije príkaz:

    git config --global user.email <Email Pouzivatela>

Pridelenie údajov o používateľovi je dôležité, pretože Git prikladá uložené údaje ku každému záznamu (commit) ktorý sa používateľom vykoná.

Inštalácia potrebných nástrojov cez virtuálne prostredie Docker

Docker je voľne dostupný open source nástroj využívaný na jednoduché nasadenie a spustenie aplikácií pomocou tzv. kontajnerov. Poskytuje vývojárom možnosť zabalenia aplikácií, so všetkými potrebnými súbormi a závislosťami pre jej správne fungovanie, do štandardizovaného balíka - kontajnera. Všetky závislosti, od konkrétnej verzie programovacieho jazyka až po potrebné knižnice sú už súčasťou obsahu kontajnera. Zabalené kontajnery sú poskytované vývojármi aplikácií pre svojich používateľov, ktorí pomocou prostredia Docker dokážu danú aplikačnú službu spustiť. Docker kontajnery boli vytvorené tak, aby boli nezávislé od prostredia na ktorom bežia a sú štandardizované, používatelia tak dokážu pracovať s Dockerom a so zabalenými kontajnermi na akomkoľvek operačnom systéme a bez žiadnych obmedzení.
Pre používateľov Dockera sú dostupné zabalené obrazy s aplikáciami od vývojárov na tzv. Docker Hub-e, kde sú dostupné podrobné popisy, inštrukcie a konfigurácie rôznych aplikácií. Práve toto online úložisko s obrazmi sme pri realizácii praktickej časti našej práce použili aj my. Pomocou Dockeru sme nainštalovali a spustili na vlastnom zariadení všetky potrebné aplikácie používané pri práci. Aplikácie sa sťahujú pomocou obrazov, ktoré je následne potrebné spustiť ako kontajnery.
Pre jednoduchšie spravovanie a lepší prehľad o celom prostredí Docker-a, je dostupná aplikácia vo forme spustiteľného kontajnera. Aplikácia s názvom Portainer vytvára grafické rozhranie pre prostredie Docker, ktoré umožňuje spravovať kontajnery, obrazy, zväzky, siete a zobraziť podrobné informácie o nich bez použitie príkazov. Pri práci sme využívali aj toto prostredie. Používané služby pri realizácii praktickej časti bakalárskeho projektu zaobstarané pomocou Docker kontajnerov sú: Služba pre správu verzií Gogs, Služba pre správu verzií Gitlab, Nástroj CI/CD Jenkins , Nástroj CI/CD Gitlab Runner a služba pre vizualizáciu Docker prostredia - Portainer.

Inštalácia a konfigurácia nástroja Gogs

Nástroj Gogs ponúka možnosť vyskúšania "demo" verzie online, ktorá funguje ako Web rozhranie. Po registrácii ponúka priestor pre odskúšanie nástroje Gogs. Umožňuje zakladanie repozitárov a prácu s nimi. Pre dôkladnejšie odskúšanie sme sa však rozhodli si nástroj nainštalovať na lokálnom počítači.
Nástroj pre prácu s Git s názvom Gogs je možné stiahnuť a nainštalovať viacerými spôsobmi, v závislosti od operačného systému zariadenia. Jednoduchú možnosť inštalácie a spustenia služby ponúka spomínané virtuálne prostredie Docker. Docker ponúka obraz (image) s pred konfigurovanou službou Gogs. Stiahnutie obrazu so všetkými jeho potrebnými súčasťami sa realizuje príkazom:

    docker pull gogs/gogs

Spustenie kontajnera so službou sa vykoná ďalším príkazom (docker run), ktorým sa určia základné konfigurácie daného Docker kontajnera a najdôležitejšie - port počítača na ktorom služba beží. V našom prípade sme si zvolili preddefinovaný port 3000. Gogs bude bežať na lokálnej adrese (localhost, resp. IP adresa počítača) na porte 3000. Port 10022 je namapovaný na službu SSH vo vnútri docker kontajnera (port 22). Príkaz na vytvorenie kontajnera:

    docker run -name=gogs -p 10022:22 -p 3000:3000 \
    --restart always \
    -v /var/gogs:/data gogs/gogs

Po spustení Gogs sa objaví prihlasovacie okno do nástroja kde je po prvom otvorení potrebné vytvoriť administrátorské konto. Po zaregistrovaní a prihlásení nám už služba ponúka plnohodnotné prostredie Gogs a môže sa začať s vytváraním nových používateľov, skupín a projektov.

Inštalácia a konfigurácia nástroja pre CI/CD - Jenkins

Na odskúšanie a používanie nástroja Jenkins je potrebné ho nainštalovať do zariadenia, ktoré bude nástroj využívať. Ponúkané sú rôzne verzie v závislosti od operačného systému zariadenia. Nie je ponúkaná však žiadna verzia na odskúšanie online pomocou hostovaných web rozhraní. Inštalácia je možná pomocou inštalačných balíkov vytvorených výhradne pre daný operačný systém, alebo je možné nástroj získať ako obraz služby Docker a následne ho používať ako spustený kontajner.
Aj v prípade Jenkinsu ponúka Docker obrazy s pred konfigurovanými verziami nástroja. Pri práci s Jenkinsom sme si zvolili inštaláciu v prostredí Docker, kedy sme zvolený obraz stiahli príkazom:

    docker pull jenkins/jenkins

Príkazom sa stiahne obraz. Následne je potrebné vytvoriť kontajner. Vykoná sa to s presnými nastaveniami ktorými sa aplikácia nasadí. Príkaz na vytvorenie kontajnera so službou Jenkins:

    docker run -name=jenkins -d \
    --restart=always \
    -p 8080:8080 -p 50000:50000 \
    -v jenkins_home:/var/jenkins_home jenkins/jenkins lts

Preddefinovaný port pre aplikáciu je 8080. Ďalej a vytvorí sa Docker volume (zväzok) s názvom jenkinshome, obsahujúci konfiguračné a pracovné súbory daného kontajnera. Tento zväzok je fyzicky umiestnený na hosťujúcom počítači. Zväzky služby Docker zotrvajú aj po zastavení a zmazaní kontajnera a sú spravované samotným Dockerom.
Po prvotnom spustení je potrebné nástroj Jenkins odomknúť pomocou hesla, ktorý sa vytvorí a uloží pri inštalácii. Adresár kde sa dané heslo nachádza sa zobrazí na prvotnom okne po spustení. Po presmerovaní do uvedeného adresára je potrebné heslo zobraziť a následne ho zadať do okna, aby sa nástroj Jenkins začal používať.
Ďalším konfiguračným krokom je zvolenie nainštalovaných pluginov nástroja. Jenkins ponúka možnosť inštalácie odporúčaných pluginov alebo výber nechá na používateľa, zvolené súčasti sa potom automaticky stiahnu a nainštalujú. Pluginy je možné nainštalovať aj dodatočne po spustení služby. Prvý účet sa vytvorí hneď po nainštalovaní pluginov a to zadaním používateľského mena a hesla, ale je možné pokračovať aj ako správca, keďže pri našej práci sa neočakáva viacero používateľských účtov na používanom zariadení.

Inštalácia a konfigurácia nástroja pre prácu s Git - Gitlab

Na odskúšanie sme nástroj Gitlab nainštalovali na privátny počítač pomocou Docker obrazu. Docker na Docker Hub-e ponúka Gitlab k stiahnutiu vo viacerých verziách. Podla postupu uvádzaného na oficiálnej stránke vývojárov Gitlab sme službu nainštalovali príkazom

    docker pull gitlab/gitlab-ce

je možné nástroj stiahnuť vo verzii Community Edition, ktorá je určená pre verejnosť. Kontajner bolo potrebné vytvoriť s vhodnými nastaveniami pomocou príkazu podľa inštrukcií v dokumentácii služby:

    docker run --detach \
    --hostname gitlab.example.com \
    --publish 443:443 --publish 80:80 --publish 2222:22 \
    --name gitlab \
    --restart always \
    --volume /srv/gitlab/config:/etc/gitlab \
    --volume /srv/gitlab/logs:/var/log/gitlab \
    --volume /srv/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest\

Po prvom prepnutí na adresu lokálne spustenej služby sa objaví uvítacia stránka s ponukou registrácie. Registráciu je potrebné vykonať pre možnosť vytvárania repozitárov a celkovo prácu so službou Gitlab. Pre našu prácu a odskúšanie možností je potrebné vytvoriť konto s administrátorskými právami. Po prihlásení sa objaví plnohodnotné používateľské rozhranie služby Gitlab. Prvotná konfigurácia pozostáva aj zo spojenia služby so zariadením pomocou SSH kľúču.

Integrácia nástrojov Jenkins a Gogs

Spojenie zvoleného nástroja Gogs pre správu verzií so službou pre CI/CD - Jenkins je potrebné vytvoriť medzi nimi spojenie a nástroje správne nakonfigurovať, aby bola ich automatická spolupráca možná. Cieľom je vytvoriť spojenie medzi repozitárom nástroja Gogs so službou Jenkins za účelom automatického vykonávania rôznych inštrukcií zadaných používateľom.
V prvom rade pre spojenie spomínaných nástrojov je potrebné pre Jenkins nainštalovať Gogs plugin, ktorý nám zabezpečí, aby Jenkins rozpoznal repozitáre vytvorené v prostredí Gogs. V používateľskom rozhraní nástroja Jenkins je potrebné prepnúť na zložku Manage Jenkins a následne Manage Plugins sa objavia Pluginy rozdelené do skupín. Pluginy ktoré sú nainštalované sa nachádzajú pod oknom Installed, a naopak tie ktoré sú dostupné na stiahnutie pod oknom s názvom Available. Pre aktualizácie pluginov je dostupné aj okno Updates, kde sa zobrazia pluginy, pre ktoré sú dostupné aktualizácie. Pre stiahnutie pluginu pre spoluprácu s repozitárom Gogs je potrebné prepnúť na okno Available a následne manuálne vyhľadať a stiahnuť plugin s názvom Gogs plugin. Po stiahnutí sa služba automaticky reštartuje a následne je služba pripravená na vytvorenie spojenia s repozitárom.
Ďalším krokom pre umožnenie spolupráce nástroja Jenkins s repozitárom služby Gogs je potrebné prideliť službe Jenkins poverenia ktoré umožňujú čítať obsah repozitára pomocou zabezpečeného prístupového protokolu SSH. Pre vytvorenie SSH kľúča pomocou RSA algoritmu na používanom zariadení je potrebné zadať príkaz:

    ssh-keygen -t rsa -b 4096 

Príkazom sa vygeneruje kľúč ktorý pozostáva z dvoch častí a to zo súkromného a verejného kľúča. Pre Jenkins je potrebné uviesť súkromný kľúč pre úspešnú spoluprácu s repozitárom. Jenkins umožňuje prideliť poverenia rôznych typov pomocou okna Credentials. Vygenerovaný privátny SSH kľúč je potrebné pridať ako Credential typu SSH Username with private key. Vyplnením potrebných údajov ako je meno používateľa a obsah privátneho kľúča je Jenkins pripravený na vytváranie projektov a na prácu s Gogs repozitárom. Základnú konfiguráciu je potrebné vykonať aj v rozhraní Gogs. Potrebné je pridať verejný SSH kľúč vygenerovaný na počítači. Po nastavení SSH je potrebné vytvoriť Git projekt (repozitár) v prostredí Gogs. Pred klonovaním a pridaní súborov do repozitára je však potrebné nastaviť webhook, ktorý je potrebný nakonfigurovať za účelom oznamovania nástroju Jenkins kedy sa v projekte vykonala a nahrala zmena. Pre webhook je potrebné uviesť URL adresu projektu Jenkins, s ktorým je potrebný zvolený repozitár prepojiť. Pri konfigurácii je možné zadať heslo, bez ktorého uvedenie v oboch nástrojoch sa neumožní spojenie. Pre odskúšanie spojenia s webhookom umožňuje nástroj Gogs jednoduchým tlačidlom odskúšať spojenia medzi projektom Jenkins a repozitárom Gogs. Tlačidlo Test Delivery pošle odozvu a skontroluje či sa spojenie podarilo. Následne podrobné výsledky testu oznámi v rozhraní Gogs. Na vytvorenie spojenia sme postupovali podľa online návodu .

Typy projektov Jenkins:
Jenkins projekt slúži na vytvorenie automatizačných krokov pre spustenie, testovanie a nasadenie vyvíjaných zdrojových kódov, ktoré sa spustia opakovane podľa potreby už samostatne. Za pomoci pluginov je možné spustiť takmer akúkoľvek aplikáciu nezávisle od programovacieho jazyka. Jenkins ponúka vytvoriť projekty rôznych typov v závislosti od funkcií ktoré daný projekt dokáže vykonať, prípadne ako je ho možné nakonfigurovať.

Freestyle projekt
Základným typom projektu v Jenkinse je Freestyle projekt, ktorý je veľmi ľahký na pochopenie a používa sa na vytvorenie automatizačných krokov počas vývoja softvéru. Umožňuje prácu s repozitárom z akéhokoľvek prostredia s ktorým je spojenie nakonfigurované, môže ísť o spoluprácu s Git rozhraniami ako Gitlab, Github, či Gogs alebo podporované sú aj staršie služby ako CVS. Nástroj Jenkins je najefektívnejší práve v spojení so službou pre správu verzií. V prípade použitia Freestyle druhu projektov nie je potrebné vytvárať pipeline script, ktorý má vlastný súbor pravidiel avšak môžme ho považovať za CI/CD pipeline. Na vykonanie krokov je možné použiť všetky známe príkazy z prostredia Windows Batch, v prípade že sa používa operačný systém Windows, a taktiež je možné použiť príkazy z prostredia Shell pre ostatné operačné systémy. V projektoch tohto typu je využívanie známych príkazov najlepší spôsob vytvárania automatizačných krokov pre vývoj softvérov. Tým pádom je možné spúšťať rôzne typy súborov naprogramovaných v rôznych programovacích jazykoch jednoducho pomocou základných príkazov ako sú gcc (pre aplikácie jazyka C), javac (pre jazyk Java) prípadne príkaz py (pre jazyk Python) a množstvo ďalšie. Zaujímavá možnosť je vzájomná spolupráca Jenkins projektov, kedy dokáže jeden projekt spustiť ďalší, prípadne zvoliť ich poradie spustenia ak sú na seba nadviazané.

Pipeline projekt
Jenkins Pipeline projekt predstavuje implementáciu CD (continuous deployment) pipelinov v prostredí Jenkins. Na rozdiel od Freestyle projektov ponúka viac jednoznačnú funkciu pre podporu úspešného doručenia vyvíjaného softvéru. Jenkins Pipeline po spojení spolupracuje s akoukoľvek službou na správu verzií, rovnako ako dokáže Freestyle projekt. Každá vykonaná zmena zaznamenaná do zvoleného nástroja so zdrojovým kódom prejde cez kroky ktoré sú vytvorené pomocou automatizačného pipelinu. Pipeline môže byť vytvorený pomocou používateľského prostredia nástroja, kedy sa skript pre pipeline vloží priamo pri zakladaní projektu a nástroj ho využíva samostatne pre zvolený repozitár. Lepším spôsobom využívania pipelinu je priamo cez nástroj na správu zdrojových kódov. Skript je možné zaznamenať do textového súboru s názvom Jenkinsfile, ktorý je potom uložený do pracovného repozitára prepojený s Jenkins projektom. Pipeline skript v Jenkinsfile je automaticky detekovaný a vykonaný nástrojom Jenkins. Využívanie Jenkinsfile-u umiestneného v repozitári so všetkými pracovnými súbormi softvéru je výhodné pre jednoduchšiu údržbu a vykonávanie zmien. Pre úpravu skriptu pre pipeline stačí upravený textový súbor zaznamenať do repozitára a nie je potrebná konfigurácia celého pipeline projektu pre úpravu skriptu. Pre prípad kedy je potrebné vykonať CI/CD kroky v repozitári na všetkých jeho vetvách, má Jenkins dostupný plugin s názvom Multibranch Pipeline. Pomocou tohto pluginu je možné vytvárať projekt ktorý automaticky rozpozná počet vetiev repozitára a zvolený pipeline skript vykoná na každej z nich, a jednotlivé build-y ostanú nezávislé od seba.

Obr 3.1 Grafické znázornenie úspešne dokončeného Jenkins pipeline

Na Obr. 3.1 sú zachytené výstupy úspešných Jenkins pipeline projektov. Graficky sa zobrazí poradie v akom sa dané buildy vykonali podľa dátumu a času vykonania. Zobrazuje názvy jednotlivých krokov a k nim sa priraďuje doba vykonania jednotlivých krokov. Zelenou farbou sa zobrazuje úspešný krok, prípadné neúspešné kroky sa zobrazia červenou farbou. Rozhranie ponúka aj podrobný rozpis krokov v tzv. konzolovej forme, kde je písomný opis vykonaných krokov. Jenkins pri vytváraní projektov umožňuje zvoliť, kedy sa má automatizačný projekt spustiť, prípadne aké akcie majú spustenie pipelinov vyvolať. Prvým spôsobom je spúšťať build na diaľku pomocou e-mailu prípadne vytvoriť požiadavku na spustenie pomocou webhookov. Je možné spúšťanie naplánovať, kedy sa build spustí vždy periodicky v presne zvolenom čase a dni v mesiaci. Pomocou nainštalovaných pluginov, za účelom spolupráce s inými nástrojmi softvérového inžinierstva, ako sú nástroje pre správu verzií s Git je možné spustenie projektov v Jenkinse aj po zaznamenaní (push) zmien do repozitára služby Gogs, Gitlab a GitHub.

Integrácia nástrojov Jenkins a Gitlab

Po osvojení práce s repozitárom Gogs v spolupráci s nástrojom Jenkins, sme sa rozhodli odskúšať službu s rozsiahlejšími možnosťami Gitlab. Vytvorenie spojenia medzi nástrojom Jenkins a Gitlab je z teoretického hľadiska rovnaký, ako bol s repozitárom služby Gogs avšak pri vytváraní ich spolupráce sa niektoré konfiguračné kroky líšia.
Community edícia služby Gitlab neponúka vstavanú integritu pre Jenkins, ale ich spojenie je jednoduché a bezproblémové. V prípade ak sme prihlásený ako správca (admin) služby Gitlab, je potrebné nastaviť výnimku pre odchádzajúce žiadosti na čítanie obsah repozitárov. V nastaveniach správcu Admin area - Settings - Network po otvorení okna Outbound requests je možné zvoliť výnimky (whitelist) URL adries, s ktorými je spolupráca umožnená. V nástroji Jenkins je rozhranie upravené na prácu s Gitlab repozitárom opäť pomocou pluginu (rozšírenia) s názvom Gitlab plugin. Týmto rozšírením sa zaistí spustenie CI/CD projektu pri vykonaní zmien v repozitári. Pri vytváraní projektov je potrebné zvoliť možnosť Build when a change is pushed to Gitlab. Pre umožnené spojenie nástrojov je potrebné generovať tzv. secret token, ktorý slúži ako heslo pri spájaní nástrojov. Secret token je generovaný pri vytváraní pipeline projektu.
Posledný krok pre úspešnú spoluprácu nástrojov je potrebný vykonať v nastaveniach Gitlab projektu v sekcii Integrations, kde je potrebné pridať Project Hook, ktorý oznámi nástroju Jenkins o vykonaných zmenách v repozitári. Project Hook je potrebný nakonfigurovať pomocou URL adresy Jenkins projektu v tvare:

    http://MenoUseraJenkinsu:APItoken@URL_Jenkinsu/project/nazovprojektu

Kde jediným neznámym údajom ostáva API token, ktorý sa generuje v rozhraní Jenkins pre individuálnych používateľov. Po kliknutí na účet používateľa a zvolení okna Configure je API token generovaný nástrojom. Ten je potrebný následne vložiť do URL adresy pre Project Hook. Po uložení zmien je spojenie medzi nástrojmi vytvorené. Na odskúšanie spojenia medzi nástrojmi ponúka Gitlab v sekcii Integrations možnosť na Test spojenia.

Inštalácia a integrácia nástroja Gitlab CI

Gitlab Runner, ktorým sa vstavaný nástroj na vytváranie CI/CD pipelinov - Gitlab CI pripája k pracovnému repozitáru je potrebný nainštalovať ako samostatná služba. Rovnako ako ostatné služby je Gitlab runner možné používať cez kontajner nástroja Docker. Spustenie služby sme vykonali príkazom:

    sudo docker run -d --name gitlab-runner 
    --restart always   
    -v /var/run/docker.sock:/var/run/docker.sock   
    -v /srv/gitlab-runner/config:/etc/gitlab-runner   
    gitlab/gitlab-runner:latest

Po inštalácii Gitlab Runnera je potrebné ho spojiť so samotným Gitlab repozitárom, pre vzájomnú spoluprácu nástrojov. Registrácia Gitlab Runnera sa vykoná užívateľom, ktorý pri procese registrácie zadá všetky informácie potrebné pre úspešné spojenie nástrojov. Udáva sa názov vytváraného runnera, URL adresa repozitára, špecifický registračný token vygenerovaný Gitlabom a executable, ktorý udáva v akom formáte sa má napísaný skript pre CI/CD pipeline spustiť. Registračný token sa nachádza v nastavení projektu v sekcii CI/CD Settings - Runners. Po nakonfigurovaní Gitlab Runnera je pripravený na prácu. Po každom zaznamenaní zmien do vzdialeného repozitára sa automaticky spustí skript napísaný v súbore YAML nazvaný .gitlab-ci.yml. Súbor je potrebné mať tiež uložený medzi súbormi repozitára. Automaticky sa spustia a vykonajú kroky udané v súbore, či už na spustenie, testovanie prípadne nasadenie súborov.

Obr 3.2 Rozhranie okna Gitlab CI/CD po spustení automatizovaných pipeline krokov

Obr. 3.2 zobrazuje stavy vykonaných prípadne práve vykonávaných pipeline krokov v prostredí Gitlab CI/CD. Vypíše sa vo forme tabuľky poradie spustených pipeline, ktoré sa spustili automaticky po zaznamenaní súborov. Okno zobrazuje stav vykonávaného pipeline, údaj o čase vykonania, údaj o dôvodu spustenia (osoba) a poznámku vytvorenú pri zázname zmien. Pipeline sa v okne môže zobraziť v troch stavoch:

• Running (modrá farba) - aktuálne spustené
• Passed (zelená farba) - úspešne vykonané
• Failed (červená farba) - vykonané neúspešne
• Canceled (čierna farba) - prerušený pipeline počas vykonávania

Vytváranie CI/CD pipeline na spustenie, testovanie a nasadenie projektov

Hlavným cieľom praktickej časti bakalárskej práce bolo vytvoriť CI/CD pipeline s nástrojom Gitlab CI a Jenkins, ktorý spolupracuje s repozitárom služby Gitlab. Pre odskúšanie možností služieb sme vytvorili automatizované CI/CD pipeline pre spustenie rôznych projektov navrhnutých v rôznych programovacích jazykoch ako C++, C a Java. Vytvorením krokov vhodných na spustenie a následné nasadenie projektov sme otestovali možnosti nástrojov Jenkins a Gitlab CI. Projekty vytvorené nástrojom na CI/CD Jenkins boli nakonfigurované tak, aby reagovali na zaznamenanie zmien vykonaných na zdrojových kódoch do vzdialených repozitárov služby Gogs a neskôr efektívnejšej služby Gitlab.
Nástroj Jenkins dokáže spustiť programy navrhnutých v rôznych programovacích jazykoch pomocou príkazov prostredia Shell. Pridaním predpony sh pred príkazy sa určí druh príkazu Shell pre pipeline skript. Časťou CI/CD pipelonov môžu byť aj kroky na testovanie pomocou tzv. unit testov navrhnutých práve na test a správne fungovanie častí vyvíjaného programu.
Pre odskúšania možností nasadenia pomocou nástroja Jenkins sme vytvorili ďalšie kroky za účelom presunutia spustených binárnych súborov, ktoré sa vytvorili vo zvolenom adresári pomocou skriptu v predošlom kroku pipeline. Jednoduchú možnosť nasadenia pomocou nástroja Jenkins na vzdialený server, ktorým je zariadenie prepojené, ponúka príkaz scp. Secure copy protocol (scp) slúži na prenos súborov medzi vzdialenými zariadeniami na základe SSH protokolu. Alternatívou scp pre operačné systémy s jadrom GNU/Linux ponúka protokol rsync.
Manuál Linux man opisuje príkaz rsync, ktorý slúži tiež na prenos súborov medzi lokálnymi prípadne vzdialenými zariadeniami. Ponúka možnosti výberu aspektov správania príkazu a umožňuje veľmi flexibilnú špecifikáciu súboru, ktorý sa prenáša. Príkazom rsync je možný prenos vybraných súborov na ktorých sa vykonala zmena, nie je potreba teda presúvať všetky súbory v celku. Pre oba druhy prenosových protokolov je žiadúce vzdialené zariadenia prepojiť v sieti a spojiť ich pomocou kľúčov protokolov SSH. Na zariadení s operačným systémom Linux Mint sme spojenie vytvorili pridaním súboru s názvom authorizedkeys, ktorý obsahuje ssh kľúče zvolených prepojených zariadení, do adresára s vygenerovanými ssh kľúčmi zariadenia.
Spojenie s nástrojom Jenkins sme vykonali s repozitármi služby Gogs aj Gitlab. Postup pre návrh CI/CD pipeline pre prostredie Jenkins je rovnaký s oboma službami. Repozitár obsahoval skúšobné súbory navrhnuté v programovacom jazyku C. V nástroji Jenkins sme vytvorili projekty druhu Freestyle, ktoré mali kroky na pipeline skript zaznamenané priamo v užívateľskom rozhraní nástroja pomocou príkazov rozhrania Shell.
Pre Pipeline projekt sme použili možnosť umiestnenia textového súboru s názvom JenkinsFile v pracovnom projekte služby pre prácu s Git. JenkinsFile obsahuje skript s krokmi, ktoré ma automatizovaný pipeline vykonať.
Za účelom spustenia programu programovacieho jazyka C a následné presunutie vytvoreného binárneho súbora na vzdialený host sme vytvorili nasledovný pipeline skript uložený do JenkinsFile:

pipeline {
   agent any
   
   stages {
      stage('Krok 1 - Vypise sa oznam') {
         steps {
            echo 'Skompiluje sa subor hello.c a vytvori sa binarny 
            subor s nazvom build a presunie sa na "server".'
         }
      }
      stage('Krok 2 - Kompiluje sa pomocou gcc') {
         steps {
            sh 'gcc program.c -o build' 
         }
      }
      stage('Nasadenie pomocou SCP') {
         steps {
            sh 'scp /jenkins/build server@110.220.330.440:/adresar/'
         }
      } 
   }
}

Prvý krok (stage) slúži na výpis oznamu pomocou príkazu echo. Krok dva spustí súbor s názvom program.c a získaný binárny súbor pomenuje build. Spustenie sa vykonáva príkazom rozhrania Shell v tvare gcc. Pre správne fungovanie príkazov je potrebné zvoliť druh rozhrania Shell predponou sh.
Následné nasadenie vytvoreného binárneho súbora s názvom build sa vykoná pomocou protokolu scp, ktorý daný súbor presunie na zvolené vzdialené zariadenie pod používateľom server. Tvar príkazu označuje druh prenosového protokolu, adresár uloženého súboru a adresár vzdialeného zariadenia, kde si želáme súbor umiestniť. Pre vzdialený prenos súborov je potrebné uviesť adresár v tvare s názvom používateľského konta a IP adresou prepojeného zariadenia.

Príklad automatizovaného pipeline-u spustenia a nasadenia súboru programovacieho jazyka C sme vytvorili aj v rozhraní Gitlab pomocou nástroja Gitlab CI. Po vytvorení spojenia medzi repozitárom a službou Gitlab runner, ktorá umožňuje chod nástroja Gitlab CI, sme odskúšali možnosti služieb. Skúšobné súbory sme zaznamenali do repozitára spolu s YAML súborom. Súbor s názvom .gitlab-ci.yml obsahuje skript pre automatizovaný CI/CD pipeline, podobne ako obsahoval súbor JenkinsFile pipeline skript pre nástroj Jenkins. Gitlab CI prítomný súbor automaticky rozpozná a po každom nahraní záznamov do projektu pipeline skript spustí. V užívateľskom prostredí Gitlab projektu sa nachádza okno s názvom CI/CD, kde sa každý vykonaný pipeline zobrazí s podrobným popisom. Pri registrovaní Gitlab runner-a k projektu sme zvolili executor docker a obraz využívaný na kompiláciu programov jazyka C - gcc.

image: gcc

before_script:
  - mkdir -p ~/.ssh
  - echo -e "$STAGING_SSH_KEY" > ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

stages: 
    - spustenie
    - nasadenie 

spustenie:
    stage: spustenie
    script: gcc program.c -o build
    artifacts: 
      paths: 
      - build 

nasadanie: 
    stage: nasadenie
    script:  
        - scp build server@110.220.330.440:/Gitlab/CI/

Vrchná časť YAML súboru označuje docker obraz s ktorým má pipeline pracovať, Gitlab CI stiahne obraz gcc a následne ho využíva v krokoch. Časť beforescript je potrebný pre prácu s príkazom scp a vykoná Kedže pracuje na princípe SSH protokolu, je potrebné priradiť SSH klúče zariadení do premennej s názvom STAGINGSSHKEY. Následne sa vytvárajú kroky pipeline s názvom spustenie a nasadenie. Krok spustenie vykoná kompiláciu súboru program.c príkazom gcc a vytvorí job artifact s uloženými súbormi vykonaného pipeline.
Dokumentácia Gitlab CI/CD uvádza Job artifacts ako zoznam súborov a adresárov vytvorených prácou pipeline-u, ktoré sa následne dajú kedykoľvek stiahnuť z rozhrania repozitára Gitlab. Nasadenie sa vykonalo príkazom scp, ktorý vytvorený binárny súbor presunie do zvoleného adresára na vzdialené zariadenie s názvom server.

Obr 3.3 Výsledok úspešne spusteného pipeline kroku

Na Obr. 3.3 je zobrazený úspešne vykonaný krok pre spustenie súboru navrhnutého v programovacom jazyku C. Pipeline postupne vykoná všetky príkazy uvedené v YAML súbore a vyhodnotí, či sa dané kroky vykonali správne.

Implementácia nástrojov CI/CD pre projekt eXam

Systém eXam je online nástroj pre podporu výučby programovacích jazykov. Je v správe vedúceho bakalárskej práce. Na Materiálovotechnologickej fakulte STU sa využíva na predmetoch Informačné technológie a Programovacie jazyky od roku 2019.
Systém poskytuje automatickú kontrolu správnosti programátorských úloh napísaných v jazyku C/C++. Systém eXam je naprogramovaný v jazyku PHP, vo frameworku Nette 3.0. Funkcie systému eXam sa priebežne pridávajú, čo znamená že pri zmene a doplnení zdrojových kódov je potrebné manuálne aktualizovať inštaláciu na produkčnom serveri. Cieľom je eliminovať potrebu manuálneho nasadenia novej vezie zdrojových kódov. Pre riešenie tejto úlohy sme zvolili vytvorenie CI/CD pipeline, ktorý by tento proces automatizovala.
Požadovaná funkcionalita nasadenia novej verzie systému eXam:

• po vytvorení zmien v zdrojových kódov projektu eXam, sa tieto zmeny nahrajú (git push) na server Gitlab,
• nástroj CI/CD zabezpečí automatické vyzdvihnutie (git pull) novej verzie zdrojových kódov do web adresára serveru exam.mtf.stuba.sk,
• nástroj CI/CD zmaže staré automaticky vygenerované súbory projektu eXam (cache).

Na nasadenie webu eXam sme zvolili nástroj Gitlab CI, keďže všetky potrebné súbory a zdrojové kódy sú spravované v repozitári rozhrania Gitlab. Povolením Gitlab CI v nastaveniach projektov rozhrania a registráciou zvoleného Gitlab Runner-a sme boli pripravený službu využívať. Pri registrovaní Gitlab Runner-a s repozitárom sme zvolili executor typu docker, pomocou ktorého sa jednoduchšie využívajú súčasti pre pipeline skript.
Vytvorením YAML súboru pomenovaný .gitlab-ci.yml a pridaním ho medzi pracovné súbory repozitára sa snaha o vytvorenie pipeline automaticky rozpozná. Následne Gitlab automaticky spúšťa kroky, ktoré obsahuje súbor pri každej nahranej zmene do repozitára.
Po nahraní zmien (git push) do vzdialeného Gitlab repozitára so súbormi systému eXam je potrebné tieto zmeny automaticky nasadiť na server z ktorého je web eXam šírený.
Navrhnutý pipeline na základe udaných krokov v súbore YAML automaticky prevezme všetky aktuálne súbory nachádzajúce sa v repozitári a následne ich pomocou kroku (stage) nasadenie presunie do vzdialeného priečinka nachádzajúci sa na spomínanom serveri. Presun súborov sme vykonali už odskúšanými metódami nasadenia softvérových diel - protokolom scp (prípadne rsync) a vzdialeným pripojením ssh.
Pre finálne spustenie novej verzie web aplikácie s aktualizovanými súbormi je potrebné vyčistiť cache pamäť nasadeného rozhrania, kde sa ukladajú súbory počas fungovania systému. Krok sme vykonali pomocou vzdialeného pripojenia ssh a následného použitia príkazu na mazanie obsahu adresárov: príkaz rm. Zmazaním obsahu špecifického adresára cache sa web rozhranie aktualizuje.
Pre oba použité príkazy je potrebné spustiť tzv. beforescript, ktorý v sebe zahŕňa kroky pre prácu cez ssh. Tieto kroky sa vykonajú vždy pred spustením samotných krokov pipeline. Táto časť je potrebná pre udelenie SSH kľúča vzdialeného zariadenia, pre možnosť spolupracovať a spravovať súbory na danom zariadení práve pomocou SSH.
Pre tento krok je potrebné vytvoriť premennú (variable) pre využívaný projekt služby Gitlab, ktorá bude obsahovať práve privátny ssh kľúč zariadenia, s ktorým si želáme spojenie vytvoriť. V našom prípade je táto premenná pomenovaná STAGINGSSHKEY. Obsah YAML súbora na nasadenie a spustenie aktualizácií systému eXam:

image: docker:git

before_script:
  - mkdir -p ~/.ssh
  - echo -e "$STAGING_SSH_KEY" > ~/.ssh/id_rsa
  - chmod 600 ~/.ssh/id_rsa
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

stages: 
    - nasadenie    
    - mazanie_cache
nasadanie: 
    stage: nasadenie
    script:  
        - scp -r * server@110.220.330.440:/eXam

mazanie_cache:
    stage: mazanie_cache
    script:  
    - ssh server@110.220.330.440 'rm /eXam/opt/exam/web/exam_nette/temp/cache/*'

Ako prvé sme si zadefinovali Docker obraz, s ktorým bude pipeline pracovať. Pre prípad nasadenia systému eXam sme zvolili docker obraz služby Git. V našom prípade príliš nezáleží na použitom obraze, keďže na nasadenie sa využíva protokol ssh, ktorý je súčasťou služby Gitlab a príkaz automaticky rozpozná. Pre prípad používania neznámych príkazov, ktoré nie sú súčasťou systému, je potrebné špecifické obrazy na ich správne fungovanie (ako v prípade aplikácií jazyka C, kde sme na kompiláciu použili obraz gcc). Nasadenie realizované príkazom scp má zvolené obmedzenia -r *, čím sa udáva presun celého repozitára so súbormi vrátanie ďalších podpriečinkov.
V oboch krokoch pipeline je uvedený adresár vzdialeného zariadenia, kam by mal byť obsah repozitára presunutý. Pre vzdialený prenos súborov je potrebné uviesť adresár v tvare s názvom používateľského účtu a IP adresou prepojeného zariadenia. Príkaz scp môže byť nahradený príkazom rsync, ktorý prenáša len tie súbory, ktoré boli počas aktualizácii systému zmenené, teda len synchronizuje adresár so zmenami. V prípade použitia rsync, bude tvar príkazu totožný s protokolom scp.
Finálny krok za účelom zmazania cache pamäte sme vykonali v špecifickom adresári obsahujúci uložené súbory vytvárané pri spustení systému.

Obr 3.4 Výsledok úspešne spusteného pipeline kroku pre nasadenie systému eXam.

Vizualizovaný výstup úspešne dokončeného CI/CD kroku nasadenie v prostredí Gitlab sa zobrazí po prepnutí na okno CI/CD v tvare akom sú zobrazené na Obr. 3.4. Zelené príkazy určujú úspešne zrealizované príkazy a v pravo sa k nim radí čas trvania jednotlivých krokov. Najprv si pipeline stiahol zvolený docker obraz, následne na začiatku oboch krokov vykonal časť beforescript. Vykonávanie príkazov scp a ssh prebehlo úspešne.

Zálohovanie údajov služby pre správu verzií Gitlab – Gitlab Backup

Pre zabezpečenie softvérov, nástrojov a informácií užívateľov sa využíva zálohovanie dát. Zálohovanie by sa malo vykonávať v pravidelných intervaloch kvôli zabezpečeniu dát proti ich strate prípadne poškodeniu. Ak by teda nastala situácia, kedy sa dáta prípadne celý systém poškodia, pomocou záloh sa dá daný systém obnoviť do stavu, v akom sa nachádzal pri vytvorení zálohy. Nástroj pre správu verzií Gitlab má zabudovaný nástroj pre zálohovanie celej služby s názvom Gitlab Backup. Administrátor služby je schopný vytvárať zálohy svojej služby a v prípade potreby systém kedykoľvek obnoviť pre udržiavanie bezpečnosti systému. Príkaz na vytvorenie zálohy sa zadáva do terminálu je nasledovný:

    sudo gitlab-backup create

Pre prípad ak je služba Gitlab spustená ako Docker kontajner, používa sa príkaz :

    sudo docker exec -t <nazov kontajnera> gitlab-backup create

Gitlab je schopný vytvoriť pomocou zabudovaného nástroja zálohu celej služby a rovnako aj jej jednotlivých častí, ako sú dáta z repozitárov a databáz, výstupy spustení nástroja Gitlab CI, registrov a ďalšie. Pomocou Gitlab Backup sa dá jednoducho presunúť služba aj medzi strojmi. Gitlab Backup však dokáže obnoviť súbory len na rovnakú verziu a typ (Community Edition/Enterprise Edition) služby.

Pre odvolanie zaznamenaných zmien v repozitári, v prípade ak sa zaznamenala nežiadúca zmena, git umožňuje vývojárom repozitár vrátiť do stavu predošlých záznamov alebo do stavu pred spojení vetiev. Ukážka Git Undoing Commits od Atlassian opisuje odvolávanie záznamov nasledovne : Vytváraním záznamov sa vytvorí história projektu. Stav zdrojových kódov pri každom zázname je možné prezerať. Každý záznam je identifikovaný pomocou jedinečného SHA-1 hash čísla, ktoré sa priraďuje pri vytváraní záznamov.
Pre zobrazenie informácií o celej histórie zaznamenaných zmien v repozitári slúži príkaz:

    git log 

Zadaním príkazu do terminálu pre zvolený adresár s projektom Git sa zobrazí číslo hash, informácie o užívateľa, ktorý daný záznam vykonal a taktiež dátum záznamu. Pre odvrátenie záznamu je dôležité práve číslo hash daného záznamu.
Git umožňuje prezerať stav súborov, vykonať testy na súboroch a dokonca aj editovať súbory bez ovplyvnenia aktuálny stav repozitára. Na tento účel slúži príkaz:

    git checkout <SHA-1 hash>

Súbory v repozitári sa tak zobrazia v tvare, akom boli pri vytvorení zvoleného záznamu. V tomto stave sa ukazovateľ HEAD presunie v histórii smerom späť na starší záznam. Vrátenie späť na aktuálny záznam repozitára sa vykoná príkazom:

    git checkout master

Vrátenie repozitára do stavu pred posledným záznamom je možné vykonať rôznymi spôsobmi. Najjednoduchší spôsob ponúka zabudovaný príkaz v systéme Git:

    git revert HEAD
    git revert <hash posledneho zaznamu>

Oboma príkazmi sa vráti stav repozitára na predošlí záznam v poradí.

Záver

Cieľom bakalárskej práce bolo oboznámiť sa s možnosťami nástrojov softvérového inžinierstva pri vývoji softvérových produktov, ako sú systémy pre správu zdrojových kódov a nástroje pre Continuous Integration a Continuous Deployment. Získané teoretické poznatky sme si v práci overili nakonfigurovaním služieb pre správu verzií Git a nástrojov pre vytváranie CI/CD pipeline-ov pre spustenie, testovanie a nasadenie vyvíjaných aplikácií. Nástroje CI/CD boli spojené s repozitármi služby Gitlab a Gogs, pomocou ktorého sme vykonali reálne nasadenie aktualizácií web rozhrania navrhnutého v jazyku PHP, ktoré je distribuované zo serveru umiestneného na Ústave aplikovanej informatiky, automatizácie a mechatroniky MTF STU. Server je v správe vedúceho bakalárskeho projektu.

V prvej kapitole práce sme sa zaoberali princípmi tvorby softvérového produktu. Opisom životného cyklu vývoja softvéru sme si osvojili teoretické poznatky potrebné pre ich úspešné nasadenie. Opis krokov pri vývoji produktu od plánovania až po výslednú údržbu sú hlavnou časťou prvej kapitoly. Modely vývoja softvérových diel, podľa ktorých je možné počas vývoja produktov postupovať, sú dôležité pre úspešné dokončenie vyvíjaných softvérových produktov v správnom tvare a predom dohodnutej časovej, či finančnej lehote.

V ďalšej kapitole opisujeme systémy pomáhajúce vývojárom softvérových produktov pri vytváraní projektov. Systémy pre správu verzií (VCS) sú vytvorené za účelom vytvárania záznamov vyvíjaného zdrojového kódu počas celej doby vývoja. Vytvorí sa tak prehľad o celej histórii vytváraného produktu a systémy umožnia jednoduchú spoluprácu viacerých členov vývojárskeho tímu. V práci sme používali VCS prostredia Git. Odskúšali sme funkcie nástrojov Gogs a Gitlab pre prácu s Git. Ďalej sme zistili akým spôsobom fungujú nástroje pre CI/CD - Jenkins a Gitlab CI v spolupráci s repozitármi zvolených nástrojov. Nástroje pre Continuous Integration a Continuous Deployment napomáhajú vývojárom uľahčiť a urýchliť vývoj softvérových produktov pomocou automatizovaných pipelinov, ktoré dokážu overiť správne fungovanie každej verzie produktu.

Opis implementácie a praktickej časti práce sa nachádza v poslednej kapitole práce. Všetky potrebné nástroje sme nainštalovali cez virtuálne prostredie Docker, ktoré ponúka možnosť spustenia softvérov pomocou kontajnerizácie. Nainštalované softvéry VCS - Gogs, Gitlab a nástroje CI/CD - Jenkins a Gitlab CI boli nakonfigurované pre ich správne fungovanie. Nástroje CI/CD vytvorením spojenia pomocou SSH spolupracovali s repozitárom služieb pre správu zdrojových kódov, a tak žiadna zmena zaznamenaná do repozitára nezostala bez povšimnutia nástrojom CI/CD. Vždy sa vykonal zvolený pipeline skript, podľa ktorého sa zaznamenaný kód spustil, testoval prípadne aj nasadil.

V bakalárskej práci sa úspešne splnili všetky očakávania a zistili možnosti automatizovaných CI/CD pipelinov. Vytvorením vhodných pipelinov v spolupráci s repozitármi služby Gitlab sa zefektívnil a urýchlil proces nasadenie web rozhrania eXam a získali sme vhodné poznatky pre budúcu prácu a vývoj softvérových produktov.

Zoznam použitej literatúry

[1] Tutorialspoint. SDLC. url: https://www.tutorialspoint.com/sdlc/index.htm (cit. 19. 12. 2019).

[2] MORAVČÍK O. VASKÝ J. MIŠÚT M. Softvérová technika. STU Bratislava, 1997. isbn: 80-227-09434-4.

[3] Ian Sommerville. Software Engineering. Pearson, 2010. isbn: 9780137053469.

[4] Bieliková M. Šimko J. Šimko M. Softvérové inžinierstvo v otázkach a odpovediach. SPEKTRUM STU, 2017. isbn: 978-80-227-4669-4.

[5] Atlassian. What is version control. url: https://www.atlassian.com/git/tutorials/what-is-version-control (cit. 21. 12. 2019).

[6] Git. Getting Started - About Version Control. url: https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control (cit. 21. 12. 2019).

[7] GNU. CVS—Concurrent Versions System. url: https://www.gnu.org/software/trans-coord/manual/cvs/cvs.html#What-is-CVS_003f (cit. 24. 12. 2019).

[8] Atlassian. What is Git. url: https://www.atlassian.com/git/tutorials/what-is-git (cit. 23. 12. 2019).

[9] Git. What is Git? url: https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F (cit. 23. 12. 2019).

[10] Git. Git Commands. url: https://git-scm.com/docs/git (cit. 27. 12. 2019).

[11] Git. Git Branching. url: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging (cit. 23. 03. 2020).

[12] Atlasian. git fetch. url: https://www.atlassian.com/git/tutorials/syncing/git-fetch (cit. 23. 03. 2020).

[13] Gogs. Gogs Documentation. url: https://gogs.io/docs (cit. 25. 12. 2019).

[14] Gitlab. Gitlab Docs. url: https://docs.gitlab.com/ce/README.html (cit.01. 02. 2020).

[15] Jenkins. Jenkins Pipeline. url: https://jenkins.io/doc/book/pipeline/ (cit. 24. 12. 2019).

[16] Edureka. Jenkins for continous integration. url: https://www.edureka.co/blog/what-is-jenkins/ (cit. 27. 12. 2019).

[17] GitLab. GitLab CI/CD. url: https://docs.gitlab.com/ce/ci/ (cit. 04. 02. 2020).

[18] Git. Download for Linux and Unix. url: https://git-scm.com/download/linux (cit. 25. 02. 2020).

[19] Opensource.com. What is Docker? url: https://opensource.com/resources/what-docker (cit. 27. 04. 2020).

[20] Ivan Bernát. Docker a jeho použitie pri kontajnerizácii. url: https://magazin.kpi.fei.tuke.sk/2019/02/docker-a-jeho-pouzitie-pri-kontajnerizacii/ (cit. 27. 04. 2020).

[21] Gitlab. Install GitLab with Docker. url: https://docs.gitlab.com/ce/install/docker.html (cit. 21. 02. 2020).

[22] Jamal Shahverdiyev. Jenkins and Gogs integration with webhook. url: https://jamalshahverdiev.wordpress.com/2018/02/09/jenkins-gogs-integration-with-webhook/ (cit. 04. 03. 2020).

[23] Jenkins. Getting started with Pipeline. url: https://www.jenkins.io/doc/book/pipeline/getting-started/#defining-a-pipeline (cit. 29. 04. 2020).

[24] Linux man page. rsync. url: https://linux.die.net/man/1/rsync (cit.27. 04. 2020).

[25] Gitlab. Job artifacts. url: https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html (cit. 27. 04. 2020).

[26] Gitlab. Backing up and restoring GitLab. url: https://docs.gitlab.com/ee/raketasks/backup_restore.html (cit. 22. 03. 2020).

[27] Atlassian. Undoing Commits Changes. url: https://www.atlassian.com/git/tutorials/undoing-changes (cit. 11. 05. 2020).