SYST´EM PRO PR˚UBˇEˇZNOU INTEGRACI SOFTWARU

(1)

SYST´ EM PRO PR˚ UBˇ Eˇ ZNOU INTEGRACI SOFTWARU

Diplomov´ a pr´ ace

Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie

Autor práce: Bc. Vojtˇech T˚uma Vedouc´ı práce: Mgr. Jiˇr´ı Vraný, Ph.D.

(2)

SYSTEM FOR SOFTWARE CONTINUOUS INTEGRATION

Diploma thesis

Study programme: N2612 – Electrotechnics and informatics Study branch: 1802T007 – Information technology

Author: Bc. Vojtˇech T˚uma Supervisor: Mgr. Jiˇr´ı Vran´y, Ph.D.

(3)

Tento list nahrad’te

origin´ alem zad´ an´ı.

(4)

Prohl´ aˇ sen´ı

Byl jsem seznámen s t´ım, ˇze na mou diplomovou práci se plnˇe vzta- huje zákon ˇc. 121/2000 Sb., o právu autorském, zejména § 60 – ˇskoln´ı d´ılo.

Beru na vˇedom´ı, ˇze Technická univerzita v Liberci (TUL) neza- sahuje do mých autorských práv uˇzit´ım mé diplomové práce pro vnitˇrn´ı potˇrebu TUL.

Uˇziji-li diplomovou pr´aci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o t´eto skuteˇcnosti TUL;

v tomto pˇr´ıpadˇe má TUL právo ode mne poˇzadovat úhradu náklad˚u, které vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcné výˇse.

Diplomovou práci jsem vypracoval samostatnˇe s pouˇzit´ım uvedené literatury a na základˇe konzultac´ı s vedouc´ım mé diplomové práce a konzultantem.

Souˇcasnˇe ˇcestnˇe prohlaˇsuji, ˇze tiˇstˇen´a verze pr´ace se shoduje s elek- tronickou verz´ı, vloˇzenou do IS STAG.

Datum:

Podpis:

(5)

Abstrakt

Práce se zabývá problematikou pr˚ubˇeˇzné integrace softwaru a obecnˇe vývoje softwaru v týmu. V úvodu práce jsou podrobnˇe popsány vˇsechny nástroje pr˚ubˇeˇzné integrace. Tedy verzovac´ı systémy, testován´ı softwaru a sestavovac´ı skripty. V druhé ˇcásti práce je popsán návrh a implementace vlastn´ıho systému pro pr˚ubˇeˇznou integraci. Popis systému se skládá ze 3 ˇcást´ı. Prvn´ı ˇ

cást popisuje grafické rozhran´ı pro ovládán´ı celého systému. Druhá ˇ

cást se zamˇeˇruje na popis vlastn´ıho ˇreˇsen´ı pro vytváˇren´ı sestavovac´ıch skript˚u. Posledn´ı ˇcást struˇcnˇe popisuje komponentu auto- rizujic´ı uˇzivatele skrze protokol SSH ke vzdáleným repozitáˇr˚um.

C´ılem práce je, aby ˇctenáˇr porozumˇel a nauˇcil se pouˇz´ıvat autorem navrˇzený systém pro pr˚ubˇeˇznou integraci softwaru.

Kl´ıˇcová slova: pr˚ubˇeˇzná integrace, verzovac´ı systémy, testován´ı softwaru, sestavovac´ı skripty

(6)

Abstract

Work is focused on prolematics of continuos integration and team software development. Introduction describes all tools of continuos integration. Means version control system, software testing and build scripts. In the second part of work there is described own implementation of system for continuous integration. Description of system is divided in to three parts. Graphical interface for controling whole system id described in the first part. Second part describes own implementation of creating buildscripts. The last part describes component which authorize users to access remote repositories throw SSH protocol. Mail goal of work is to explaim how created system for continuos integration works and explaim to reader how to use it.

Keywords: continuos integration, version control systems, software testing, build scripts

(7)

Podˇ ekov´ an´ı

Chtˇel bych podˇekovat Martinu Takáˇcovi za pomoc pˇri vytváˇren´ı systému. Dále bych chtˇel podˇekovat vedouc´ımu práce Mgr. Jiˇr´ımu Vranému Ph.D., který se mé práce ujal. V neposledn´ı ˇradˇe chci podˇekovat svým bl´ızkým, kteˇr´ı mˇe podporovali bˇehem studia.

(8)

Obsah

Seznam obr´azk˚u . . . 10

Seznam zkratek . . . 13

1 Uvod´ 14 2 Pr˚ubˇeˇzn´a integrace 16 2.1 Verzovac´ı syst´em . . . 17

2.1.1 Repozit´aˇr . . . 19

2.1.2 Zivotn´ı cyklus verzov´ˇ an´ı . . . 21

2.1.3 V´yvojov´e vˇetve . . . 24

2.1.4 Zachytn´e h´aky . . . 25

2.1.5 Uchov´av´an´ı historie zmˇen . . . 26

2.1.6 Dobré zvyky pro pouˇz´ıván´ı verzovac´ıch systém˚u . . . 28

2.2 Pˇredstavitel´e verzovac´ıch syst´em˚u . . . 29

2.2.1 GIT . . . 29

2.2.2 Mercurial . . . 30

2.2.3 Bazaar . . . 30

2.3 Sestavovac´ı syst´em . . . 31

2.4 Testov´an´ı . . . 32

3 N´avrh vlastn´ıho ˇreˇsen´ı 35 3.1 Sezn´amen´ı se s problematikou . . . 35

3.2 N´avrh vlastn´ıho ˇreˇsen´ı . . . 36

(9)

4 Vlastn´ı ˇreˇsen´ı 38

4.1 Hockej . . . 39

4.1.1 Sestavovac´ı skript . . . 39

4.1.2 Katalog . . . 40

4.1.3 Definice . . . 41

4.2 Prestacio . . . 42

4.2.1 Repozit´aˇre . . . 43

4.2.3 Hockej . . . 43

4.2.4 Uˇzivatelsk´e ´uˇcty . . . 43

4.3 Stas . . . 44

5 Návod na pouˇz´ıván´ı a praktické ukázky 46 5.1 Hockej . . . 46

5.1.1 Instalace . . . 46

5.1.2 Vytvoˇren´ı sestavovac´ıho skriptu . . . 46

5.1.3 Vytvoˇren´ı vlastn´ıho katalogu . . . 48

5.1.4 Uk´azka rozˇsiˇrov´an´ı definic . . . 50

5.1.5 Spuˇstˇen´ı . . . 51

5.2 Prestacio . . . 52

5.2.1 Instalace . . . 52

5.2.2 Repozit´aˇre . . . 52

5.2.4 V´ysledek sestavovac´ıho skriptu . . . 64

5.2.5 Katalogy Hockeje . . . 66

5.2.6 Uˇzivatelsk´e ´uˇcty . . . 67

6 Z´avˇer 69 6.1 Sloˇzitost vytvoˇren´ı syst´emu . . . 69

6.2 Intuitivnost ovl´ad´an´ı . . . 70

6.3 Celkov´a funkˇcnost a moˇzn´e vylepˇsen´ı . . . 70

(10)

6.4 Syst´em jako volnˇe ˇs´ıˇriteln´y software . . . 71 6.5 Zhodnocen´ı . . . 71

(11)

Seznam obr´ azk˚ u

2.1 Velikost pˇr´ınos˚u pˇri pokroku . . . 19

2.2 Repozit´aˇr a pracovn´ı kopie . . . 20

2.3 Synchronizace dvou repozit´aˇr˚u . . . 20

2.4 Synchronizace dvou repozit´aˇr˚u . . . 21

2.5 Rozkop´ırov´an´ı repozit´aˇre . . . 22

2.6 Odesl´an´ı zmˇen do repozit´aˇre . . . 22

2.7 Pˇrid´an´ı ostatn´ıch zmˇen a odesl´an´ı . . . 23

2.8 Navr´acen´ı zmˇen . . . 23

2.9 Viditelnost v´yvojov´ych vˇetv´ı . . . 24

2.10 Vytvoˇren´ı odnoˇze . . . 25

2.11 Pˇr´ıklad záchytných hák˚u . . . 26

4.1 Sch´ema syst´emu . . . 38

4.2 Hockej katalogy . . . 41

4.3 Hockej - skl´ad´an´ı definic . . . 42

4.4 Menu . . . 42

5.1 Seznam repozit´aˇr˚u . . . 53

5.2 Pˇridat repozit´aˇr . . . 53

5.3 Detail repozit´aˇre . . . 54

5.4 Zmˇeny v repozit´aˇri . . . 55

5.5 Detail zmˇeny . . . 55

5.6 Pˇrid´av´an´ı katalog˚u . . . 56

5.7 Pˇrid´av´an´ı definice . . . 57

(12)

5.8 Definice file . . . 58

5.9 Nastaven´ı definice . . . 59

5.10 Ruˇcnˇe upraven´a definice . . . 60

5.11 Propojen´ı definic . . . 60

5.12 Dialog vytvoˇren´ı pˇr´ıkazu . . . 60

5.13 Pˇr´ıkaz . . . 61

5.14 Uk´azka sestaven´ı . . . 61

5.15 Uk´azka sestaven´ı . . . 64

5.16 V´ysledek sestaven´ı . . . 66

5.17 Seznam katalog˚u . . . 66

5.18 Detail katalogu . . . 67

5.19 Seznam uˇzivatel˚u . . . 68

5.20 Detail uˇzivatele . . . 68

(13)

Seznam zkratek

CI Continuous integration(Pr˚ubˇeˇzn´a integrace) FTP File Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

SVN Subversion

XML eXtensible Markup Language

IDE Integrated Development Environment

SSH Secure Shell(protokol pro zabezpeˇcenou komunikaci)

(14)

1 Uvod ´

Pokud se ohlédneme do nejmladˇs´ıch dob naˇs´ı civilizace zjist´ıme, ˇze jiˇz praˇclovˇek pouˇz´ıval nástroje, aby si ulehˇcil svoji práci. Ve stˇredovˇeku si kaˇzdý kováˇr vyrábˇel nástroje, pomoc´ı kterých mohl vyrábˇet rychleji dokonalejˇs´ı výrobky. Dokázal vy- produkovat v´ıce kvalitn´ıch výrobk˚u a uspokojit lépe svoje zákazn´ıky. Vytváˇren´ı nástroj˚u, které ulehˇc´ı práci, se zdá tedy být výhodné. D´ıky mnohým z tˇechto nástroj˚u, dosáhla naˇse civilizace velké technické úrovnˇe.

Jedna z dneˇsn´ıch velmi d˚uleˇzitých profes´ı je programován´ı. I zde lidé hledaj´ı nástroje, pomoc´ı kterých by si svou práci mohli usnadnit. Na rozd´ıl od povolán´ı kováˇre se ovˇsem jedná o velmi mladou discipl´ınu. V posledn´ıch desetilet´ıch vˇsak z´ıskává na rozmachu. S pˇr´ıchodem prvn´ıho elektronkového poˇc´ıtaˇce ENIAC, který byl dokonˇcen v roce 1946, se mnohé zmˇenilo. V této dobˇe existovala pouze velmi ome- zená mnoˇzina vyj´ımeˇcnˇe nadaných jedinc˚u, kteˇr´ı dokázali naprogramovat funkˇcn´ı aplikaci. Pokud aplikaci vyv´ıjel jeden ˇci dva lidé, nebyl problém si práci rozdˇelit.

