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
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 vˇetˇsinou velmi sloˇzit´e. Pokud se tyto testy aplikuj´ı jiˇz pˇri v´yvoji aplikace, vedou k vytv´aˇren´ı kvalitn´ı k´odu.
• Funkˇcn´ı - Ovˇeˇruj´ı, zda je aplikace schopn´a plnit ´ukoly, pro kter´e byla navrˇzena a zda jsou splnˇeny vˇsechny poˇzadavky z´akazn´ıka. V pˇr´ıpadˇe internetov´eho obchodu by testov´an´ı objedn´avky spadalo pr´avˇe do funkˇcn´ıch test˚u.
• Integraˇcn´ı - Jedna z podmnoˇzin funkˇcn´ıho testov´an´ı. Kontroluje se spr´avn´a ko-munikace komponent aplikace mezi sebou, ale i napˇr´ıklad komunikaci s operaˇcn´ım syst´emem nebo hardwarem. U menˇs´ıch projekt˚u lze tuto ˇc´ast vynechat.
• Uˇzivatelsk´e - Aplikaci by mˇel pochopit i nˇekdo jin´y neˇz jej´ı v´yvoj´aˇr. Vezme se tedy n´ahodn´y ˇclovˇek a zadaj´ı se mu ´ukoly, kter´e m´a s aplikac´ı vykonat. Pokud je nedok´aˇze dokonˇcit ani s n´avodem, je vˇetˇsinou aplikace ˇspatnˇe navrˇzen´a.
T´ım je ukonˇcena motivaˇcn´ı ˇc´ast, proˇc pouˇz´ıvat n´astroje pr˚ubˇeˇzn´e integrace.
3 N´ avrh vlastn´ıho ˇ reˇ sen´ı
C´ılem pr´ace bylo sezn´amen´ı se s problematikou verzovac´ıch syst´em˚u a n´astroji pr˚ubˇeˇzn´e integrace. N´aslednˇe dan´e znalosti uplatnit pro n´avrh vlastn´ıho syst´emu pr˚ubˇeˇzn´e integrace, kter´y je zamˇeˇren na v´yvoj aplikac´ı v prostˇred´ı www aplikac´ı.
Tento n´avrh mˇel b´yt nakonec prakticky implementov´an.
3.1 Sezn´ amen´ı se s problematikou
Autor pr´ace jiˇz pˇred vytvoˇren´ım diplomov´e pr´ace mˇel zkuˇsenost s pouˇz´ıv´am verzo-vac´ıch syst´em˚u. Nejv´ıce byl sezn´amen s verzovac´ım syst´emem Mercurial. Bylo nutn´e vylepˇsit znalosti o syst´emu GIT a Bazaar.
GIT jako nejpouˇz´ıvanˇejˇs´ı verzovac´ı syst´em poskytuje ˇsirokou ˇsk´alu dokumentaˇcn´ıch materi´alu. Existuje nˇekolik webov´ych aplikac´ı, kter´e umoˇzˇnuj´ı spr´avu repozit´aˇre skrze vzd´alen´y pˇr´ıstup. Inspirovat se je moˇzn´e napˇr´ıklad na projektu GitHub [7], kter´y poskytuje jedno z nejl´epe zpracov´an´ych rozhran´ı pro spr´avu repozit´aˇre po-moc´ı grafick´eho rozhran´ı.
Stejnˇe tak Mercuri´al je velice dobˇre zdokumentovan´y syst´em. Mezi nejzn´amˇejˇs´ı grafick´e n´astavby patˇr´ı HgTurtoise, kter´y poskytuje vˇsechny potˇrebn´e vlastnosti pro celkovou spr´avu repozit´aˇre. Autorova znalost Mercurialu vˇsak postaˇcuje pro potˇreby,
kter´e bude v´ysledn´y syst´em obsahovat.
U syst´emu Bazaar se uk´azalo, ˇze se jiˇz nad´ale aktivnˇe nevyv´ıj´ı, a proto od jeho implementace do v´ysledn´eho syst´emu bylo upuˇstˇeno. Posledn´ı aktualizace Bazaaru byla podle domovsk´e str´anky projektu [4] provedena v z´aˇr´ı roku 2013 a nad´ale se nepl´anuje jeho dalˇs´ı v´yvoj.
Sezn´amen´ı se s n´astroji pr˚ubˇeˇzn´e integrace nebo cel´ymi syst´emy bylo obt´ıˇznˇejˇs´ı.
Existuje nˇekolik des´ıtek syst´em˚u, kter´e poskytuj´ı n´astroje pro pr˚ubˇeˇznou integraci.
Liˇs´ı se v platform´ach, licenc´ıch, podpoˇre pro IDE a ostan´ıch vlastnostech [8]. Mezi nejzn´amˇejˇs´ı syst´emy patˇr´ı Jenkins, Travis a TeamCity. Vˇsechny tyto syst´emy maj´ı nˇekolik sv´ych priorit, kter´ymi se d´a inspirovat. Podporuj´ı vystaven´ı k´odu 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´ych znalost´ı a dosavadn´ıch zkuˇsenost´ı autora byl vytvoˇren n´avrh vlastn´ıho syst´emu. Syst´em mus´ı splˇnovat n´asledujic´ı 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´ı
Pro spr´avu repozit´aˇru je tˇreba vytvoˇrit vlastn´ı syst´em, kter´y bude na vstupu pod-porovat dva r˚uzn´e druhy repozit´aˇr˚u. Repozit´aˇre pro syst´em GIT a Mercuri´al. Bude kladen d˚uraz na jednoduchost nastavov´an´ı repozit´aˇr˚u a moˇznost vykon´avat z´akladn´ı operace nad repozit´aˇri. Tedy vytvoˇren´ı repozit´aˇre, klonov´an´ı repozit´aˇre, zjiˇstˇen´ı potˇrebn´ych ´udaj˚u o repozit´aˇri a pˇr´ıpadnˇe i jeho smaz´an´ı. Souˇc´ast´ı syst´emu pro spr´avu repozit´aˇr˚u bude i moˇznost nastavov´an´ı vlastn´ıch sestavovac´ıch skript˚u. Pˇri vytv´aˇren´ı skriptu bude kladen d˚uraz na co nejvˇetˇs´ı intuitivnost pˇri jeho vytv´aˇren´ı.
Bude pouˇzit n´avrh pomoc´ı grafick´eho editoru, kter´y bude obsahovat funkˇcn´ı bloky.
Tyto bloky bude uˇzivatel spojovat a tak vytv´aˇret sloˇzitˇejˇs´ı funkce.
Pro spr´avu pˇr´ıstup˚u k repozit´aˇr˚um bude vytvoˇren dalˇs´ı syst´em, kter´y bude spravovat pˇr´ıstupy pomoc´ı protokolu SSH. Tento syst´em bude m´ıt za ´ukol iden-tifikovat pˇr´ıchoz´ı spojen´ı a ovˇeˇrit, zda m´a povolen´ı nad dan´ym repozit´aˇrem prov´est poˇzadovanou ˇcinnost. Jeho dalˇs´ıˇcinnost bude upravovat soubory operaˇcn´ıho syst´emu, kter´e maj´ı za ´ukol obsluhovat pˇripojen´ı pomoc´ı protokolu SSH.
Pro moˇznost vytvoˇren´ı sestavovac´ıho skriptu bude nutn´e vytvoˇrit vlastn´ı ja-zyk, pomoc´ı kter´eho se bude skript vytv´aˇret. Dosavadn´ı, autorem nalezen´e jazyky a n´astoje, nejsou dostateˇcnˇe ohebn´e, aby se daly jednoduˇse sestavovat v grafick´em rozhran´ı. Zde se nach´az´ı asi nejsloˇzitˇejˇs´ı ˇc´ast pr´ace, kter´e bude vˇenov´an nejvˇetˇs´ı d˚uraz.
Jako hlavn´ı programovac´ı jazyk bude zvolen PHP, protoˇze ho autor nejl´epe ovl´ad´a. Sestavovac´ı skripty budou ve form´atu XML, protoˇze tento form´at posky-tuje dobr´e n´astroje pro validaci. Syst´em bude c´ılit hlavnˇe na v´yvoj´aˇre pouˇzivajic´ı volnˇe ˇs´ıˇriteln´y nebo svobodn´y software. Proto bude hlavn´ım platformou operaˇcn´ı syst´em Linux.
4 Vlastn´ı ˇ reˇ sen´ı
V n´asleduj´ıc´ı ˇc´asti pr´ace se budeme zab´yvat implementac´ı konkr´etn´ıho syst´emu, kter´y si klade za c´ıl poskytnout uˇzivateli vˇsechny potˇrebn´e n´astroje, aby mohl zaˇc´ıt vyuˇz´ıvat pr˚ubˇeˇznou integraci pro sv˚uj projekt. Z´aroveˇn klade d˚uraz na jednoduchou instalaci, intuitivn´ı ovl´ad´an´ı a pˇrehledn´e v´ystupy. Syst´em je rozdˇelen do tˇr´ı ˇc´ast´ı.
Jazyk je zvolena angliˇctina, aby nebyla aplikace omezen´a pouze pro n´arodn´ı trh.
Skrze rozhran´ı, kter´e aplikace poskytuje je moˇzn´e prov´est lokalizaci do jak´eho koliv jin´eho jazyka.