Nyn´ı knihu z prvn´ıho pˇr´ıkladu nahrad´ıme za aplikaci, kter´a obsahuje nˇekolik sou-bor˚u. Soubory mus´ı b´yt nˇekde uloˇzeny. U verzovac´ıch syst´em˚u se toto m´ısto naz´yv´a repozit´aˇr. Jedn´a se o adres´aˇr, kde jsou ve speci´aln´ım form´atu uloˇzeny vˇsechny sou-bory, kter´e jsou verzovan´e (spravovan´e verzovac´ım syst´emem). Spr´avnˇe nen´ı moˇzn´e do repozit´aˇre pˇristoupit a ruˇcnˇe zmˇenit jeho obsah. M˚uˇzeme si ho pˇredstavit jako bal´ık dat, kter´y obsahuje n´ami vloˇzen´y obsah a doprovodn´a data, kter´a popisuj´ı jednotliv´e zmˇeny proveden´e na datech.
V pˇr´ıpadˇe, ˇze nepracujeme v t´ymu a chceme pouze ukl´adat historii projektu, staˇc´ı n´am lok´aln´ı repozit´aˇr. Ten leˇz´ı na lok´aln´ım poˇc´ıtaˇci a zpravidla k nˇemu m´a pˇr´ıstup pouze uˇzivatel na dan´em poˇc´ıtaˇci. Aby bylo moˇzn´e data v repozit´aˇri upravo-vat, mus´ıme si vytvoˇrit pracovn´ı kopii repozit´aˇre, ve kter´e m˚uˇzeme prov´adˇet zmˇeny, kter´e opˇet n´aslednˇe nahrajeme do repozit´aˇre. Ten zmˇenu zaznamen´a a uloˇz´ı si ji do sv´e historie.
Obr´azek 2.2: Repozit´aˇr a pracovn´ı kopie
Pr´ace v t´ymu ovˇsem vyˇzaduje tyto repozit´aˇre synchronizovat. Repozit´aˇre mezi sebou dok´aˇz´ı komunikovat a odes´ılat si mezi sebou zmˇeny. Je tedy moˇzn´e propojit dva repozit´aˇre, kter´e si mezi sebou budou odes´ılat zmˇeny.
Obr´azek 2.3: Synchronizace dvou repozit´aˇr˚u
Toto se ovˇsem st´av´a nepraktick´e, kdyˇz se zvyˇsuje poˇcet repozit´aˇr˚u a vznik´a tˇeˇzce udrˇziteln´a infrastruktura. Proto se zav´ad´ı myˇslenka sd´ılen´eho repozit´aˇre, se kter´ym se vˇsechny ostatn´ı repozit´aˇre aktualizuj´ı. Tento repozit´aˇr by mˇel b´yt na veˇrejn´em m´ıstˇe, kam maj´ı vˇsichni uˇzivatel´e pˇr´ıstup, aby se s n´ım mohli co nejˇcastˇeji synchro-nizovat. V praxi se toto ˇreˇsen´ı ukazuje jako nejlepˇs´ı.
Obr´azek 2.4: Synchronizace dvou repozit´aˇr˚u
Repozit´aˇre, kter´e nejsou sd´ılen´e se naz´yvaj´ı lok´aln´ı nebo uˇzivatelsk´e. Pro zjed-noduˇsen´ı d´ale v pr´aci budou tyto repozit´aˇre komponov´any jako souˇc´ast uˇzivatele a budeme uvaˇzovat, ˇze uˇzivatel komunikuje se sd´ılen´ym repozit´aˇrem pr´avˇe skrze sv˚uj lok´aln´ı repozit´aˇr.
2.1.2 Zivotn´ı cyklus verzov´ ˇ an´ı
Pokud se zamˇeˇr´ıme na nejpokroˇcilejˇs´ı distribuovan´e verzovac´ı syst´emy, vˇsechny maj´ı velice podobn´y ˇzivotn´ı cyklus. Z´akladem je vytvoˇren´ı repozit´aˇre, kter´y je pˇr´ıstupn´y vˇsem pˇrispˇevatel˚um. Pro firemn´ı projekty je dobr´e ho um´ıstit na sd´ılen´y disk a zpˇr´ıstupnit ho poˇzadovan´ym uˇzivatel˚um. Nen´ı probl´em se vˇsak pˇripojit ke vzd´alen´emu repozit´aˇri promoc´ı protokolu SSH nebo HTTPS i vnˇe firemn´ı s´ıtˇe. Vˇetˇsina distri-buovan´ych verzovac´ıch syst´em˚u m´a jiˇz pˇripraven´e rozhran´ı, kter´e implementaci t´eto komunikaci zajiˇst’uje. Existuj´ı dva moˇzn´e sc´en´aˇre pˇri vytv´aˇren´ı repozit´aˇre:
• Obsah (k´od) jiˇz existuje a repozit´aˇre bude obsahovat nˇejak´a data
• Vytvoˇr´ıme pr´azdn´y repozit´aˇr, kter´y n´aslednˇe napln´ıme obsahem
Na z´akladˇe situace vytvoˇr´ıme nov´y repozit´aˇr, kter´y je pr´azdn´y nebo inicializu-jeme repozit´aˇr nad jiˇz existuj´ıc´ım k´odem. V obou situac´ıch se vlastnˇe jedn´a o
vy-tvoˇren´ı pr´azdn´eho repozit´aˇre, do kter´eho se n´aslednˇe nahraj´ı data.
Obr´azek 2.5: Rozkop´ırov´an´ı repozit´aˇre
Poˇzadov´an´ı uˇzivatel´e si n´aslednˇe vytvoˇr´ı kopie sd´ılen´eho repozit´aˇre.
Nyn´ı uˇz m´a kaˇzd´y uˇzivatel vlastn´ı kopii a m˚uˇze vytv´aˇret zmˇeny. Aˇz uzn´a za vhodn´e, tak odeˇsle seznam sv´ych zmˇen do sd´ılen´eho repozit´aˇre. Nejlepˇs´ı je pos´ılat zmˇeny co nejˇcastˇeji, aby nedoch´azelo ke zbyteˇcnˇe velk´emu mnoˇzstv´ı konflikt˚u. Nejdˇr´ıve syst´em zkontroluje, zda nejsou nov´e zmˇeny ve sd´ılen´em repozit´aˇri od jin´ych uˇzivatel˚u a pokud nejsou, tak zmˇeny odeˇsle.
Obr´azek 2.6: Odesl´an´ı zmˇen do repozit´aˇre
Pokud nˇejak´y jin´y uˇzivatel udˇelal zmˇenu, kter´a jeˇstˇe nen´ı v lok´aln´ım repozit´aˇri zahrnuta, tak se nahr´an´ı do sd´ılen´eho repozit´aˇre neprovede. Syst´em upozorn´ı na vznik konfliktu a bude po n´as poˇzadovat staˇzen´ı zmˇen od ostatn´ıch uˇzivatel˚u. Pˇred odesl´an´ım mus´ıme vlastn´ı zmˇeny spojit se zmˇenami, kter´e provedli ostatn´ı uˇzivatel´e
a v´ysledek n´aslednˇe odeslat do sd´ılen´eho repozit´aˇre.
Obr´azek 2.7: Pˇrid´an´ı ostatn´ıch zmˇen a odesl´an´ı
Jednou z posledn´ıch d˚uleˇzit´ych ud´alost´ı je navr´acen´ı zmˇen. Pokud nˇejak´y uˇzivatel udˇel´a opravu, kter´a rozbije funkˇcnost aplikace, je nutn´e se vr´atit o jednu nebo nˇekolik verz´ı zpˇet. Jedn´a se vlastnˇe o klasickou zmˇenu v k´odu s t´ım, ˇze zmˇen´ıte k´od do stavu, ve kter´em jiˇz byl.
Obr´azek 2.8: Navr´acen´ı zmˇen
Jak zn´azorˇnuje obr´azek 2.8, uˇzivatel odeslal do sd´ılen´eho repozit´aˇre 3 zmˇeny a kaˇzd´e zmˇenˇe odpov´ıd´a stav aplikace. Zmˇena C dostala aplikaci do stavu, kdy nefunguje. Uˇzivatel tedy chce vr´atit 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.
2.1.3 V´ yvojov´ e vˇ etve
Jestliˇze verzovac´ı syst´em spravuje napˇr´ıklad internetov´y vyhled´avaˇc str´anek a uˇzivatel provede ´upravu, kterou odeˇsle na sd´ılen´y repozit´aˇr, ´uprava se okamˇzitˇe projev´ı v ostr´e verzi, kter´a je viditelna vˇsem n´avˇstˇevn´ık˚um vyhledavaˇce na internetu. Po-kud by si ovˇsem uˇzivatel chtˇel pouze vyzkouˇset nov´y zp˚usob vyhled´av´an´ı nebo no-vou barvu pozad´ı, bylo by dobr´e m´ıt skrytou kopii, kterou uvid´ı pouze on. Tento probl´em se d´a vyˇreˇsit vytvoˇren´ım dalˇs´ıho repozit´aˇre, kter´y nebude um´ıstˇen viditelnˇe na internetu. Ovˇsem pak mus´ıme ruˇcnˇe ˇreˇsit synchronizaci mezi repozit´aˇri a t´ım se dost´av´ame na ´uroveˇn dokumentu na sd´ılen´em disku.
Obr´azek 2.9: Viditelnost v´yvojov´ych vˇetv´ı
Proto verzovac´ı syst´emy pˇrich´azej´ı s moˇznost´ı zakl´adat v´yvojov´e vˇetve. Umoˇzˇnuj´ı m´ıt hlavn´ı vˇetev, kter´a je napˇr´ıklad viditeln´a vˇsem uˇzivatel˚um internetu, ale k ostatn´ım vˇetv´ım se dostane pouze omezen´a skupina lid´ı.
Dalˇs´ım vyuˇzit´ım v´yvojov´ych verz´ı je vytvoˇren´ı odnoˇze ciz´ıho software. Jestliˇze v´ami obl´ıben´e knihovnˇe sch´az´ı pr´avˇe jedna pro v´as kl´ıˇcov´a funkce, kterou v´ıte jak doprogramovat, ale nechcete celou knihovnu vytv´aˇret znovu, je pro v´as nejlepˇs´ı moˇznost´ı vytvoˇrit odnoˇz jiˇz existuj´ıc´ı knihovny. Jedn´a se o zkop´ırov´an´ı posledn´ı verze knihovny do vlastn´ıho repozit´aˇre, kde knihovnˇe dopln´ıte potˇrebn´e funkce. Po-kud autor knihovny vyd´a aktualizace, kter´e poPo-kud nekoliduj´ı s vaˇsimi zmˇenami, m˚uˇzete si aktualizaci pˇridat i do vlastn´ı knihovny.
Obr´azek 2.10: Vytvoˇren´ı odnoˇze
2.1.4 Zachytn´ e h´ aky
Pokud jeden z pˇrispˇevatel˚u provede nahr´an´ı sv´ych zmˇen do sd´ılen´eho repozit´aˇre, bylo by dobr´e na to upozornit ostatn´ı. Nebo spustit automatickou sadu test˚u, kter´a ovˇeˇr´ı, ˇze se zmˇenou nic nerozbilo.
Toto je moˇzn´e pr´avˇe pomoc´ı z´achytn´ych h´ak˚u (hooks). Verzovac´ı syst´emy posky-tuj´ı nˇekolik h´ak˚u, na kter´e se daj´ı
”povˇesit“ r˚uzn´e skripty. Vˇetˇsinou lze zvolit, zda chceme skript spustit pˇred nebo po dan´e ud´alosti. Jednotliv´e h´aky jsou rozdˇeleny na lok´aln´ı a serverov´e.
Lok´aln´ı h´aky (v uˇzivatelks´ych repozit´aˇr´ıch) se vˇetˇsinou pouˇz´ıvaj´ı na syntaktic-kou kontrolu zmˇen, kter´e odes´ıl´ame. M˚uˇzeme zde kontrolovat, zda zmˇeny neobsahuj´ı zakomentovan´y k´od nebo lad´ıc´ı informace, kter´e by mˇely z˚ustat pouze na lok´aln´ım poˇc´ıtaˇci uˇzivatele.
Serverov´e h´aky (ve sd´ılen´em repozit´aˇri) naopak nach´azej´ı vyuˇzit´ı pˇri spouˇstˇen´ı test˚u, sestavov´an´ıˇci publikov´an´ı aktu´aln´ı verze pro veˇrejnost. Jestliˇze napˇr´ıklad selˇze
testov´an´ı aplikace, budou vˇsichni uˇzivatel´e upozornˇen´ı e-mailem. Z´achytn´e h´aky jsou proto nejd˚uleˇzitˇejˇs´ı souˇc´ast´ı syst´em˚u pro pr˚ubˇeˇznou integraci. Bez nich nen´ı moˇzn´e automaticky reagovat na zmˇeny, kter´e uˇzivatel´e vytv´aˇrej´ı a n´aslednˇe odes´ılaj´ı do sd´ılen´eho repozit´aˇre.
Obr´azek 2.11: Pˇr´ıklad z´achytn´ych h´ak˚u
H´aky na rozd´ıl od soubor˚u nejsou sd´ılen´e, protoˇze v kaˇzd´em repozit´aˇri mohou b´yt r˚uzn´e skripty spojen´e s r˚uzn´ymi ud´alostmi. Nejˇcastˇeji je vˇetˇsina h´ak˚u um´ıstˇena na serveru, kter´y prov´ad´ı testov´an´ı, sestavovan´ı a podobn´e ´ukony.
2.1.5 Uchov´ av´ an´ı historie zmˇ en
Uchov´av´an´ı historie je dalˇs´ı d˚uleˇzitou vlastnost´ı verzovac´ıch syst´em˚u. Historie ob-sahuje 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.
• Posledn´ı zmˇena, ze kter´e uˇzivatel vych´azel.
• Obsah zmˇeny (co bylo odebr´ano a co pˇrid´ano).
• V´yvojov´a vˇetev, ve kter´e se zmˇena nach´az´ı.
Syst´em m´a jist´a omezen´ı, kter´a chr´an´ı celistvost historie. Nelze napˇr´ıklad prov´est zmˇenu bez popisuj´ıc´ı zpr´avy. Nelze vytvoˇrit zmˇenu, kter´a m´a stejn´eho pˇredka jako jin´a zmˇena. Odes´ıl´an´a zmˇena mus´ı m´ıt tedy v sobˇe zakomponovan´e vˇsechny zmˇeny, kter´e jiˇz v repozit´aˇri jsou. Jm´eno uˇzivatele se m˚uˇze ovˇeˇrovat a t´ım zjistit, zda uˇzivatel m´a pr´avo udˇelat zmˇenu.
Uk´azka moˇzn´e podoby z´aznamu 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´ez´a nˇekolik r˚uzn´ych uplatnˇen´ı:
• Dok´aˇzeme zjistit, kdo provedl jakou zmˇenu.
• Dok´aˇzeme zjistit, kdo je autorem k´odu, kter´y upravujeme.
• Dok´aˇzeme zjistit, jak´e zmˇeny nem´ame zakomponovan´e v lok´aln´ım repozit´aˇri.
• Dok´aˇzeme se vracet ve zmˇen´ach. Uv´est k´od do dˇr´ıvˇejˇs´ı verze.
• Zobrazovat rozd´ıly mezi jednotliv´ymi zmˇenami.
• Kontrolovat produktivitu pr´ace program´ator˚u.
Shrnut´ım vˇsech tˇechto vlastnost´ı dost´av´ame velice siln´y n´astroj, jak kontrolovat v´yvoj projektu a prov´adˇet jeho verzov´an´ı.
2.1.6 Dobr´ e zvyky pro pouˇz´ıv´ an´ı verzovac´ıch syst´ em˚ u
Pˇri pouˇz´ıv´an´ı verzovac´ıch syst´em˚u existuje ˇrada dobr´ych zvyk˚u, kter´e n´am mohou velice ulehˇcit pr´aci.
Asi nejd˚uleˇzitˇejˇs´ı z nich je ˇcast´e synchronizov´an´ı k´odu se sd´ılen´ym repozit´aˇrem.
Pokud se n´am bˇehem mˇes´ıce nahromad´ı zmˇeny od jin´ych uˇzivatel˚u a my se bu-deme snaˇzit tyto zmˇeny zakomponovat do naˇs´ı lok´aln´ı verze, je t´emˇeˇr jist´e, ˇze dojde ke konfliktu, kter´y n´am 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´e edituj´ı stejnou ˇc´ast k´odu.
Jedna zmˇena by mˇela obsahovat pouze vˇeci, kter´e spolu souvisej´ı. Nedodrˇzen´ı to-hoto pravidla vede k vytv´aˇren´ım dlouh´ych popis˚u zmˇen, kter´e se stanou nepˇrehledn´e.
Vˇetˇsinou se vˇsak uchyluje k jednoduˇsˇs´ım zpr´av´am jako ”velk´a zmˇena”, kter´e jsou v podstatˇe nejhorˇs´ı, protoˇze o zmˇenˇe nic nevypov´ıdaj´ı.
V´ysledkem zmˇeny by mˇel b´yt opˇet funkˇcn´ı k´od. Pokud v´ıme, ˇze nˇeco nefun-guje naprosto spr´avnˇe, tak nem´a smysl vytv´aˇret zmˇenu. T´ım vznikaj´ı zmˇeny, do kter´ych se nelze vracet, protoˇze v danou dobu byla aplikace nefunkˇcn´ı. Ne vˇsak vˇzdy dok´aˇzeme urˇcit funkˇcnost aplikace a provedeme nevˇedomˇe nefunkˇcn´ı zmˇenu.
Prov´ad´ıme-li opravu jiˇz implementovan´ych funkc´ı a z´aroveˇn pˇrid´av´ame nov´e funkce, snaˇz´ıme se nem´ıchat tyto dvˇe poloˇzky do jedn´e zmˇeny. Pokud ovˇsem na sobˇe nejsou funkˇcnˇe z´avisl´e.
Posledn´ım a nejd˚uleˇzitˇejˇs´ım zvykem jsou spr´avnˇe popisky zmˇen. Popisek by mˇel obsahovat, jak´e ˇc´asti aplikace se zmˇena t´yk´a a co bylo opraveno nebo pˇrid´ano. Exis-tuje dokument [3], kter´y ˇr´ık´a jak popisky vytv´aˇret.
2.2 Pˇredstavitel´ e verzovac´ıch syst´ em˚ u
Existuje mnoˇzstv´ı verzovac´ıch syst´em˚u, kde kaˇzd´y vynik´a v urˇcit´ych oblastech. Pro pr´aci byly vybr´any syst´emy 3 nejpouˇz´ıvanˇejˇs´ı [2] syst´emy a to GIT, Mercurial a Ba-zaar. Mezi dalˇs´ı zn´amˇejˇs´ı pˇredstavitel´e patˇr´ı verzovac´ıch syst´em˚u patˇr´ı BitKeeper, CVS, Perforce a Team Foundation Server. V dobˇe vytv´aˇren´ı pr´ace existovalo celkem kolem 30 syst´em˚u pro verzov´an´ı.
2.2.1 GIT
GIT je syst´em p˚uvodnˇe vyvinut´y pro spr´avu zdrojov´eho k´odu pro j´adro Linuxu.
Byl vytvoˇren Linusem Torvaldsem, kter´y je zakladatelem Linuxu. Je zaloˇzen na sn´ımkov´an´ı k´odu. Pokud uˇzivatel provede zmˇenu na souboru, tak se vytvoˇr´ı sn´ımek souboru, kter´y reprezentuje stav souboru pˇred zmˇenou. Ukl´adaj´ı se tedy vˇzdy cel´e soubory. Hlavn´ı vlastnosti GIT jsou :
• Vytv´aˇren´ı sn´ımk˚u soubor˚u.
• 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´e oznaˇcovan´y jako HG, je v´ysledkem pr´ace Matta Mackalla. Ten zaˇcal s v´yvojem ve stejnou dobu, jako se zaˇcal vyv´ıjet GIT. Vˇetˇsina syst´emu je napsan´a v jazyce Python, ˇc´ımˇz se st´av´a multiplatformn´ı. Narozd´ıl od GIT pouˇz´ıv´a pouze rozd´ılov´e zmˇeny, ˇc´ımˇz je m´enˇe n´aroˇcn´y na datov´y 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´e grafick´e n´astroje.
2.2.3 Bazaar
Bazaar je syst´em podporovan´y firmou Canoncial, kter´a stoj´ı za v´yvojem zn´ame linuxov´e distribuce Ubuntu. Jedn´a se o multiplatformn´ı syst´em napsan´y v jazyce
Python. V´yvoj se opˇet datuje do stejn´eho obdob´ı jako u dvou pˇredchoz´ıch syst´em˚u.
V posledn´ı dobˇe syst´em neprojevuje vˇetˇs´ı v´yvoj a je sp´ıˇs na ´ustupu. Nicm´enˇe z histo-rick´ych d˚uvod˚u jsou pomoc´ı nˇeho verzov´any projekty jako MySQL, MariaDB nebo GNOME.
2.3 Sestavovac´ı syst´ em
Ze zdrojov´eho k´odu je potˇreba vytvoˇrit spustitelnou aplikaci. Tento proces m˚uˇze b´yt komplikovan´y a ve v´ysledku se skl´adat z nˇekolik po sobˇe jdouc´ıch ˇcinnost´ı, kter´e je nutn´e manu´al vykon´avat. At’ uˇz se jedn´a o kompilace, aktualizov´an´ı datab´aze nebo kop´ırov´an´ı soubor˚u, jde t´emˇeˇr vˇsechno zautomatizovat.
Vezmˇeme si opˇet pˇr´ıklad, na kter´em si vysvˇetl´ıme jakou m´a ´ulohu sestavovac´ı syst´em s vyuˇzit´ım predchoz´ı znalosti o verzovac´ıch syst´emech. Mˇejme webovou apli-kaci, kterou upravujeme na lok´aln´ım poˇc´ıtaˇci a mus´ıme ji vystavit na veˇrejn´y web.
Ukol, kter´´ y n´as potk´a vˇzdy, je kop´ırov´an´ı nov´ych soubor˚u na ´uloˇziˇstˇe, kde bude aplikace veˇrejnˇe dostupn´a. Otevˇreme tedy libovoln´eho spr´avce soubor˚u a pˇrekop´ırujeme vˇsechna potˇrebn´a data. Pozdˇeji zjist´ıme, ˇze je lepˇs´ım ˇreˇsen´ım je vytvoˇren´ı skriptu, kter´y ´ukony vykon´a za n´as. At’ uˇz kop´ırujeme soubory skrze FTP, SSH nebo jin´y pro-tokol, jistˇe nalezneme i n´astroj, kter´y toto bude dˇelat za n´as. Jedn´ım ze z´akladn´ıch n´astroj˚u je synchronizace adres´aˇr˚u. V´ysledkem je tedy skript, kter´y spust´ıme ruˇcnˇe pˇr´ıkazem.
Dalˇs´ım ´ukolem m˚uˇze b´yt generov´an´ı jazykov´ych pˇreklad˚u pro aplikace. Pokud pouˇz´ıv´ame gettext [5], je nutn´e soubor s pˇreklady kompilovat. Pˇri pˇrid´an´ı nov´ych pˇreklad˚u je nutn´e soubor ruˇcnˇe zkompilovat a n´aslednˇe ho nahr´at spoleˇcnˇe s ostatn´ımi
soubory. Opˇet se jedn´a o vˇec, kterou m˚uˇzeme pˇridat do skriptu. Pˇridejme ho tedy na zaˇc´atek pˇredchoz´ıho skriptu, aby se pˇreklady zkompilovali a n´aslednˇe odeˇsleme vˇsechny soubory.
Pokud si chceme uchov´avat zmˇeny v datab´azi, existuje moˇznost pouˇz´ıvat n´astroj, kter´y n´am bude datab´azi automaticky aktualizovat. Nejjednoduˇsˇs´ı ˇreˇsen´ı je si ve sv´em projektu vytvoˇrit sloˇzku, do kter´e budeme pˇrid´avat soubory obsahuj´ıc´ı napˇr´ıklad SQL pˇr´ıkazy, kter´e se maj´ı nad datab´azi vykonat. Lepˇs´ıˇreˇsen´ı je opˇet vytvoˇrit skript, jenˇz n´am tyto soubory s´am spust´ı po nahr´an´ı. Pˇridejme ho tedy opˇet na zaˇc´atek naˇseho prvn´ıho skriptu, protoˇze je spr´avn´e nejdˇr´ıv upravit datab´azi a n´aslednˇe k´od, kter´y jiˇz poˇc´ıt´a se zmˇenami v datab´azi.
Aplikace je hojnˇe pouˇz´ıvan´a a nechceme, aby obsahovala chyby. Proto vyuˇz´ıv´ame i testov´an´ı, kter´e se spouˇst´ı pomoc´ı nˇekolika n´astroj˚u. M´ame jednotkov´e testy, kter´e v ide´aln´ım pˇr´ıpadˇe pokr´yvaj´ı vˇetˇsinu k´odu naˇs´ı aplikace. Tyto testy by mˇely b´yt spuˇstˇeny pˇred nahr´an´ım nov´eho k´odu na veˇrejn´y web. Opˇet je lze spouˇstˇet automa-ticky. Opˇet pˇrid´ame skript, kter´y spust´ı vˇsechny testy.
Pr´avˇe jsme pokryli znaˇcnou ˇc´ast ˇcinnost´ı, kter´e jsme museli prov´adˇet ruˇcnˇe, ale nyn´ı je dˇelaj´ı skripty za n´as. T´ım jsme vytvoˇrili automatick´y sestavovac´ı syst´em.
Jednotliv´e ˇc´asti syst´emu sv´aˇzeme se z´achytn´ymi h´aky verzovac´ıho syst´emu. Nejprve spust´ıme testy a jako posledn´ı nahrajeme aplikaci na veˇrejn´y web.
2.4 Testov´ an´ı
V pˇredchoz´ı kapitole bylo zd˚uraznˇeno testov´an´ı softwaru. Jedn´a se o ˇcinnost, jejiˇz n´avratnost nen´ı tak zˇrejm´a, protoˇze testov´an´ı pˇr´ımo negeneruje novou funkˇcnost
aplikace, kterou by z´akazn´ık mohl vidˇet. Nicm´enˇe zkuˇsenosti ukazuj´ı, ˇze vytv´aˇret testy m´a smysl[6].
Dobr´ym pˇr´ıkladem m˚uˇze b´yt klasick´y internetov´y obchod. Zde je kl´ıˇcovou vlast-nost´ı moˇznost dokonˇcen´ı objedn´avky. Firma vytvoˇr´ı pro z´akazn´ıka aplikaci, kter´a bude prod´avat jeho produkty na internetu. Jiˇz pˇri v´yvoji nˇekolikr´at zkouˇs´ı, zda jde dokonˇcit objedn´avka. Kdyˇz vˇse funguje spr´avnˇe, tak produkt z´akazn´ıkovi pro-daj´ı. Uplyne jist´a doba a z´akazn´ık, chce vytvoˇrit dalˇs´ı funkˇcnost. Firma pˇrid´a nov´e funkce a opˇet ovˇeˇr´ı zda, objedn´avka funguje, protoˇze se jednalo o velk´e z´asahy.
Vˇse se st´ale prov´ad´ı ruˇcnˇe a kaˇzd´y test zabere neopomenutelnou dobu. Za rok se z´akazn´ık opˇet ozve a chce vytvoˇrit zas´ıl´an´ı v´anoˇcn´ıch pouk´azek. Term´ın na reali-zaci je velmi kr´atk´y, a proto firma narychlo nasazuje odes´ıl´an´ı pouk´azek. Bohuˇzel aktualizace vyˇzadovala ´upravu komponenty, kter´a odes´ıl´a e-maily, takˇze k odesl´an´ı e-mailu je nutn´y dalˇs´ı povinn´y parametr. S t´ım ovˇsem nepoˇc´ıt´a odes´ıl´an´ı potvrzen´ı objedn´avky. A v´ysledkem je, ˇze se neodes´ılaj´ı e-maily po dokonˇcen´ı objedn´avky, coˇz je kl´ıˇcov´a vlastnost. Pokud by existoval test na odes´ıl´an´ı e-mailu s potvrzen´ım objedn´avky, nemohlo by k tomuto doj´ıt. Pˇri spuˇstˇen´ı vˇsech test˚u by doˇslo k chybˇe a sestavovac´ı syst´em by nedovolil aktualizovat aplikaci.
Existuje nˇekolik zp˚usob˚u testov´an´ı [9]:
• Program´atorsk´e - Dva program´atoˇri si navz´ajem kontroluj´ı k´od. Jeden k´od vytvoˇr´ı, druh´y k´od zkontroluje a vytvoˇr´ı pro k´od testy (zpravidla ruˇcnˇe otestuje funkce). Jedn´a se o nejm´enˇe n´akladn´e a nejv´ıce ´uˇcinn´e testov´an´ı.
• Jednotkov´e - N´asleduj´ı po program´atorsk´em testov´an´ı. Testovanou jednotkou lze rozumˇet jako oddˇelitelnou ˇc´ast aplikace, na kterou se vytvoˇr´ı test, jenˇz ovˇeˇr´ı jej´ı funkˇcnost. Aplikovat jednotkov´e testy do existuj´ıc´ıho projektu je
• Jednotkov´e - N´asleduj´ı po program´atorsk´em testov´an´ı. Testovanou jednotkou lze rozumˇet jako oddˇelitelnou ˇc´ast aplikace, na kterou se vytvoˇr´ı test, jenˇz ovˇeˇr´ı jej´ı funkˇcnost. Aplikovat jednotkov´e testy do existuj´ıc´ıho projektu je