Dnes se programován´ı pˇribl´ıˇzilo mnohem vˇetˇs´ı skupinˇe lid´ı. Nyn´ı m˚uˇze na jednom projektu pracovat i nˇekolik des´ıtek programátor˚u. Pokud by kaˇzdý pracoval na jiné ˇcásti kódu, nenastal by ˇzádný problém a s trochou nadsázky by se projekt mohl vyv´ıjet bez omezen´ı. M˚uˇze se vˇsak stát, ˇze dva r˚uzn´ı lidé pracuj´ıc´ı na odliˇsných ˇcástech aplikace. Budou potˇrebovat upravit tu samou knihovnu, protoˇze v n´ı byla chyba. Zde m˚uˇze vznikout konflikt, jestliˇze oba neopravili knihovnu naprosto steným

(15)

zp˚usobem. Pokud se jedná o pˇridán´ı jednoho ˇrádku, tak problém nenastává. Pokud se vˇsak zmˇen´ı nˇekolik des´ıtek ˇrádk˚u v jedné knihovnˇe, je prakticky nemoˇzné práci obou správnˇe propojit a ovˇeˇrit správnou funkˇcnost.

Tato práce se zabývá problematikou práce v´ıce lid´ı na jednom projektu. Jak vytvoˇrit moˇznost pˇridat do existuj´ıc´ıho projektu novou funkcionalitu aniˇz by doˇslo k rozbit´ı té stávaj´ıc´ı.

(16)

2 Pr˚ ubˇ eˇ zn´ a integrace

Pro vysvˇetlen´ı pojmu pr˚ubˇeˇzná integrace (CI) je nejlepˇs´ı si uvést pˇr´ıklad. Mˇejme tedy za úkol vytvoˇrit novou vlastnost do jiˇz existuj´ıc´ıho webového projektu. Nejprve si uvedeme pˇr´ıklad postupu, kde bude pouˇzitý systém pr˚ubˇeˇzné integrace nebo jeho ˇcást´ı a posléze pˇr´ıklad, kdy nebude vyuˇzito ˇzádné ˇcásti pr˚ubˇeˇzné integrace.

Pokud nepouˇzijeme ˇzádné z ˇcást´ı pr˚ubˇeˇzné integrace, bude náˇs postup vˇetˇsinˇe programátor˚u velmi dobˇre známý. Otevˇreme souborový manaˇzer a zkop´ırujeme si existuj´ıc´ı kód projektu na sv˚uj poˇc´ıtaˇc. Následnˇe provedeme úpravy na r˚uzných kni- hovnách, do kterých pˇridáme nové vlastnosti pro náˇs projekt. Otevˇreme webový prohl´ıˇzeˇc a vyzkouˇs´ıme vˇsechny nové vlastnosti na lokáln´ım poˇc´ıtaˇci. Pokud vˇse funguje správnˇe, nakop´ırujeme pomoc´ı protokolu FTP(S) nebo protokolu SSH na server upravené soubory. Nyn´ı znovu zkontrolujeme ve webovém prohl´ıˇzeˇci, zda vˇsechny naˇse nové vlastnosti funguj´ı. Je–li souˇcást´ı nových vlastnost´ı i aktualizace databázového schématu, mus´ıme ruˇcnˇe databázi upravit. M˚uˇze zde nastat nˇekolik problém˚u. M˚uˇze to být zapomenutý upravený soubor, nezkontrolován´ı vˇsech ˇcást´ı, kterých se aktualizace týkala nebo nesmazán´ı vyrovnávac´ı pamˇeti, kde jsou stále uloˇzená stará data.

Nyn´ı pouˇzijeme nástroje pro pr˚ubˇeˇznou integraci, které pomáhaj´ı zamezit právˇe tˇemto chybám. V tomto pˇr´ıpadˇe budeme postupovat analogicky, ale budeme vyuˇz´ıvat nástroje, které nám práci ulehˇc´ı. Samotné nástroje budou popsány v dalˇs´ıch kapi-

(17)

tolách. Pro zkop´ırován´ı aktuáln´ıho kódu projektu na vlastn´ı poˇc´ıtaˇc vyuˇzijeme verzovac´ı systém, který vytvoˇr´ı pracovn´ı kopii projektu. Následnˇe provedeme úpravy v kódu. Pokud náˇs projekt obsahuje jednotkové ˇci jiné testy, nástroje tyto testy automaticky spust´ı pˇred odeslán´ım nového kódu na server. Pokud nˇekterý z test˚u bude hlásit chybný výsledek v´ıme, ˇze nová vlastnost naruˇsila jiˇz existuj´ıc´ı kód nebo nefunguje správnˇe. Verzovac´ı systém následnˇe odeˇsle na server vˇsechny soubory, které byly upraveny. Pokud aktualizace upravuje databázové schéma, tak i tyto zmˇeny jsou provedeny automaticky. Máme tedy mnohem vˇetˇs´ı ˇsanci úspˇechu, ˇze naˇse nová vlastnost bude správnˇe spuˇstˇena.

T´ımto by se dal velice krátce vysvˇetlit pojem pr˚ubˇeˇzná integrace. Nyn´ı si pop´ıˇseme jednotlivé ˇcásti, které by mˇel systém pro pr˚ubˇeˇznou integraci podporovat.

2.1 Verzovac´ı syst´ em

Mˇejme situaci, kdy dva r˚uzn´ı lidé maj´ı za úkol do existuj´ıc´ıho projektu pˇridat sv˚uj vlastn´ı obsah. Tento projekt m˚uˇze být ku pˇr´ıkladu kniha. Nemus´ı se vˇzdy jednat o software. Kaˇzdý si tedy na zaˇcátku poˇr´ıd´ı kopii aktuáln´ı verze. Prvn´ı z nich do- konˇc´ı práci dˇr´ıve a na nˇekolik r˚uzných m´ıst v knize pˇridá náhodné mnoˇzstv´ı nových odstavc˚u a uprav´ı i ˇcásti p˚uvodn´ıho textu, protoˇze obsahoval chyby. Druhý ˇclovˇek dokonˇc´ı práci jen o den pozdˇeji s t´ım, ˇze pˇripsal jeden odstavec na konec knihy.

Nejjednoduˇsˇs´ı ˇreˇsen´ı je vz´ıt práci ˇclovˇeka, který vytvoˇril v´ıce textu a jehoˇz práce je v´ıce rozprostˇrena v celé knize a k n´ı pˇripojit nový odstavec na konec, který vytvoˇril druhý ˇclovˇek. Nyn´ı ˇzádný problém nenastává, protoˇze oba se dokázali dohodnout, co kdo udˇelal. Bohuˇzel druhý z nich zapomnˇel ˇr´ıci, ˇze opravil na zaˇcátku knihy úvod, bez kterého odstavec na konci knihy nemá smysl. Knihu vydaj´ı a tento nedostatek

(18)

objev´ı aˇz poté, co se zaˇcne kniha prodávat. ˇCtenáˇri si povˇsimnou, ˇze posledn´ı ka- pitola nedává smysl. Vydavatel knihy tedy zjist´ı, ˇze je v knize chyba a vydá nový výtisk. Bohuˇzel, uˇz vytiskl nˇekolik stovek výtisk˚u, které obsahuj´ı chybu. Zkus´ı tedy nalézt lepˇs´ı proces kontrolován´ı práce.

Kniha se nyn´ı opˇet nacház´ı v aktuáln´ım stavu (vˇsichni maj´ı stejnou kopii). Edi- tor˚u knihy zaˇcne pˇribývat a zjist´ı, ˇze je lepˇs´ı si kaˇzdý den poslat seznam zmˇen, které kaˇzdý z nich provedl. Tento systém je uˇz lépe udrˇzitelný, protoˇze jednou za den si vˇsichni do svého rozpracovaného dokumentu nakop´ıruj´ı nové ˇcásti. Dalˇs´ım pokro- kem je vyuˇz´ıván´ı sd´ıleného disku, kdy existuje jeden soubor na sd´ıleném úloˇziˇsti a kaˇzdý do nˇej m˚uˇze naráz pˇrisp´ıvat. Jelikoˇz je aktuáln´ı práce vˇsech pˇrispˇevatel˚u na jednom m´ıstˇe, má smysl dokument v pravidelných ˇcasových intervalech zálohovat.

T´ım z´ıskáme historii dokumentu a m˚uˇzeme se zpˇetnˇe pod´ıvat ,v jakém stavu byl dokument minulý týden.

Pokud k dosaˇzenénu pokroku pˇridáme moˇznost kontrolovat, kdo jaké zmˇeny udˇelal a v jaký ˇcas, tak se dostáváme na úroveˇn nejzákladnˇejˇs´ıho verzovac´ıho systému.

Takovým systémem m˚uˇze být napˇr´ıklad Subversion[1] (oznaˇcován zkratkou SVN), který za nás provád´ı základn´ı operace jako pˇrekop´ırován´ı aktuáln´ı verze ze serveru na lokáln´ı poˇc´ıtaˇc a zároveˇn i nahrán´ı upravené verze zpˇet na server. Ke kaˇzdé zmˇenˇe je moˇzné pˇridat i text, který bude popisovat provedenou zmˇenu. Pokud udˇeláme zmˇenu a nahrajeme ji na server, ostatn´ı uˇzivatelé si ji mohou stáhnout k sobˇe na lokáln´ı poˇc´ıtaˇc a pokud se nejedná o kolizn´ı zmˇenu (dva pˇrispˇevatelé naráz upravili stejný ˇrádek) bude zmˇena automaticky zakomponována. Nyn´ı máme jiˇz velice silný nástroj, který dokáˇze zajistit automatické pˇripojován´ı zmˇen mezi pˇrispˇevateli a za- znamenávat, kdo co upravil. Poˇrád se ovˇsem jedná o chytˇrejˇs´ı sd´ılený disk, který má vˇse d˚uleˇzité uloˇzené na jednom m´ıstˇe, proto se tento systém nazývá centralizovaný.

Vˇse je uloˇzeno na jednom centralizovaném úloˇziˇsti, ke kterému mus´ıme m´ıt stálé pˇripojen´ı, pokud chceme projekt upravovat.

(19)

Vˇsechny tyto nedostatky odstraˇnuj´ı distribuované verzovac´ı systémy[2]. Pˇrináˇsej´ı moˇznost pracovat bez pˇr´ımého pˇripojen´ı k centralizovanému úloˇziˇsti. Zmˇeny se mohou hromadit na lokáln´ım poˇc´ıtaˇci a odeslat je na centráln´ı úloˇziˇstˇe aˇz v dobˇe, kdy je moˇznost se k nˇemu pˇripojit. M˚uˇzeme tedy udˇelat nˇekolik zmˇen a ty napˇr´ıklad na konci týdne odeslat, coˇz ovˇsem nen´ı dobrý zvyk, jak bude popsáno dále. Nejvˇetˇs´ı výhodou je distribuce zmˇen mezi vˇsemi pˇrispˇevateli. Kaˇzdá instance (kopie, klon) má v sobˇe uloˇzené zmˇeny, které provedli ostatn´ı pˇrispˇevatelé. Je moˇzné tedy odváˇznˇe ˇr´ıci, ˇze nemá smysl vytváˇret speciáln´ı zálohy na centráln´ım úloˇziˇsti, protoˇze na vˇsech poˇc´ıtaˇc´ıch je záloha kompletnˇe uloˇzená. Mezi nejznámˇejˇs´ı zástupce distribuovaných systém˚u patˇr´ı GIT, Mercurial(Hg) a Bazzar(Bzr).

Obr´azek 2.1: Velikost pˇr´ınos˚u pˇri pokroku

2.1.1 Repozit´ aˇ r

Nyn´ı knihu z prvn´ıho pˇr´ıkladu nahrad´ıme za aplikaci, která obsahuje nˇekolik soubor˚u. Soubory mus´ı být nˇekde uloˇzeny. U verzovac´ıch systém˚u se toto m´ısto nazývá repozitáˇr. Jedná se o adresáˇr, kde jsou ve speciáln´ım formátu uloˇzeny vˇsechny soubory, které jsou verzované (spravované verzovac´ım systémem). Správnˇe nen´ı moˇzné do repozitáˇre pˇristoupit a ruˇcnˇe zmˇenit jeho obsah. M˚uˇzeme si ho pˇredstavit jako bal´ık dat, který obsahuje námi vloˇzený obsah a doprovodná data, která popisuj´ı jednotlivé zmˇeny provedené na datech.

(20)

V pˇr´ıpadˇe, ˇze nepracujeme v týmu a chceme pouze ukládat historii projektu, staˇc´ı nám lokáln´ı repozitáˇr. Ten leˇz´ı na lokáln´ım poˇc´ıtaˇci a zpravidla k nˇemu má pˇr´ıstup pouze uˇzivatel na daném poˇc´ıtaˇci. Aby bylo moˇzné data v repozitáˇri upravovat, mus´ıme si vytvoˇrit pracovn´ı kopii repozitáˇre, ve které m˚uˇzeme provádˇet zmˇeny, které opˇet následnˇe nahrajeme do repozitáˇre. Ten zmˇenu zaznamená a uloˇz´ı si ji do své historie.

Obr´azek 2.2: Repozit´aˇr a pracovn´ı kopie

Práce v týmu ovˇsem vyˇzaduje tyto repozitáˇre synchronizovat. Repozitáˇre mezi sebou dokáˇz´ı komunikovat a odes´ılat si mezi sebou zmˇeny. Je tedy moˇzné propojit dva repozitáˇre, které si mezi sebou budou odes´ılat zmˇeny.

Obr´azek 2.3: Synchronizace dvou repozit´aˇr˚u

Toto se ovˇsem stává nepraktické, kdyˇz se zvyˇsuje poˇcet repozitáˇr˚u a vzniká tˇeˇzce udrˇzitelná infrastruktura. Proto se zavád´ı myˇslenka sd´ıleného repozitáˇre, se kterým se vˇsechny ostatn´ı repozitáˇre aktualizuj´ı. Tento repozitáˇr by mˇel být na veˇrejném m´ıstˇe, kam maj´ı vˇsichni uˇzivatelé pˇr´ıstup, aby se s n´ım mohli co nejˇcastˇeji synchronizovat. V praxi se toto ˇreˇsen´ı ukazuje jako nejlepˇs´ı.

(21)

Obr´azek 2.4: Synchronizace dvou repozit´aˇr˚u

Repozitáˇre, které nejsou sd´ılené se nazývaj´ı lokáln´ı nebo uˇzivatelské. Pro zjed- noduˇsen´ı dále v práci budou tyto repozitáˇre komponovány jako souˇcást uˇzivatele a budeme uvaˇzovat, ˇze uˇzivatel komunikuje se sd´ıleným repozitáˇrem právˇe skrze sv˚uj lokáln´ı repozitáˇr.

2.1.2 Zivotn´ı cyklus verzov´ ˇ an´ı

Pokud se zamˇeˇr´ıme na nejpokroˇcilejˇs´ı distribuované verzovac´ı systémy, vˇsechny maj´ı velice podobný ˇzivotn´ı cyklus. Základem je vytvoˇren´ı repozitáˇre, který je pˇr´ıstupný vˇsem pˇrispˇevatel˚um. Pro firemn´ı projekty je dobré ho um´ıstit na sd´ılený disk a zpˇr´ıstupnit ho poˇzadovaným uˇzivatel˚um. Nen´ı problém se vˇsak pˇripojit ke vzdálenému repozitáˇri promoc´ı protokolu SSH nebo HTTPS i vnˇe firemn´ı s´ıtˇe. Vˇetˇsina distri- buovaných verzovac´ıch systém˚u má jiˇz pˇripravené rozhran´ı, které implementaci této komunikaci zajiˇst’uje. Existuj´ı dva moˇzné scénáˇre pˇri vytváˇren´ı repozitáˇre:

• Obsah (kód) jiˇz existuje a repozitáˇre bude obsahovat nˇejaká data

• Vytvoˇr´ıme prázdný repozitáˇr, který následnˇe napln´ıme obsahem

Na základˇe situace vytvoˇr´ıme nový repozitáˇr, který je prázdný nebo inicializu- jeme repozitáˇr nad jiˇz existuj´ıc´ım kódem. V obou situac´ıch se vlastnˇe jedná o vy-

(22)

tvoˇren´ı prázdného repozitáˇre, do kterého se následnˇe nahraj´ı data.

Obrázek 2.5: Rozkop´ırován´ı repozitáˇre

Poˇzadován´ı uˇzivatelé si následnˇe vytvoˇr´ı kopie sd´ıleného repozitáˇre.

Nyn´ı uˇz má kaˇzdý uˇzivatel vlastn´ı kopii a m˚uˇze vytváˇret zmˇeny. Aˇz uzná za vhodné, tak odeˇsle seznam svých zmˇen do sd´ıleného repozitáˇre. Nejlepˇs´ı je pos´ılat zmˇeny co nejˇcastˇeji, aby nedocházelo ke zbyteˇcnˇe velkému mnoˇzstv´ı konflikt˚u. Nejdˇr´ıve systém zkontroluje, zda nejsou nové zmˇeny ve sd´ıleném repozitáˇri od jiných uˇzivatel˚u a pokud nejsou, tak zmˇeny odeˇsle.

Obrázek 2.6: Odeslán´ı zmˇen do repozitáˇre

Pokud nˇejaký jiný uˇzivatel udˇelal zmˇenu, která jeˇstˇe nen´ı v lokáln´ım repozitáˇri zahrnuta, tak se nahrán´ı do sd´ıleného repozitáˇre neprovede. Systém upozorn´ı na vznik konfliktu a bude po nás poˇzadovat staˇzen´ı zmˇen od ostatn´ıch uˇzivatel˚u. Pˇred odeslán´ım mus´ıme vlastn´ı zmˇeny spojit se zmˇenami, které provedli ostatn´ı uˇzivatelé

(23)

a výsledek následnˇe odeslat do sd´ıleného repozitáˇre.

Obrázek 2.7: Pˇridán´ı ostatn´ıch zmˇen a odeslán´ı

Jednou z posledn´ıch d˚uleˇzitých událost´ı je navrácen´ı zmˇen. Pokud nˇejaký uˇzivatel udˇelá opravu, která rozbije funkˇcnost aplikace, je nutné se vrátit o jednu nebo nˇekolik verz´ı zpˇet. Jedná se vlastnˇe o klasickou zmˇenu v kódu s t´ım, ˇze zmˇen´ıte kód do stavu, ve kterém jiˇz byl.

Obr´azek 2.8: Navr´acen´ı zmˇen

Jak znázorˇnuje obrázek 2.8, uˇzivatel odeslal do sd´ıleného repozitáˇre 3 zmˇeny a kaˇzdé zmˇenˇe odpov´ıdá stav aplikace. Zmˇena C dostala aplikaci do stavu, kdy nefunguje. Uˇzivatel tedy chce vrátit aplikaci do stavu, kdy jeˇstˇe fungovala. Vezme tedy zmˇenu C zpˇet t´ım, ˇze dalˇs´ı zmˇenou neguje vˇse co se v C zmˇenilo.

(24)

2.1.3 V´ yvojov´ e vˇ etve

Jestliˇze verzovac´ı systém spravuje napˇr´ıklad internetový vyhledávaˇc stránek a uˇzivatel provede úpravu, kterou odeˇsle na sd´ılený repozitáˇr, úprava se okamˇzitˇe projev´ı v ostré verzi, která je viditelna vˇsem návˇstˇevn´ık˚um vyhledavaˇce na internetu. Po- kud by si ovˇsem uˇzivatel chtˇel pouze vyzkouˇset nový zp˚usob vyhledáván´ı nebo novou barvu pozad´ı, bylo by dobré m´ıt skrytou kopii, kterou uvid´ı pouze on. Tento problém se dá vyˇreˇsit vytvoˇren´ım dalˇs´ıho repozitáˇre, který nebude um´ıstˇen viditelnˇe na internetu. Ovˇsem pak mus´ıme ruˇcnˇe ˇreˇsit synchronizaci mezi repozitáˇri a t´ım se dostáváme na úroveˇn dokumentu na sd´ıleném disku.

Obrázek 2.9: Viditelnost vývojových vˇetv´ı

Proto verzovac´ı systémy pˇricházej´ı s moˇznost´ı zakládat vývojové vˇetve. Umoˇzˇnuj´ı m´ıt hlavn´ı vˇetev, která je napˇr´ıklad viditelná vˇsem uˇzivatel˚um internetu, ale k ostatn´ım vˇetv´ım se dostane pouze omezená skupina lid´ı.

Dalˇs´ım vyuˇzit´ım vývojových verz´ı je vytvoˇren´ı odnoˇze ciz´ıho software. Jestliˇze vámi obl´ıbené knihovnˇe scház´ı právˇe jedna pro vás kl´ıˇcová funkce, kterou v´ıte jak doprogramovat, ale nechcete celou knihovnu vytváˇret znovu, je pro vás nejlepˇs´ı moˇznost´ı vytvoˇrit odnoˇz jiˇz existuj´ıc´ı knihovny. Jedná se o zkop´ırován´ı posledn´ı verze knihovny do vlastn´ıho repozitáˇre, kde knihovnˇe dopln´ıte potˇrebné funkce. Po- kud autor knihovny vydá aktualizace, které pokud nekoliduj´ı s vaˇsimi zmˇenami, m˚uˇzete si aktualizaci pˇridat i do vlastn´ı knihovny.

(25)

Obr´azek 2.10: Vytvoˇren´ı odnoˇze

2.1.4 Zachytn´ e h´ aky

Pokud jeden z pˇrispˇevatel˚u provede nahrán´ı svých zmˇen do sd´ıleného repozitáˇre, bylo by dobré na to upozornit ostatn´ı. Nebo spustit automatickou sadu test˚u, která ovˇeˇr´ı, ˇze se zmˇenou nic nerozbilo.

Toto je moˇzné právˇe pomoc´ı záchytných hák˚u (hooks). Verzovac´ı systémy poskytuj´ı nˇekolik hák˚u, na které se daj´ı

”povˇesit“ r˚uzné skripty. Vˇetˇsinou lze zvolit, zda chceme skript spustit pˇred nebo po dané události. Jednotlivé háky jsou rozdˇeleny na lokáln´ı a serverové.

Lokáln´ı háky (v uˇzivatelksých repozitáˇr´ıch) se vˇetˇsinou pouˇz´ıvaj´ı na syntaktic- kou kontrolu zmˇen, které odes´ıláme. M˚uˇzeme zde kontrolovat, zda zmˇeny neobsahuj´ı zakomentovaný kód nebo lad´ıc´ı informace, které by mˇely z˚ustat pouze na lokáln´ım poˇc´ıtaˇci uˇzivatele.

Serverové háky (ve sd´ıleném repozitáˇri) naopak nacházej´ı vyuˇzit´ı pˇri spouˇstˇen´ı test˚u, sestavován´ı ˇci publikován´ı aktuáln´ı verze pro veˇrejnost. Jestliˇze napˇr´ıklad selˇze

(26)

testován´ı aplikace, budou vˇsichni uˇzivatelé upozornˇen´ı e-mailem. Záchytné háky jsou proto nejd˚uleˇzitˇejˇs´ı souˇcást´ı systém˚u pro pr˚ubˇeˇznou integraci. Bez nich nen´ı moˇzné automaticky reagovat na zmˇeny, které uˇzivatelé vytváˇrej´ı a následnˇe odes´ılaj´ı do sd´ıleného repozitáˇre.

Obrázek 2.11: Pˇr´ıklad záchytných hák˚u

Háky na rozd´ıl od soubor˚u nejsou sd´ılené, protoˇze v kaˇzdém repozitáˇri mohou být r˚uzné skripty spojené s r˚uznými událostmi. Nejˇcastˇeji je vˇetˇsina hák˚u um´ıstˇena na serveru, který provád´ı testován´ı, sestavovan´ı a podobné úkony.

2.1.5 Uchov´ av´ an´ı historie zmˇ en

Uchováván´ı historie je dalˇs´ı d˚uleˇzitou vlastnost´ı verzovac´ıch systém˚u. Historie obsahuje hned nˇekolik poloˇzek:

• Jm´eno uˇzivatele, kter´y zmˇenu provedl.

• Kdy zmˇenu uˇzivatel provedl.

• Popis zmˇeny, kterou uˇzivatel provedl.

(27)

• Posledn´ı zmˇena, ze kter´e uˇzivatel vych´azel.

• Obsah zmˇeny (co bylo odebr´ano a co pˇrid´ano).

• Vývojová vˇetev, ve které se zmˇena nacház´ı.

Systém má jistá omezen´ı, která chrán´ı celistvost historie. Nelze napˇr´ıklad provést zmˇenu bez popisuj´ıc´ı zprávy. Nelze vytvoˇrit zmˇenu, která má stejného pˇredka jako jiná zmˇena. Odes´ıláná zmˇena mus´ı m´ıt tedy v sobˇe zakomponované vˇsechny zmˇeny, které jiˇz v repozitáˇri jsou. Jméno uˇzivatele se m˚uˇze ovˇeˇrovat a t´ım zjistit, zda uˇzivatel má právo udˇelat zmˇenu.

Ukázka moˇzné podoby záznamu v historii (Mercurial):

changeset: 24:fd82dc9d5317

branch: default

tag: stable.2

user: Vojta T˚uma <ja@vojta-tuma.cz>

date: Wed Dec 18 21:07:13 2013 +0100 summary: Doc: added readme.md

Historie pak nalézá nˇekolik r˚uzných uplatnˇen´ı:

• Dok´aˇzeme zjistit, kdo provedl jakou zmˇenu.

• Dokáˇzeme zjistit, kdo je autorem kódu, který upravujeme.

• Dokáˇzeme zjistit, jaké zmˇeny nemáme zakomponované v lokáln´ım repozitáˇri.

• Dokáˇzeme se vracet ve zmˇenách. Uvést kód do dˇr´ıvˇejˇs´ı verze.

• Zobrazovat rozd´ıly mezi jednotliv´ymi zmˇenami.

(28)

• Kontrolovat produktivitu pr´ace program´ator˚u.

Shrnut´ım vˇsech tˇechto vlastnost´ı dostáváme velice silný nástroj, jak kontrolovat vývoj projektu a provádˇet jeho verzován´ı.

2.1.6 Dobr´ e zvyky pro pouˇ z´ıv´ an´ı verzovac´ıch syst´ em˚ u

Pˇri pouˇz´ıván´ı verzovac´ıch systém˚u existuje ˇrada dobrých zvyk˚u, které nám mohou velice ulehˇcit práci.

Asi nejd˚uleˇzitˇejˇs´ı z nich je ˇcasté synchronizován´ı kódu se sd´ıleným repozitáˇrem.

Pokud se nám bˇehem mˇes´ıce nahromad´ı zmˇeny od jiných uˇzivatel˚u a my se budeme snaˇzit tyto zmˇeny zakomponovat do naˇs´ı lokáln´ı verze, je témˇeˇr jisté, ˇze dojde ke konfliktu, který nám nedovol´ı zmˇeny automaticky zakomponovat. Mus´ıme tedy ruˇcnˇe urˇcit, jak se maj´ı zmˇeny propojit. Toto nastane, pokud dva r˚uzn´ı uˇzivatelé edituj´ı stejnou ˇcást kódu.

Jedna zmˇena by mˇela obsahovat pouze vˇeci, které spolu souvisej´ı. Nedodrˇzen´ı to- hoto pravidla vede k vytváˇren´ım dlouhých popis˚u zmˇen, které se stanou nepˇrehledné.

Vˇetˇsinou se vˇsak uchyluje k jednoduˇsˇs´ım zprávám jako ”velká zmˇena”, které jsou v podstatˇe nejhorˇs´ı, protoˇze o zmˇenˇe nic nevypov´ıdaj´ı.

Výsledkem zmˇeny by mˇel být opˇet funkˇcn´ı kód. Pokud v´ıme, ˇze nˇeco nefunguje naprosto správnˇe, tak nemá smysl vytváˇret zmˇenu. T´ım vznikaj´ı zmˇeny, do kterých se nelze vracet, protoˇze v danou dobu byla aplikace nefunkˇcn´ı. Ne vˇsak vˇzdy dokáˇzeme urˇcit funkˇcnost aplikace a provedeme nevˇedomˇe nefunkˇcn´ı zmˇenu.

(29)

Provád´ıme-li opravu jiˇz implementovaných funkc´ı a zároveˇn pˇridáváme nové funkce, snaˇz´ıme se nem´ıchat tyto dvˇe poloˇzky do jedné zmˇeny. Pokud ovˇsem na sobˇe nejsou funkˇcnˇe závislé.

Posledn´ım a nejd˚uleˇzitˇejˇs´ım zvykem jsou správnˇe popisky zmˇen. Popisek by mˇel obsahovat, jaké ˇcásti aplikace se zmˇena týká a co bylo opraveno nebo pˇridáno. Exis- tuje dokument [3], který ˇr´ıká jak popisky vytváˇret.

2.2 Pˇ redstavitel´ e verzovac´ıch syst´ em˚ u

Existuje mnoˇzstv´ı verzovac´ıch systém˚u, kde kaˇzdý vyniká v urˇcitých oblastech. Pro práci byly vybrány systémy 3 nejpouˇz´ıvanˇejˇs´ı [2] systémy a to GIT, Mercurial a Ba- zaar. Mezi dalˇs´ı známˇejˇs´ı pˇredstavitelé patˇr´ı verzovac´ıch systém˚u patˇr´ı BitKeeper, CVS, Perforce a Team Foundation Server. V dobˇe vytváˇren´ı práce existovalo celkem kolem 30 systém˚u pro verzován´ı.

2.2.1 GIT

GIT je systém p˚uvodnˇe vyvinutý pro správu zdrojového kódu pro jádro Linuxu.

Byl vytvoˇren Linusem Torvaldsem, který je zakladatelem Linuxu. Je zaloˇzen na sn´ımkován´ı kódu. Pokud uˇzivatel provede zmˇenu na souboru, tak se vytvoˇr´ı sn´ımek souboru, který reprezentuje stav souboru pˇred zmˇenou. Ukládaj´ı se tedy vˇzdy celé soubory. Hlavn´ı vlastnosti GIT jsou :

• Vytv´aˇren´ı sn´ımk˚u soubor˚u.

(30)

• Do zmˇen zaˇrazovat pouze jednotliv´e ˇr´adky.

• Moˇznost mˇenit historii.

• Nen´ı nutn´e stahovat celou historii.

• Nejv´ıce rozˇs´ıˇren´ı (nejvˇetˇs´ı podpora).

• Mezi pracovn´ı kopii a lok´aln´ım repozit´aˇrem je mezistupeˇn stash.

• Nevhodnˇe zvolen´e n´azvoslov´ı pˇr´ıkaz˚u.

2.2.2 Mercurial

Mercurial, také oznaˇcovaný jako HG, je výsledkem práce Matta Mackalla. Ten zaˇcal s vývojem ve stejnou dobu, jako se zaˇcal vyv´ıjet GIT. Vˇetˇsina systému je napsaná v jazyce Python, ˇc´ımˇz se stává multiplatformn´ı. Narozd´ıl od GIT pouˇz´ıvá pouze rozd´ılové zmˇeny, ˇc´ımˇz je ménˇe nároˇcný na datový provoz. Hlavn´ı vlastnosti Mercu- rial jsou:

• Intuitivn´ı n´azvy pˇr´ıkaz˚u.

• Jednoduchost.

• Zmˇeny pomoc´ı changeset (seznam zmˇen).

• Dobr´a podpora.

• Vyspˇelé grafické nástroje.

2.2.3 Bazaar

Bazaar je systém podporovaný firmou Canoncial, která stoj´ı za vývojem známe linuxové distribuce Ubuntu. Jedná se o multiplatformn´ı systém napsaný v jazyce

(31)

Python. Vývoj se opˇet datuje do stejného obdob´ı jako u dvou pˇredchoz´ıch systém˚u.

V posledn´ı dobˇe systém neprojevuje vˇetˇs´ı vývoj a je sp´ıˇs na ústupu. Nicménˇe z histo- rických d˚uvod˚u jsou pomoc´ı nˇeho verzovány projekty jako MySQL, MariaDB nebo GNOME.

2.3 Sestavovac´ı syst´ em

Ze zdrojového kódu je potˇreba vytvoˇrit spustitelnou aplikaci. Tento proces m˚uˇze být komplikovaný a ve výsledku se skládat z nˇekolik po sobˇe jdouc´ıch ˇcinnost´ı, které je nutné manuál vykonávat. At’ uˇz se jedná o kompilace, aktualizován´ı databáze nebo kop´ırován´ı soubor˚u, jde témˇeˇr vˇsechno zautomatizovat.

Vezmˇeme si opˇet pˇr´ıklad, na kterém si vysvˇetl´ıme jakou má úlohu sestavovac´ı systém s vyuˇzit´ım predchoz´ı znalosti o verzovac´ıch systémech. Mˇejme webovou aplikaci, kterou upravujeme na lokáln´ım poˇc´ıtaˇci a mus´ıme ji vystavit na veˇrejný web.

Ukol, kter´´ y nás potká vˇzdy, je kop´ırován´ı nových soubor˚u na úloˇziˇstˇe, kde bude aplikace veˇrejnˇe dostupná. Otevˇreme tedy libovolného správce soubor˚u a pˇrekop´ırujeme vˇsechna potˇrebná data. Pozdˇeji zjist´ıme, ˇze je lepˇs´ım ˇreˇsen´ım je vytvoˇren´ı skriptu, který úkony vykoná za nás. At’ uˇz kop´ırujeme soubory skrze FTP, SSH nebo jiný protokol, jistˇe nalezneme i nástroj, který toto bude dˇelat za nás. Jedn´ım ze základn´ıch nástroj˚u je synchronizace adresáˇr˚u. Výsledkem je tedy skript, který spust´ıme ruˇcnˇe pˇr´ıkazem.

Dalˇs´ım úkolem m˚uˇze být generován´ı jazykových pˇreklad˚u pro aplikace. Pokud pouˇz´ıváme gettext [5], je nutné soubor s pˇreklady kompilovat. Pˇri pˇridán´ı nových pˇreklad˚u je nutné soubor ruˇcnˇe zkompilovat a následnˇe ho nahrát spoleˇcnˇe s ostatn´ımi

(32)

soubory. Opˇet se jedná o vˇec, kterou m˚uˇzeme pˇridat do skriptu. Pˇridejme ho tedy na zaˇcátek pˇredchoz´ıho skriptu, aby se pˇreklady zkompilovali a následnˇe odeˇsleme vˇsechny soubory.

Pokud si chceme uchovávat zmˇeny v databázi, existuje moˇznost pouˇz´ıvat nástroj, který nám bude databázi automaticky aktualizovat. Nejjednoduˇsˇs´ı ˇreˇsen´ı je si ve svém projektu vytvoˇrit sloˇzku, do které budeme pˇridávat soubory obsahuj´ıc´ı napˇr´ıklad SQL pˇr´ıkazy, které se maj´ı nad databázi vykonat. Lepˇs´ıˇreˇsen´ı je opˇet vytvoˇrit skript, jenˇz nám tyto soubory sám spust´ı po nahrán´ı. Pˇridejme ho tedy opˇet na zaˇcátek naˇseho prvn´ıho skriptu, protoˇze je správné nejdˇr´ıv upravit databázi a následnˇe kód, který jiˇz poˇc´ıtá se zmˇenami v databázi.

Aplikace je hojnˇe pouˇz´ıvaná a nechceme, aby obsahovala chyby. Proto vyuˇz´ıváme i testován´ı, které se spouˇst´ı pomoc´ı nˇekolika nástroj˚u. Máme jednotkové testy, které v ideáln´ım pˇr´ıpadˇe pokrývaj´ı vˇetˇsinu kódu naˇs´ı aplikace. Tyto testy by mˇely být spuˇstˇeny pˇred nahrán´ım nového kódu na veˇrejný web. Opˇet je lze spouˇstˇet automaticky. Opˇet pˇridáme skript, který spust´ı vˇsechny testy.

Právˇe jsme pokryli znaˇcnou ˇcást ˇcinnost´ı, které jsme museli provádˇet ruˇcnˇe, ale nyn´ı je dˇelaj´ı skripty za nás. T´ım jsme vytvoˇrili automatický sestavovac´ı systém.

Jednotlivé ˇcásti systému sváˇzeme se záchytnými háky verzovac´ıho systému. Nejprve spust´ıme testy a jako posledn´ı nahrajeme aplikaci na veˇrejný web.

2.4 Testov´ an´ı

V pˇredchoz´ı kapitole bylo zd˚uraznˇeno testován´ı softwaru. Jedná se o ˇcinnost, jejiˇz návratnost nen´ı tak zˇrejmá, protoˇze testován´ı pˇr´ımo negeneruje novou funkˇcnost

(33)

aplikace, kterou by zákazn´ık mohl vidˇet. Nicménˇe zkuˇsenosti ukazuj´ı, ˇze vytváˇret testy má smysl[6].

Dobrým pˇr´ıkladem m˚uˇze být klasický internetový obchod. Zde je kl´ıˇcovou vlastnost´ı moˇznost dokonˇcen´ı objednávky. Firma vytvoˇr´ı pro zákazn´ıka aplikaci, která bude prodávat jeho produkty na internetu. Jiˇz pˇri vývoji nˇekolikrát zkouˇs´ı, zda jde dokonˇcit objednávka. Kdyˇz vˇse funguje správnˇe, tak produkt zákazn´ıkovi pro- daj´ı. Uplyne jistá doba a zákazn´ık, chce vytvoˇrit dalˇs´ı funkˇcnost. Firma pˇridá nové funkce a opˇet ovˇeˇr´ı zda, objednávka funguje, protoˇze se jednalo o velké zásahy.

Vˇse se stále provád´ı ruˇcnˇe a kaˇzdý test zabere neopomenutelnou dobu. Za rok se zákazn´ık opˇet ozve a chce vytvoˇrit zas´ılán´ı vánoˇcn´ıch poukázek. Term´ın na reali- zaci je velmi krátký, a proto firma narychlo nasazuje odes´ılán´ı poukázek. Bohuˇzel aktualizace vyˇzadovala úpravu komponenty, která odes´ılá e-maily, takˇze k odeslán´ı e-mailu je nutný dalˇs´ı povinný parametr. S t´ım ovˇsem nepoˇc´ıtá odes´ılán´ı potvrzen´ı objednávky. A výsledkem je, ˇze se neodes´ılaj´ı e-maily po dokonˇcen´ı objednávky, coˇz je kl´ıˇcová vlastnost. Pokud by existoval test na odes´ılán´ı e-mailu s potvrzen´ım objednávky, nemohlo by k tomuto doj´ıt. Pˇri spuˇstˇen´ı vˇsech test˚u by doˇslo k chybˇe a sestavovac´ı systém by nedovolil aktualizovat aplikaci.

Existuje nˇekolik zp˚usob˚u testov´an´ı [9]:

• Programátorské - Dva programátoˇri si navzájem kontroluj´ı kód. Jeden kód vytvoˇr´ı, druhý kód zkontroluje a vytvoˇr´ı pro kód testy (zpravidla ruˇcnˇe otestuje funkce). Jedná se o nejménˇe nákladné a nejv´ıce úˇcinné testován´ı.

• Jednotkové - Následuj´ı po programátorském testován´ı. Testovanou jednotkou lze rozumˇet jako oddˇelitelnou ˇcást aplikace, na kterou se vytvoˇr´ı test, jenˇz ovˇeˇr´ı jej´ı funkˇcnost. Aplikovat jednotkové testy do existuj´ıc´ıho projektu je vˇetˇsinou velmi sloˇzité. Pokud se tyto testy aplikuj´ı jiˇz pˇri vývoji aplikace, vedou k vytváˇren´ı kvalitn´ı kódu.

(34)

• Funkˇcn´ı - Ovˇeˇruj´ı, zda je aplikace schopná plnit úkoly, pro které byla navrˇzena a zda jsou splnˇeny vˇsechny poˇzadavky zákazn´ıka. V pˇr´ıpadˇe internetového obchodu by testován´ı objednávky spadalo právˇe do funkˇcn´ıch test˚u.

• Integraˇcn´ı - Jedna z podmnoˇzin funkˇcn´ıho testován´ı. Kontroluje se správná ko- munikace komponent aplikace mezi sebou, ale i napˇr´ıklad komunikaci s operaˇcn´ım systémem nebo hardwarem. U menˇs´ıch projekt˚u lze tuto ˇcást vynechat.

• Uˇzivatelské - Aplikaci by mˇel pochopit i nˇekdo jiný neˇz jej´ı vývojáˇr. Vezme se tedy náhodný ˇclovˇek a zadaj´ı se mu úkoly, které má s aplikac´ı vykonat. Pokud je nedokáˇze dokonˇcit ani s návodem, je vˇetˇsinou aplikace ˇspatnˇe navrˇzená.

T´ım je ukonˇcena motivaˇcn´ı ˇcást, proˇc pouˇz´ıvat nástroje pr˚ubˇeˇzné integrace.

(35)

3 N´ avrh vlastn´ıho ˇ reˇ sen´ı

C´ılem práce bylo seznámen´ı se s problematikou verzovac´ıch systém˚u a nástroji pr˚ubˇeˇzné integrace. Následnˇe dané znalosti uplatnit pro návrh vlastn´ıho systému pr˚ubˇeˇzné integrace, který je zamˇeˇren na vývoj aplikac´ı v prostˇred´ı www aplikac´ı.

Tento návrh mˇel být nakonec prakticky implementován.

3.1 Sezn´ amen´ı se s problematikou

Autor práce jiˇz pˇred vytvoˇren´ım diplomové práce mˇel zkuˇsenost s pouˇz´ıvám verzovac´ıch systém˚u. Nejv´ıce byl seznámen s verzovac´ım systémem Mercurial. Bylo nutné vylepˇsit znalosti o systému GIT a Bazaar.

GIT jako nejpouˇz´ıvanˇejˇs´ı verzovac´ı systém poskytuje ˇsirokou ˇskálu dokumentaˇcn´ıch materiálu. Existuje nˇekolik webových aplikac´ı, které umoˇzˇnuj´ı správu repozitáˇre skrze vzdálený pˇr´ıstup. Inspirovat se je moˇzné napˇr´ıklad na projektu GitHub [7], který poskytuje jedno z nejlépe zpracováných rozhran´ı pro správu repozitáˇre pomoc´ı grafického rozhran´ı.

Stejnˇe tak Mercuriál je velice dobˇre zdokumentovaný systém. Mezi nejznámˇejˇs´ı grafické nástavby patˇr´ı HgTurtoise, který poskytuje vˇsechny potˇrebné vlastnosti pro celkovou správu repozitáˇre. Autorova znalost Mercurialu vˇsak postaˇcuje pro potˇreby,

(36)

které bude výsledný systém obsahovat.

U systému Bazaar se ukázalo, ˇze se jiˇz nadále aktivnˇe nevyv´ıj´ı, a proto od jeho implementace do výsledného systému bylo upuˇstˇeno. Posledn´ı aktualizace Bazaaru byla podle domovské stránky projektu [4] provedena v záˇr´ı roku 2013 a nadále se neplánuje jeho dalˇs´ı vývoj.

Seznámen´ı se s nástroji pr˚ubˇeˇzné integrace nebo celými systémy bylo obt´ıˇznˇejˇs´ı.

Existuje nˇekolik des´ıtek systém˚u, které poskytuj´ı nástroje pro pr˚ubˇeˇznou integraci.

Liˇs´ı se v platformách, licenc´ıch, podpoˇre pro IDE a ostan´ıch vlastnostech [8]. Mezi nejznámˇejˇs´ı systémy patˇr´ı Jenkins, Travis a TeamCity. Vˇsechny tyto systémy maj´ı nˇekolik svých priorit, kterými se dá inspirovat. Podporuj´ı vystaven´ı kódu na pro- dukˇcn´ı server, spuˇstˇen´ı test˚u, sestaven´ı aplikace a mnoho dalˇs´ıho.

3.2 N´ avrh vlastn´ıho ˇ reˇ sen´ı

Ze z´ıskaných znalost´ı a dosavadn´ıch zkuˇsenost´ı autora byl vytvoˇren návrh vlastn´ıho systému. Systém mus´ı splˇnovat následujic´ı poˇzadavky:

• Spr´ava repozit´aˇru

• Spr´ava sestavovac´ıch skript˚u

• Spr´ava pˇr´ıstup˚u

• Grafick´e rozhran´ı pro snadn´y pˇr´ıstup

• Konzolov´y pˇr´ıstup pro detailnˇejˇs´ı nastaven´ı

(37)

Pro správu repozitáˇru je tˇreba vytvoˇrit vlastn´ı systém, který bude na vstupu podporovat dva r˚uzné druhy repozitáˇr˚u. Repozitáˇre pro systém GIT a Mercuriál. Bude kladen d˚uraz na jednoduchost nastavován´ı repozitáˇr˚u a moˇznost vykonávat základn´ı operace nad repozitáˇri. Tedy vytvoˇren´ı repozitáˇre, klonován´ı repozitáˇre, zjiˇstˇen´ı potˇrebných údaj˚u o repozitáˇri a pˇr´ıpadnˇe i jeho smazán´ı. Souˇcást´ı systému pro správu repozitáˇr˚u bude i moˇznost nastavován´ı vlastn´ıch sestavovac´ıch skript˚u. Pˇri vytváˇren´ı skriptu bude kladen d˚uraz na co nejvˇetˇs´ı intuitivnost pˇri jeho vytváˇren´ı.

Bude pouˇzit návrh pomoc´ı grafického editoru, který bude obsahovat funkˇcn´ı bloky.

Tyto bloky bude uˇzivatel spojovat a tak vytv´aˇret sloˇzitˇejˇs´ı funkce.

Pro správu pˇr´ıstup˚u k repozitáˇr˚um bude vytvoˇren dalˇs´ı systém, který bude spravovat pˇr´ıstupy pomoc´ı protokolu SSH. Tento systém bude m´ıt za úkol iden- tifikovat pˇr´ıchoz´ı spojen´ı a ovˇeˇrit, zda má povolen´ı nad daným repozitáˇrem provést poˇzadovanou ˇcinnost. Jeho dalˇs´ıˇcinnost bude upravovat soubory operaˇcn´ıho systému, které maj´ı za úkol obsluhovat pˇripojen´ı pomoc´ı protokolu SSH.

Pro moˇznost vytvoˇren´ı sestavovac´ıho skriptu bude nutné vytvoˇrit vlastn´ı jazyk, pomoc´ı kterého se bude skript vytváˇret. Dosavadn´ı, autorem nalezené jazyky a nástoje, nejsou dostateˇcnˇe ohebné, aby se daly jednoduˇse sestavovat v grafickém rozhran´ı. Zde se nacház´ı asi nejsloˇzitˇejˇs´ı ˇcást práce, které bude vˇenován nejvˇetˇs´ı d˚uraz.

Jako hlavn´ı programovac´ı jazyk bude zvolen PHP, protoˇze ho autor nejlépe ovládá. Sestavovac´ı skripty budou ve formátu XML, protoˇze tento formát poskytuje dobré nástroje pro validaci. Systém bude c´ılit hlavnˇe na vývojáˇre pouˇzivajic´ı volnˇe ˇs´ıˇritelný nebo svobodný software. Proto bude hlavn´ım platformou operaˇcn´ı systém Linux.

(38)

4 Vlastn´ı ˇ reˇ sen´ı

V následuj´ıc´ı ˇcásti práce se budeme zabývat implementac´ı konkrétn´ıho systému, který si klade za c´ıl poskytnout uˇzivateli vˇsechny potˇrebné nástroje, aby mohl zaˇc´ıt vyuˇz´ıvat pr˚ubˇeˇznou integraci pro sv˚uj projekt. Zároveˇn klade d˚uraz na jednoduchou instalaci, intuitivn´ı ovládán´ı a pˇrehledné výstupy. Systém je rozdˇelen do tˇr´ı ˇcást´ı.

Jazyk je zvolena angliˇctina, aby nebyla aplikace omezen´a pouze pro n´arodn´ı trh.

Skrze rozhran´ı, které aplikace poskytuje je moˇzné provést lokalizaci do jakého koliv jiného jazyka.

Obrázek 4.1: Schéma systému

Obrázek 4.1 vystihuje schéma celého systému. Na poˇcátku je uˇzivatel, který má zájem poslat svoje nové zmˇeny do repozitáˇre. Pˇripoj´ı se tedy pomoc´ı protokolu SSH ke vzdálenému repozitáˇri, kde Stas zkontroluje, zda má k pˇripojen´ı právo. Po ovˇeˇren´ı se dostává uˇzivatel pˇr´ımo k repozitáˇri, do kterého zap´ıˇse svoje

(39)

zmˇeny. V jiném pˇr´ıpadˇe se uˇzivatel pˇripojuje k Prestaciu, které mu umoˇzn´ı nastaven´ı vˇsech repozitáˇr˚u. Z´ıská informace o stavu repozitáˇre a má moˇznost mˇenit sestavovac´ı skript pˇriˇrazený k danému repozitáˇri. Pokud dojde k události, která vy- volá spuˇstˇen´ı sestavovac´ıho skriptu, tak je spouˇstˇen Hockej s pˇr´ısluˇsnými parametry.

Vˇsechny ˇcásti Hockeje byly týmovˇe vyv´ıjeny. Následuje popis ˇcinost´ı jednotlivých komponent systému.

4.1 Hockej

Pro úˇcel práce byl vyvinut sestavovac´ı systém, který nese jméno Hockej. Lze pomoc´ı nˇeho spouˇstˇet r˚uzné c´ıle pr˚ubˇeˇzné integrace. Poˇc´ınaje kop´ırován´ım soubor˚u a konˇce verzován´ı databáze. Jeho hlavn´ım c´ılem je co nejv´ıce zjednoduˇsit tvorbu sestavovac´ıch skript˚u.

4.1.1 Sestavovac´ı skript

Definice ˇcinnosti Hockeje je obsaˇzena v sestavovac´ım skriptu. Tento skript obsahuje definice ˇcinnost´ı, které lze vykonávat. Soubor se skriptem má koncovku ”.hockej”, je ve formátu XML a jeho jednotlivé elementy maj´ı speciáln´ı význam. Existuj´ı 4 druhý element˚u:

• Definice - Nejmenˇs´ı jednotka, která vykonává ˇcinnost (kop´ırován´ı, mazán´ı, filtrován´ı atd.). Nelze samostatnˇe spustit.

• Pˇr´ıkaz - Shluk v´ıce definic, které se sériovˇe po sobˇe spouˇst´ı. Jednotlivé pˇr´ıkazy je moˇzné spouˇstˇet z pˇr´ıkazové ˇrádky.

(40)

• Odvozen´ı - Z definice lze odvodit novou vlastn´ı definici, která má jiˇz pˇrednastavené vlastnosti.

Koˇrenovým elementem kaˇzdého sestavovac´ıho skriptu je element <hockej>, který ˇr´ıká, ˇze se bude jednat o sestavovac´ı skript Hockeje. Následuje nepovinný element

<description>, který by mˇel popisovat ˇcinnost sestavovac´ıho skriptu. Stejnˇe tak m˚uˇze být doplnˇen nepovinný element <version> urˇcuj´ıc´ı verzi daného skriptu.

4.1.2 Katalog

Definice vˇsech ˇcinnost´ı, kter´e Hockej dok´aˇze vykonat, jsou um´ıstˇen´ı v kataloz´ıch.

Katalog se do sestavovac´ıho skriptu pˇridá pomoc´ı elementu <catalog>. Má dva povinné parametry:

• from - ˇR´ıká, kde se nacházej´ı soubory potˇrebné pro inicializaci katalogu.

• as - Pˇriˇrazuje katalogu jmenný prostor, pod kterým bude pˇr´ıstupný. Jeho elementy jsou následnˇe pˇr´ıstupné jako ”namespace.”a jméno definice.

Existuj´ı celkem 4 zdroje katalog˚u:

• Vestavˇené - Jsou pˇr´ımo souˇcást´ı instalace Hockeje. Kód, který se bude vy- konávat je nadefinován pouze v nich. Ostatn´ı katalogy pouze dˇed´ı z vestavˇených katalog˚u. Výchoz´ı adresáˇr je ”/usr/share/hockej/catalogs/”.

• Uˇzivatelské - Vlastn´ı katalogy, které si vytváˇrej´ı uˇzivatelé. Uloˇzený zpravidla v uˇzivatelské sloˇzce poˇc´ıtaˇce. Výchoz´ı adresáˇr je ”/home/user/.local/hockej/”.

• Projektové - Jeden projekt m˚uˇze vlastnit nˇekolik privátn´ıch katalog˚u. Výchoz´ı cesta nen´ı pˇredem urˇcená.

(41)

• Pˇr´ım´e - Zapisuj´ı se pˇr´ımo do sestavovac´ıho skriptu jako element <catalog>

bez parametru ”from”.

Obr´azek 4.2: Hockej katalogy

Aˇz na vestavˇené katalogy, které jsou definovány v´ıce soubory, si vˇsechny vytváˇr´ı uˇzivatel. Nejjednoduˇsˇs´ı je vytvoˇrit pˇr´ımý katalog, který je souˇcást´ı sestavovac´ıho skriptu.

4.1.3 Definice

Nejmenˇs´ı vykonatelnou ˇcást´ı pro Hockej je definice. Jedná se napˇr´ıklad o vytvoˇren´ı instance souboru, zápis do souboru, vytvoˇren´ı sloˇzky nebo spuˇstˇen´ı skriptu. V pˇredchoz´ıch

pˇr´ıpadech byly definice napˇr´ıklad elementy <print from="fs.file-write">, <file from="my.my-file">

nebo <content from="core.string">. Vˇsechny maj´ı definovan´y povinn´y parametr

”from”, který ˇr´ıká jaká je rodiˇcovská definice toho prvku. Pˇriˇcemˇz kaˇzdý element m˚uˇze m´ıt právˇe jednoho rodiˇce, ale i tak se daj´ı vytváˇret sloˇzité struktury.

(42)

Obrázek 4.3: Hockej - skládán´ı definic

4.2 Prestacio

Aplikace poskytuj´ıc´ı grafické prostˇred´ı pro ovládán´ı celého systému. Je vytvoˇrena na základˇe aplikaˇcn´ıho frameworku Nette [10]. Jedná se o nejd˚uleˇzitˇejˇs´ı komponentu systému a proto je po n´ı celý systém nazván.

Obrázek 4.4: Menu Prestacio se skládá z následuj´ıc´ıch ˇcást´ı:

• Home - Jednoduch´y popis aplikace

• Repositories - Seznam vˇsech repozit´aˇr˚u

• Hockej - Sestavovac´ı syst´em (glob´aln´ı nastaven´ı)

• Accounts - Uˇzivatelské úˇcty, pro pˇr´ıstup k repozitáˇr˚um

• About - M´ısto pro vloˇzen´ı vlastn´ıho textu (napˇr´ıklad kr´atk´y popis firmy, projekt˚u atd.)

(43)

4.2.1 Repozit´ aˇ re

Prestacio dokáˇze spravovat nˇekolik repozitáˇr˚u najednou. Skrze jednotlivé verzovac´ı systémy jsou o repozitáˇr´ıch z´ıskáváné údaje, které jsou následnˇe zobrazeny v gra- fickém prostˇred´ı uˇzivately. Je moˇzné spravovat repozitáˇre verzovac´ıch systém˚u GIT a Mercuriál. Lze provádˇet pouze vytˇeˇzován´ı informac´ı a nelze provádˇet zmˇeny v nastaven´ı repozitáˇr˚u. T´ım je ˇcásteˇcnˇe zabezpeˇcena konzistence dat a zábránˇeno uˇzivateli systému repozitáˇr uvést do nefunkˇcn´ıho stavu.

4.2.2 Sestavovac´ı skript

Prestacio umoˇzˇnuje kaˇzdému repozitáˇri vytvoˇrit vlastn´ı sestavovac´ı skript, který slouˇz´ı k zautomatizován´ı ˇcinost´ı nad repozitáˇrem. Skript m˚uˇze být vytvoˇren v tex- tovém editoru nebo lze vyuˇz´ıt grafické nadstavby, která umoˇzˇnuje jednoduché vytváˇren´ı skript˚u. Grafickému editoru a vytváˇren´ı skript˚u bude vˇenována ˇcást dalˇs´ı kapitoly.

4.2.3 Hockej

Tato ˇcást z´ıskává vˇsechny dostupné informace o aktuáln´ım nastaven´ı Hockeje. Tedy informace o kataloz´ıch, kde jsou podrobnˇe popsáný vˇsechny definice, které jsou v kataloz´ıch obsaˇzeny. Katalogy jsou rozdˇeleny na systémové a uˇzivatelské.

4.2.4 Uˇ zivatelsk´ e ´ uˇ cty

K repozitáˇr˚um mohou pˇristupovat rozliˇcn´ı uˇzivatelé, proto tato sekce umoˇzˇnuje spravovat pˇr´ıstupy uˇzivatel˚u k jednotlivým repozitáˇr˚um a pˇridávat k nim oprávnˇen´ı na ˇcten´ı ˇci zápis. Je zde také správa vˇsech veˇrejný kl´ıˇc˚u potˇrebných pro zabezpeˇcenou komunikaci protokolem SSH mezi uˇzivatelem a repozitáˇrem.

(44)

4.3 Stas

Pro moˇznost pˇripojen´ı uˇzivatel˚u skrze protokol SSH bylo nutné vytvoˇrit systém, který bude uˇzivatele ovˇeˇrovat. Jedná se tedy o vrstvu, která je vloˇzena mezi sluˇzbou spravujic´ı SSH komunikaci a repozitáˇrem. Zkratka systému Stas znamená ”Ssh Tri- vial Authorization System”. Jedná se o obdobu systému Gitolite [11], který ovˇsem podporuje pouze verzovac´ı systém GIT.

V pˇr´ıpadˇe, kdy se uˇzivatel pˇripojuje skrze prokol SSH ke vzdálenému repozitáˇri a pˇripojen´ı nen´ı spravované pomoc´ı Stas, je pr˚ubˇeh následujic´ı:

• Uˇzivatel se autorizuje pomoc´ı svého veˇrejného kl´ıˇce nebo hesla sluˇzbˇe serveru na který se pˇripojuje.

• Uˇzivatel dostane pˇr´ıstup pˇr´ımo k repozit´aˇri a nahraje do nˇej svoje zmˇeny.

Nen´ı tedy zde nic, co by uˇzivatele identifikovalo. Do repozitáˇre tedy mohou pˇrisp´ıvat vˇsichni, kteˇr´ı maj´ı heslo nebo zaregistrovaný veˇrejný kl´ıˇc.

V druhém pˇr´ıpadˇe se uˇzivatel pˇripojuje ke vzdálenému uloˇziˇsti spravovaného pomoc´ı Stas, které zajist´ı indentifikaci uˇzivatele a zkontroluje, zda má pˇr´ıstup pro danou operaci na repozitáˇrem. Postup je tedy následujic´ı:

• Uˇzivatel se autorizuje pomoc´ı svého veˇrejného kl´ıˇce serveru na který se pˇripojuje.

• Spust´ı se Stas, kter´e podle kl´ıˇce zkontroluje uˇzivatele pˇripojuj´ıc´ıho se k repozit´aˇri.

• Stas zjist´ı, zda má daný uˇzivatel právo k repozitáˇri pˇristoupit.

(45)

• Stas zkontroluje o jakou ˇcinnost se bude jednat. Existuj´ı 2 typy (ˇcten´ı a z´apis).

• Stas povol´ı nebo zam´ıtne ˇcinost.

Aby bylo moˇzné pˇripojovat uˇzivatele pomoc´ı SSH protokolu, mus´ı Stas nakop´ırovat veˇrejné kl´ıˇce vˇsech uˇzivatel˚u zadaných v Prestaciu do souboru

~/.ssh/authorized_keys.

(46)

5 N´ avod na pouˇ z´ıv´ an´ı a praktick´ e uk´ azky

5.1 Hockej

V této kapitole bude popsáno jakým zp˚usobem se pouˇz´ıvá navrˇzený systém pro vytváˇren´ı a vykonáván´ı sestavovac´ıch skript˚u.

5.1.1 Instalace

Jedná se o samostatnou souˇcást, která vyˇzaduje instalaci. Pro instalaci je nutné m´ıt nainstalovaný Composer(https://getcomposer.org/), GIT(http://git-scm.com/) a PHP ve verzi vˇetˇs´ı neˇz 5.4. Následnˇe je tˇreba naklonovat repozitáˇr s Hockejem z pˇriloˇzeného CD nebo z aktuáln´ıho repozitáˇre pomoc´ı pˇr´ıkazu

git@bitbucket.org:Tacoberu/hockej.git, pˇrepnout se do sloˇzky s naklonovaným hockejem a spustit Composer composer install. Hockej mus´ı být um´ıstˇeˇn do ad- resáˇre, kde bude globálnˇe spustitelný.

Napˇr´ıklad ln -s source/bin/hockej ~/bin/hockej.

5.1.2 Vytvoˇ ren´ı sestavovac´ıho skriptu

Definice katalog˚u, kter´e bude skript vyuˇz´ıvat se definuj´ı pomoc´ı elementu <catalog>

s povinn´ymi parametry from(zdroj katalogu) a as(jmenn´y prostor).

(47)

Nejjednoduˇsˇs´ı katalog m˚uˇze tedy vypadat n´asledovnˇe:

<?xml version="1.0" ?>

<description>First buildscript</description>

</hockej>

Skript si pˇri spuˇstˇen´ı inicializuje katalog ”filesystem”a pˇriˇrad´ı mu jmenný prostor ”fs”. Nic v´ıc vˇsak neudˇelá. Je proto nutné definovat pˇr´ıkaz pomoc´ı elementu

<command>, který bude moci Hockej spustit. Element mus´ı m´ıt nadefinovaný atribut name, který ˇr´ıká jakým pˇr´ıkazem bude spuˇstˇen. Nadefinujme si tedy pˇr´ıkaz, který zap´ıˇse do souboru ”priklad.txt”ˇretˇezec ”Hello, I’am Hockej!”. Výsledný skript bude vypadat následovnˇe:

<?xml version="1.0" ?>

<description>First buildscript</description>

(48)

<filename from="fs.file">priklad.txt</filename>

</file>

<content from="core.string">Hello, I’am Hockej!</content>

</print>

</command>

</hockej>

Po spuˇstˇen´ı sestavovac´ıho souboru pˇr´ıkazem ”hockej build”ve sloˇzce se skriptem Hockej zap´ıˇse text do souboru. Nyn´ı si podrobnˇe probereme, co jednotliv´e poloˇzky znamenaj´ı.

5.1.3 Vytvoˇ ren´ı vlastn´ıho katalogu

Pro pˇr´ıklad si, ale uvedeme definici katalogu v extern´ım souboru, kter´a bude prakticky stejn´a.

Extern´ı katalogy jsou definované v souborech s názvem ”catalog.hockej”a jsou ve formátu XML. Vytvoˇrme jednoduchý katalog, který nám bude definovat cestu k souboru ”priklad.txt”:

<?xml version="1.0" encoding="UTF-8"?>

<id>routes</id>

(49)

<description>Cesta k~soubor˚um</description>

<my-file from="fs.file">

<filename from="core.string">priklad.txt</filename>

</my-file>

</catalog>

Pokud si nyn´ı pˇrid´ame do sestavovac´ı skriptu tento katalog, budeme m´ıt k dis- pozici nov´y element <my-file>.

Pomoc´ı <catalog from="hockej://project//routes" as="my" /> pˇridáme vlastn´ı katalog do skriptu a m˚uˇzeme pouˇz´ıvat následuj´ıc´ı pˇredpis pro zápis do souboru :

<content from="core.string">Hello, I’am Hockej!</content>

</print>

</command>

(50)

Soubor s katalogem by v tomto pˇr´ıpadˇe byl uloˇzen ve sloˇzce project/routes, která by se nacházela v koˇrenovém adresáˇri projektu. T´ım se dá ulehˇcit opisován´ı stejných konstrukc´ı pro nazván´ı souboru, vytváˇren´ı sloˇzek a ostatn´ıch.

5.1.4 Uk´ azka rozˇ siˇ rov´ an´ı definic

Napˇr´ıklad definice ”fs.file-write”zajiˇst’uje zápis do souboru. Vytvoˇrili jsme tedy element s libovolným názvem, který dˇed´ı od definice ”fs.file-write”. Pˇr´ıkladem m˚uˇze být element <print from="fs-file-write"> z minulého pˇr´ıkladu. Tato definice vyˇzaduje dalˇs´ı dvˇe definice:

• Soubor, do kter´eho se bude zapisovat. Jedn´a se o potomka definice ”fs.file”.

• Text, kter´y se bude zapisovat. Zde se bude jednat o potomka definice ”core.string”.

Tyto závislosti je moˇzné z´ıskat pomoc´ı parseru katalog˚u, ten je v grafické po- dobnˇe implementován v Prestaciu. Závislosti umoˇzˇnuj´ı vytváˇret sloˇzité struktury, které se mohou r˚uznˇe pˇrekrývat. Tato vlastnost je kl´ıˇcová, kv˚uli které byl Hockej vytvoˇren. Lze pˇreddefinovávat jiˇz nastavené definice nebo je doplˇnovat. Nejlépe si to m˚uˇzeme vysvˇetlit na pˇr´ıkladu se souborem, tedy s potomkem definice ”fs.file”, který vyˇzaduje následuj´ıc´ı definice:

• Koˇren - Potomek definice ”fs.path”

• Cesta - Potomek tˇr´ıdy ”fs.path”

• N´azev souboru - Potomek tˇr´ıdy ”core.string”

(51)

Jeho definice m˚uˇze vypadat n´asledovnˇe :

<path from="fs.path">/korenovy/adresar/</path>

<path from="fs.path">/cesta/dal/</path>

<filename from="core.string">nazev_souboru.txt</filename>

</soubor>

T´ım jsme vytvoˇrili definici, kterou m˚uˇzeme pouˇz´ıt k vytvoˇren´ı elementu <muj-soubor from="soubor" />.

Potˇrebujeme vytvoˇrit dalˇs´ı definici, ale chceme pouze zmˇenit jm´eno souboru. To lze uskuteˇcnit n´asledovnˇe:

<druhy-soubor from="soubor">

<filename from="core.string">jiny_nazev.txt</filename>

</druhy-soubor>

Tuto definici m˚uˇze opˇet pouˇz´ıt pomoc´ı elementu <jiny-sobour from="druhy-soubor">

a pˇredat definici pro z´apis do souboru a n´aslednˇe libovolnˇe mˇenit jej´ı pˇredky.

5.1.5 Spuˇ stˇ en´ı

Samotný Hockej se pˇri správnˇe provedené instalaci spouˇst´ı pˇr´ıkazem hockej a pa- rametrem, který ˇr´ıká co má udˇelat:

• help - Zobraz´ı plnou n´apovˇedu.

• list - Zobraz´ı seznam vˇsech spustiteln´ych pˇr´ıkaz˚u. Atributy ”name”od vˇsech element˚u <command>.

(52)

• run <pˇr´ıkaz> - Vyhled´a v aktu´aln´ı sloˇzce soubor ”build.hockej”a spust´ı v nˇem pˇr´ıkaz. Napˇr´ıklad hockej run build.

• -f --buildfile <nazev_skriptu> - Specifikuje n´azev souboru se sestavovac´ım skriptem. Napˇr´ıklad hockej run build -f build-local.hockej.

• --xml - V´ystup ve form´atu XML. Napˇr´ıklad hockej run build --xml.

• --dry-run - Provede such´y bˇeh. Fyzicky se nic nevykon´a.

Napˇr´ıklad hockej run build --dry-run.

5.2 Prestacio

5.2.1 Instalace

Prestacio je webová aplikace, která pro svoji instalaci vyˇzaduje webový server, který obsahuje interpreter jazyk PHP pro verzi 5.4 a vyˇsˇs´ı. Dále je nutný nainstalovaný Composer a GIT. Následnˇe je tˇreba naklonovat repozitáˇr s projektem z pˇrilozeného CD nebo z aktuáln´ıho repozitáˇre pomoc´ı pˇr´ıkazu

git clone git@bitbucket.org:Tacoberu/prestacio.git. Pˇrepnout se do sloˇzky s naklonovaný projektem a spustit Composer pˇr´ıkazem composer install, t´ım se doinstaluj´ı vˇsechny závislosti. Jako posledn´ı krok je nutné vytvoˇrit instanci hosta v konfiguraci webového serveru, která bude odkazovat do sloˇzky webroot.

Souˇc´ast´ı instalace Prestacia je i instalace Stas.

5.2.2 Repozit´ aˇ re

Prestacio dokáˇze hospodaˇrit s nˇekolika repozitáˇri nezávisle na sobˇe. U kaˇzdého repo- zitáˇre je zobrazen jeho název a pˇr´ıkaz, pomoc´ı kterého je moˇzné si vytvoˇrit lokáln´ı kopii repozitáˇre. Posledn´ı poloˇzka je stav repozitáˇre, který znázorˇnuje stav posledn´ıho

(53)

sestaven´ı aplikace. Pokud se sestaven´ı zdaˇrilo je zobrazena 1 v opaˇcn´em pˇr´ıpadˇe je zde nula.

Obr´azek 5.1: Seznam repozit´aˇr˚u

Zat´ım podporované verzovac´ı systémy jsou GIT a Mercurial. Podle zkratek git a hg lze rozeznat, kterým verzovac´ım systémem je repozitáˇr spravován.

Pomoc´ı tlaˇc´ıtka Add new repository je moˇzné pˇridat nový repozitáˇr ke správˇe.

Obr´azek 5.2: Pˇridat repozit´aˇr

V pˇridávac´ım formuláˇri staˇc´ı zvolit název repozitáˇre a verzovac´ı systém, pomoc´ı kterého bude spravován. Vˇsechny tlaˇc´ıtka v Prestaciu jsou barevnˇe odliˇsené:

• Zelen´a - Vytvoˇren´ı nov´e prvku.

(54)

• Sed´ˇ a- Zobrazen´ı podrobnost´ı.

• Cerven´ˇ a - Smaz´an´ı prvku.

Po kliknut´ı na název repozitáˇre se otevˇre detailn´ı zobrazen´ı repozitáˇre.

Obr´azek 5.3: Detail repozit´aˇre

Kde jsou vypsány jednotlivé údaje o repozitáˇri:

• Name - Jm´eno repozit´aˇre.

• Url - Adresa, pomoc´ı které je moˇzné repozitáˇr naklonovat.

• Last tag - Posledn´ı pˇridˇelen´a znaˇcka.

• Last commit - Záznam o posledn´ı nahrané zmˇenˇe. Obsahuje jméno uˇzivatele, kontroln´ı souˇcet v pˇr´ıpadˇe GIT, popisek zmˇeny a moˇznost zobrazit diferenciáln´ı zobrazen´ı s pˇredchoz´ı zmˇenou.

• ACL - Omezen´ı pˇr´ıstupov´ych prav.

• Deploy status - Stejný význam jako status v seznamu repozitáˇr˚u a moˇznost zobrazit detailn´ı zprávy s výsledky sestavovac´ıho systému.

• Buildscript - Odkaz na definov´an´ı vlastn´ıho sestavovac´ıho skriptu.

(55)

Obr´azek 5.4: Zmˇeny v repozit´aˇri

Pro lepˇs´ı pˇrehled vývoje kódu je d˚uleˇzité vidˇet seznam vˇsech zmˇen, které byly v repozitáˇri provedeny. Prestacio obsahuje pˇrehledné zobrazen´ı, které poskytuje základn´ı informace o vˇsech zmˇenách, které byly v kódu provedeny. Vˇsechny tyto informace poskytuje verzovac´ı systém a Prestacio je pˇrevád´ı do pˇrehlednˇejˇs´ı podoby. Na obrázku 3.5 je vidˇet, ˇze Vojta T˚uma provedl zmˇenu s popisem: ”Buildset:

element offset generates objects out of canvas.”. Tato zmˇena byla provedena 2.dubna v 22:21. Po kliknut´ı na popis zmˇeny se zobraz´ı detailnˇejˇs´ı informace o zmˇenˇe.

Obr´azek 5.5: Detail zmˇeny

V detailn´ım popisu jsou zobrazeny jednotlivé soubory, jejichˇz obsah byl v dané zmˇenˇe upraven. Konkrétn´ı zobrazen´ı je závislé na pouˇzitém verzovac´ım systému, protoˇze výstup je generován pˇr´ımo verzovac´ım systémem. Na obrázku 3.6 vid´ıme,

(56)

ˇze byl zmˇenˇen obsah souboru CanvasDirective.js. ˇRádky, které zaˇc´ınaj´ı znam´ınkem m´ınus ˇr´ıkaj´ı, ˇze byl daný ˇrádek v souboru odebrán. Naopak ˇrádky zaˇc´ınaj´ıc´ı znaménkem plus znaˇc´ı pˇridán´ı nového ˇrádku v rámci zmˇeny.

5.2.3 Sestavovac´ı skript

Kaˇzdému repozitáˇri je pˇriˇrazen jeden sestavovac´ı skript. Po kliknut´ı na odkaz ”Edit buildscript”v detailu repozitáˇre se zobraz´ı okno s moˇznost´ı editace sestavovac´ı skriptu Hockeje.

Cel´e prostˇred´ı je rozdˇelen´e do 3 panel˚u:

• Lev´y - Definuje se v nˇem popisek, verze a katalogy, kter´e bude sestavovac´ı skript pouˇz´ıvat.

• Stˇredn´ı - Vkládaj´ı se do nˇej elementy, ze kterých se sestavuje výsledný skript.

Zobrazuje se v nˇem v´ysledn´e xml.

• Prav´y - Zobrazuj´ı se v nˇem moˇzn´e parametry element˚u.

Obrázek 5.6: Pˇridáván´ı katalog˚u

(57)

Nejdˇr´ıve vybereme v levém panelu katalogy, které chceme pouˇz´ıvat. Jsou rozdˇelené na ”System”(vestavˇené) a ”Custom”(projektové a uˇzivatelské). Nad stˇredn´ım pane- lem je liˇsta, na které jsou 4 tlaˇc´ıtka:

• Add task - Pˇrid´a novou definici.

• Add command - Pˇrid´a nov´y pˇr´ıkaz.

• Graphic editor - Zobraz´ı sestavovac´ı skript v grafick´e podobˇe.

• Xml preview - Z grafické podoby vygeneruje výsledný XML soubor.

Novou definici pˇridáme kliknut´ım na tlaˇc´ıtko ”Add task”. Zobraz´ı se dialogové okno, ve kterém zvol´ıme z jakého katalogu chceme definici vyb´ırat, následnˇe vybereme danou definici a klikneme na tlaˇc´ıtko pro pˇridán´ı definice do grafického editoru.

Obrázek 5.7: Pˇridáván´ı definice

Po vloˇzen´ı se zobraz´ı element v grafickém editoru. Na levé stranˇe má definice, které vyˇzaduje, aby mohl správnˇe pracovat. Na pravé stranˇe jaký jeho výstup. Na levé stranˇe vid´ıme, ˇze vyˇzaduje parametr ”root”, který je typu ”path”. Podle názvu zjist´ıme, ˇze se bude zˇrejmˇe jedna o koˇrenový adresáˇr. Dalˇs´ı dva parametry jsou opˇet typu ”path”. Jeden je relativn´ı cesta od koˇrene dále a druhý je název souboru.

Výstup na pravé stranˇe ukazuje, ˇze z toho elementu je moˇzné z´ıskat definici typu