View
2
Download
0
Category
Preview:
Citation preview
Tallinna ÜlikoolMatemaatika-loodusteaduskond
Informaatika osakond
PHP-põhise tarkvaraarenduse abivahendid.
SeminaritööAhti Nurme
Juhendaja: Jaagup Kippar
Autor: ...................................“.....“..............2006.a.Juhendaja:...............................“.....“..............2006.a.Osakonnajuhataja:..................“.....“..............2006.a.
2006 Tallinn
1
Sisukord 1 Sissejuhatus......................................................................................................................................3
1.1 Teema valiku põhjendus...........................................................................................................3 1.2 Probleemi sõnastus...................................................................................................................3 1.3 Töö eesmärk..............................................................................................................................4 1.4 Töö tulemus..............................................................................................................................4 1.5 Töö struktuur.............................................................................................................................4
2 PHP-põhine tarkvaraarendus ja selle abivahendid...........................................................................5 2.1 Tarkvaraarenduse mõiste..........................................................................................................5 2.2 Uuritava tarkvara ehk AutomatWebi tutvustus.........................................................................7
2.2.1 AW Object Request Broker...............................................................................................8 2.2.2 AW Classbase....................................................................................................................9 2.2.3 AW Storage.....................................................................................................................10 2.2.4 Kasutatavad tehnoloogiad...............................................................................................10
3 Veahalduse, koodihalduse, paketihalduse ja koodi dokumentatsiooni tähtsus tarkvaraarenduses. 12 4 Paketihaldus....................................................................................................................................15
4.1 RPM........................................................................................................................................16 4.2 Dpkg........................................................................................................................................19 4.3 FreeBSD Ports Collection.......................................................................................................21 4.4 Autopackage............................................................................................................................22
5 Veahaldus........................................................................................................................................24 5.1 Bugzilla...................................................................................................................................26 5.2 Mantis BugTracker.................................................................................................................27 5.3 Flyspray..................................................................................................................................27 5.4 JIRA........................................................................................................................................28 5.5 Trac.........................................................................................................................................29 5.6 AW BugTrack..........................................................................................................................30
6 Koodihaldus....................................................................................................................................32 6.1 GNU Arch...............................................................................................................................35 6.2 Bazaar.....................................................................................................................................36 6.3 BitKeeper................................................................................................................................36 6.4 CVS.........................................................................................................................................37 6.5 Subversion..............................................................................................................................38
7 Koodi dokumentatsioon..................................................................................................................40 7.1 Javadoc....................................................................................................................................41 7.2 phpDocumentor......................................................................................................................41 7.3 PHPDoc..................................................................................................................................42 7.4 AW DocGen............................................................................................................................43 7.5 PHPXref..................................................................................................................................43
8 Kokkuvõte......................................................................................................................................45 9 Kasutatud infoallikad......................................................................................................................48 10 Lisad.............................................................................................................................................49
10.1 Lisa 1: Javadoci levinumad märgendid................................................................................49 10.2 Lisa 2: AW DocGeni praegune süntaks ja kuvapildistus......................................................49 1.1 Lisa 3: AW BugTracki kuvapildistus......................................................................................52
2
1 Sissejuhatus
1.1 Teema valiku põhjendusOlles ise kokku puutunud programmeerimisega juba aastast 1999, alguses Perliga ja praeguseni
PHP-ga, jäid minu teadmised ja oskused kuni eelmise aasta sügiseni suures osas vaid PHP
programmeerimise tasemele, arusaam ja mõistmine tarkvaraarenduse olemusest on alles praegu
järkjärgult välja kujunemas. Osalt oli see ka tingitud valitud programmeerimiskeele spetsiifikast,
kuid suures osa ka PHP põhise tarkvara uudsusest ja sellest tulenevast reglementeerimatusest.
Iseenest on ka PHP võimalused rakenduste valmistamisel oma Easy Deploy metoodika tõttu vägagi
huvi pakkuv uurimisteema, otsustasin siiski keskenduda esialgu sellega seotud temaatikale.
Praeguseks hetkeks on AutomatWebi temaatikal valminud 3 bakalaureusetööd, millest 2 on
käsitlenud süsteemi üldiselt ja üks on käsitlenud kvaliteedi ja protsessijuhtimist AutomatWebi
kontekstis, selletõttu tundus minu jaoks ülekohtune, et kõik kirjatükid on keskendunud pigem
AutomatWebi funktsionaalsusele ja välimisele küljele, mitte arendamisele. Selletõttu sai antud
temaatika käsitluse alla võetud. Kuna AutomatWebi areng tavapärasest veebiskript tegemisest
tarkvaraarendusliku lähenemiseni on senimaani olnud vägagi aeglane ja puudulik, vajab
tarkvaraarendus antud kontekstis lähemat uurimist ja väljatöötamist, et saada parim võimalik
tulemus. Kuna tarkvaraarendus kui selline on oma olemuselt väga keeruline ja mitmekoeline
süsteem, käsitleb seda temaatikat mõnes järgnevas töös. Sellepärast sai esialgu keskendutud just
tarkvaraarendust toetavatele tegevustele, mille põhjal saab järgmises ringis juba sügavuti minna
AutomatWebi enda arendamise juurde.
1.2 Probleemi sõnastusAastast 1999 tegutsev veebifirma Struktuur Meedia on kogu see aeg arendanud veebipõhist
tarkvaraplatvormi AutomatWeb. Alguses puhtalt PHP3-põhise CMS rakendusena alguse saanuna,
on põhiarendus liikumas PHP5 peale, muutudes PHP põhisest arendusest suures osas
teadmuspõhiseks arenduseks. Seni läheneti arendusele veebifirmade moodusel, viies muudatusi
sisse vastavalt vajadusele, kuid seos klientide arvu kasvuga on kasvamas üle pea erinevate
versioonide ja veaparanduste omavaheline sobitamine, tekitades tõsine vajadus tarkvaraarenduse
juhtimise konkretiseerimiseks, alustades sellega seotud taustprotsessidest, eelkõigega sooviga
pakkuda paremaid, lihtsamaid ja töökindlamaid lahendusi.
3
1.3 Töö eesmärkSeminaritöö eesmärk konkreetsemalt on teha ülevaade antud ettevõtte konteksti tarkvaraarenduseks
sobivate vahendite kohta ja nende rakenduse otstarbekusest ja võimalusest PHP spetsifiikas,
üldisemas plaanis on kolm eesmärki:
– Panna märk maha PHP põhise tarkvaraarenduse problemaatikast;
– Tekitada mingitmoodi juhis teistele sama temaatikaga kokku puutuvatele organisatsioonidele;
– Anda teemast huvitatutele programmeerijatele võimalus antud valdkonnaga tutvuda.
Eelkõige keskendume siinkohal neljale vahendile: koodihaldus, paketihaldus, veahaldus ja koodi
dokumentatsioon. See valik ei ole olnud juhuslik, vaid konkreetselt seotud AutomatWebi arengus ja
plaanides viimasel kahel aastal toimunuga: koodihaldus on välja kasvamas CVS-ist, paketihaldus on
teemaks olnud juba üle 2 aasta, veahalduse kohapealt sai AW BugTrack alustatud umbes aasta
tagasi ning sai arenguhoo sisse nüüd, 2006 alguses ning koodi laiaulatuslikum dokumenteerimine
AW DocGen abiga on praegu teoks saamas.
1.4 Töö tulemusTöö tulemusena peaks valmima ülevaade turul saadaolevatest vahenditest ja ka isearendamise
võimalustest ja otstarbekusest, seda eelkõige ülevaadete ja soovituste formaadis. Täpsemalt üritame
lahata ka antud vahendite sobivust AutomatWebi arenduse konteksti, proovides leida parimat
lahendust antud töö raames, mille põhjal saaks rakendamist planeerima asuda. Üldisemalt võib seda
käsitleda ka kui juhtnööre PHP-põhise tarkvaraarenduse “pakendamise” võimalustest lihtsast ja
struktureerimata veebiprogrammeerimise kontekstist konkreetsemasse ja jätkusuutlikumasse
tarkvaraarenduse konteksti.
1.5 Töö struktuurÜlesehituselt jaguneb töö kolmeks:
1. Sissejuhatus teemasse, kus käsitletakse valitud tarkvara ning PHP-põhise tarkvara arenduse
spetsiifikat ning valitud teemade (koodi dokumentatsioon, koodihaldus, paketihaldus ja
veahaldus) üldisemat tutvustust ja tähtsust AutomatWebi arenduses.
2. Konkretiseerimist, kus tutvustatakse iga teema kohta olemasolevaid lahendusi, pakutakse
4
omapoolseid variante ning antakse hinnang valiku kohta.
3. Kokkuvõte, kus üritatakse leitud lahendusi mõtestada lahti ühtse tervikuna, analüüsida
koostoimet ning pakkuda kava edasiseks tegevuseks.
2 PHP-põhine tarkvaraarendus ja selle abivahendid
2.1 Tarkvaraarenduse mõisteEt mõista PHP-põhise tarkvaraarenduse spetsiifikat, peab kõigepealt seletama lahti
tarkvaraarenduse kui sellise: lihtsalt seletades on tarkvaraarendus on tarkvara loomeprotsess.
Üldjuhul peetakse tarkvaraarenduse all silmas tarkvara loomist inimgrupi poolt, kokkulepitud
reeglite alusel. Formaalset tarkvara loomist üksikisiku poolt nimetatakse sageli lihtsalt
programmeerimiseks (kuigi ka see võib sisaldada kõiki protsessi samme). Tarkvaraarenduse
protsessi täpne kuju sõltub peamiselt arendatava tarkvara otstarbest ning loojate eelistustest ning
kogemustest.
Klassikaliselt sisaldab tarkvaraarendus järgmisi tegevusi (Pilt 3):
• Süsteemianalüüs (sageli ka nõuete analüüs, või spetsifitseerimine) - luuakse või määratakse
kindlaks see, mida loodav tarkvara tegema peab, sageli ka lahenduse üldkuju. Sageli
kasutatakse selleks prototüüpimist, mille käigus luuakse tulevase lahenduse osaline mudel,
erinevate lahendusvariantide katsetamise või probleemi parema mõistmise eesmärgil.
• Disain - luuakse tarkvara sisemine arhitektuur - loogiline ülesehitus ning erinevate omaduste
jaotus programmi osade vahel. Sageli luuakse disain väga üksikasjalik - pseudokoodi
tasemel.
• Programmeerimine – disainitud lahendus teostatakse programmeerimiskeeles, vajadusel
kujundatakse tarkvara kasutajaliides. Sageli on disaini ja programmeerimise vahelise piiri
tõmbamine raske. Mõned allikad peavad täpseimaks disainiks testitud programmi
lähtekoodi.
• Testimine – kontrollitakse lahenduse töökindlust, jõudlust ja eesmärgipärasust.
• Juurutamine – olenevalt loodava tarkvara tüübist võib see tähendada nii tarkvara
paigaldamist konkreetsesse keskkonda, kui ka lihtsalt müüki paiskamist. Sageli hõlmab
juurutamine ka kasutajate koolitamist tarkvaraga töötamiseks.
• Hooldus – vigade parandamine, täiendavate omaduste lisamine, kohandamine muutuva
keskkonnaga, klienditugi.
5
Pilt 3. Tarkvaraarenduse elutsükkel.
Nende tegevuste tegemise ulatus, järjekord ja täpne sisu olenevad suuresti arendaja poolt
kasutatavast tarkvaraprotsessist. Näiteks viiakse nn. kosemudeli kohaselt eelnimetatud sammud läbi
üksteise järel. Iteratiivse mudeli kohaselt seevastu koosneb kogu protsess mitmest järjestikusest
tsüklist (iteratsioonist) mis kõik sisaldavad analüüsi, disaini, programmeerimist ja testimist kuid
erinevates tsüklites on rõhk erinevatel sammudel. Tarkvara protsessimudeleid on praeguseks
hetkeks tekkinud väga palju, igaüks oma spetsiifikaga, ning need arenevad pidevalt edasi.
Vaadeldaval juhul ei lõppe tarkvaraarendus hooldusega, vaid on pidevalt kordu protsess.
PHP on tarkvara kontekstis vägagi omapärane nähe: oma jõulise tulekuga 1999. aastast alates, kui
lasti välja 4. versioon, on tekitanud väga huvitava olukorra, nimelt veebi tarkvarastumise. Kuni selle
ajani oli veeb vägagi staatiline, vaid suuremad portaalilahendused olid dünaamiliselt genereeritavad,
kui viimase kuue aasta jooksul on suurem osa veebist läinud üle dünaamilisele sisule, lõviosa
nendest PHP-põhisel platvormil. Kuigi Microsoft ja Sun on oma .NET ja Java erinevate
versioonidega üritavad olemasolevat vahet tasa teha, on rong praegusel hetkel nende jaoks läinud:
PHP on vaieldamatult kõige populaarsem veebirakenduste valmistamise keel1.
See omakorda nõuab teistmoodi lähenemist tarkvaraarendusse, kui tavapäraste
programmeerimiskeelt nagu Java, C/C++ ja Visual Basic puhul. Tavapäraselt on tarkvaraarenduse
1 http://www.php.net/usage.php
6
eesmärgiks saada kohe alguses parim lahendus, kuna ümbertegemine on kallim ja keerukam kui
uuesti tegemine, siis PHP puhul on see probleem väiksema skaalaga. Olles oma olemuselt madala
taseme skriptikeel, millele ei ole veel tehtud visuaalseid arenduskeskkondi (nagu teistele keeltele),
on see siiski väga kiirelt omandatav, kirjutatav ja võimekas. Sellest tulenevalt peab
arendamisprotsess olema paindlik, et see arenduskiirust takistama hakkaks, kuid samas piisavalt
põhjalik, et kataks vajadusel ka teadmuspõhise arenduse. Sellest tulenevalt on suurem osa PHP
arendust, vähemalt Eestis, mingi modifikatsioon XP-st[x].
Senimaani on üle 6 aasta toimunud AutomatWebi arendamine toimunud küll visioonorienteeritult,
planeerides tuleviku jaoks, kuid tegevus ise on seni olnud küllaltki piiritlemata, eelkõige
töömahtude ja arendusmeeskonna väiksuse tõttu. Kuna AutomatWebi suurus on viimase 2 aasta
jooksul kahekordistunud (kui aastal 2004 oli 200,000 koodirida, siis praeguseks on peaaegu
400,000), kuid meeskonna maht jäänud enamvähem samaks, on tekkinud vajadus peale meeskonna
jõulise laiendamise ka hallata ja koordineerida paremini AutomatWebi arendamist. Samas on
muutunud ka tegevuste spetsiifika: kui 2004 aastal oli põhiline arendustegevus koondunud
sisuhalduse ja AW baassüsteemi võimaluste arendamisele ning saadi hakkama tavapärase mudeliga,
kus programmeerija arendas võimalusi, kujundaja lõi kujunduse ja sidus HTML-iga ning
projektijuht testis/suhtles kliendiga/haldas sisu, siis praeguseks on suurem osa arendustegevusest
koondunud eelkõige ärirakendustele, nagu kliendihaldus ja ressursiplaneerimine, kus oleks vaja
veidike konkreetsemat rollide jaotamist, kui seni on toimunud, ning see on omakorda seotud antud
uurimustöö temaatikaga.
2.2 Uuritava tarkvara ehk AutomatWebi tutvustusKuna töö olemuse mõistmiseks on tähtis ka uuritava tarkvara tundmine, toon järgnevalt ära
AutomaWebi lühikese tutvustuse:
AutomatWeb on Struktuur Meedia väljatöötatud üle interneti kasutatav tarkvaraplatvorm
veebilahenduste jaoks. AutomatWebi nimetatakse platvormiks, kuna üks ja sama tarkvara baasosa
koondab endas kümmekond erinevat tooteperekonda. See on AutomatWebi peamisi eeliseid - ennast
tõestanud platvorm koos suure moodulite hulgaga.
Praeguseks võib AutomatWebi ühtses tarkvarakeskkonnas kasutada kõiki populaarsemaid interneti
teenuseid alates sisuhaldusest kuni aja- ja kliendihalduseni. Uute võimaluste hulk kasvab kiiresti
tänu süsteemi paindlikkusele.
7
Platvormi ülesehitusest ehk süsteemiarhitektuurist sõltuvad väga paljud omadused: avatus uutele
arendustele, paindlikkus ja liidestatavus, turvalisus.
AutomatWebi süsteemiarhitektuur põhineb kolmel sambal ehk kolmel olulisemal tehnoloogial (Pilt
9).
Pilt 9. AutomatWebi süsteemiarhitektuur.
Igal sambal on oma väljundid nii tootearendajatele kui ka praegustele ja tulevastele AutomatWebi
klientidele:
2.2.1 AW Object Request BrokerAW Object Request Broker on närvikeskus, mis vahendab programmisiseseid ja väljast tulevaid
päringuid. Veebipõhiste tarkvarade puhul toimub programmile käskude edasiandmine hüperlingi
ehk URLi kaudu, mida kontrollib ORB. ORB on moodulite vahelise suhtluse protokoll, mis
võimaldab näiteks eri programmeerimisekeeltes loodud ning eri serverites asuvatel moodulitel
omavahel suhelda.
Teiseks on ORB meetod, millega kirjeldatakse XML formaadis ära mooduli API kasutamise
tingimused. See võimaldab kasutajal süsteemi kasutada just niipalju, kui ORBi kihis on
deklareeritud ning ei luba mooduli seest suvalisi funktsioone ja parameetreid välja kutsuda.
8
ORBi väljundid:
• täiendav koht, kus kontrollitakse kasutajaõigusi,
• valideeritakse kasutaja poolt sisestatud infot, sealhulgas URLe. Alles siis, kui andmed on
valideeritud, tõmmatakse vastav klass käima. See suurendab tunduvalt süsteemi turvalisust
häkkimise vastu,
• võimaldab päringuid ka teistest süsteemidest vastu võtta,
• URLides kasutatavate avalike meetodite dünaamiline genereerimine,
• tagab AWle XML-RPC Web Services toe kogu programmi ulatuses,
• on lüliks AW API ja teiste süsteemide vahel üle Web Services kihi (XML-RPC, SOAP),
• klassidele saab luua erinevaid liideseid ORBi tasemel.
2.2.2 AW ClassbaseAW Classbase on täiendav abstraheerimise vahend klassipõhiselt kasutajaliidese ehitamiseks ja
sellega manipuleerimiseks. Tänu Classbasele käib AutomatWebi uute ühtlase kasutajaliidesega
moodulite loomine kiiresti. Kogu funktsionaalsus mida lõppkasutaja ekraanilt näeb, pärineb
andmebaasist, kus on ära kirjeldatud kõik kasutajaliidese võimalused. Klassi ehk mooduli
vormistamise viimane tegevus on kogu AW omaduste andmebaasi põhjal uue kasutajaliidese kihi
kompileerimine.
Classbase väljundid:
• lihtsustab ja kiirendab kasutajaliidese ehitamist,
• ühtlane visuaalsetel komponentidel põhinev kasutajaliides lõppkasutajale,
• uute visuaalsete komponentide kasutamine koheselt kogu AW ulatuses,
• liidese stiilide muutmine ühest kohast,
• erinevate kujundusmallidega HTML liideste loomine,
• ühtne andmete salvestamise loogika ja valideerimisvõimalused,
• klassi omaduste kirjeldamine päises lisab AWle läbipaistvuse, teeb koodi vabalt loetavaks,
• ühele klassile võib samas süsteemis luua mitu erinevat kasutajaliidest,
• standardiseerib klassi vormistuse,
• võimaldab AWle genereerida teisi kasutajaliideseid peale HTMLi (näiteks Applet, GTK,
Winforms, XAML, XUL),
• tagab seostehalduri mugava kasutamise.
9
2.2.3 AW StorageAW Storage eesmärk on rakenduste tasemel päringute võimalikult abstraktne kirjeldus ja ühtse
päringuloogika tagamine kogu programmi ulatuses. AW Storaget võib kujutleda suure
torustikuvõrguna, läbi mille liiguvad kõik AW andmepäringud. Storage suunab andmed vastavalt
parameetritele kitsamate torude kaudu näiteks läbi andmeallika filtri My-SQL andmebaasi või läbi
integratsioonikihi välistesse rakendustesse.
Storage üheks olulisemaks alamkomponendiks on seostehaldur, mis haldab dünaamiliselt
objektidevahelisi seoseid. Dünaamiline seos on näiteks kliendibaasis leiduva organisatsiooni alla
lisatud sündmuse (kõne, kohtumine, leping jt) automaatne seostamine lisaja personaalse kalendriga.
Seostehaldur on abiks ka käsitsi seoste loomisel, näiteks saab kalendrisündmusega siduda faile
(koosolekuprotokoll) ja teisi objekte. Seostehaldur muudab objektidevaheliste seoste loomise
süsteemile ja lõppkasutajatele ühtlaseks ja võimaldab objekte korduvkasutada.
Storage väljundid:
• kasutajaõiguste kontrollimine,
• ühtlustatud andmebaasipäringud,
• minimeerib vigaste päringute arvu,
• muudab päringute optimeerimise tsentraalseks,
• garanteerib õiguste kontrolli päringute/andmete tasemel,
• võimaldab granulaarselt andmepäringuid vahemällu salvestada (cacheda),
• päringud salvestatakse kompileeritud kujul massiivi,
• võimaldab hõlpsasti lisada teiste andmebaasiserverite tuge kogu programmi ulatuses,
• võimaldab saada ülitäpse ülevaate sellest, milliseid päringuid süsteemis tehakse,
• tagab ühtse loogikaga objektidevahelised seosed.
2.2.4 Kasutatavad tehnoloogiadAutomatWebi töö ei eelda ühegi tasulise tarkvara olemasolu. AutomatWeb on täielikult
programmeeritud PHP4-s ja kasutab sujuvaks töötamiseks ka PHP- või ZEND-Acceleratorit.
Praktikas töötab AutomatWeb Linux, Free- ja Open BSD, AIX, Solaris ja muudes UNIXi laadsetes
operatsioonisüsteemides. On lahendusi, kus AutomatWeb töötab ka Windows platvormil, kuid
problemaatilisena.
AutomatWebi objektisüsteemi andmebaasiserverina kasutatatakse My-SQLi. Suhtlemine My-SQL
andmebaasiga käib üle vastava draiveri. Käesolevaks hetkeks on AutomatWebile arendatud ka MS-
10
SQL draiver, praktilist kasutamist leiab see lisandväärtusega teiste andmebaasiserveritega
suhtlemisel [3]. AutomatWebi detailsema kirjelduse võib leida Raul Viigipuu 2005 aastal valminud
lõputööst „Ülevaade AutomatWebi platvormist. HTML kujunduse ühendamise juhend
AutomatWebiga“.
11
3 Veahalduse, koodihalduse, paketihalduse ja koodi dokumentatsiooni tähtsus tarkvaraarendusesAntud uurimustöö puhul on vägagi tähtis lahti seletada, mis tähtsus on nimetatud vahenditel PHP-
põhises tarkvaraarenduses, nii üldiselt kui ka AutomatWebi spetsiifiliselt lähenedes.
Kuna tarkvara kui selline ei ole oma olemuselt monoliitne moodustis, mis saaks mingi hetk valmis
ja püsiks sellisena 600 aastat, vaid on pidevas ja korduvas arengus, peavad olema kõik selle
arendamist toetavad tegevused olema sama paindlikud. Esmatähtis on alati kõige värskema ja
asjakohasema informatsiooni saamine, nii tarkvara arendustsüklist üldiselt, kui ka selle
konkreetsetest etappidest. Just selle informatsiooni pakkumine ongi antud tööriistade ülesanne.
Kuid tähtis ei ole mitte ainult informatsioon ja ülevaatlikus ise, vaid selle asumine üldises
kontekstis, mida pakub terve arendusprotsessi talletamine, millega tegeleb iga tööriist ise küljest.
Koodihaldus talletab kogu tarkvara elutsükli jooksul arendatud koodi, mille põhjal saab hiljem
ennustada edaspidiseid tegevusi ning lähenemisi, veahaldus toetab tarkvaraarendamist selle kõikidel
eluetappidel, andes arendajatele otsest tagasisidet koodi kvaliteedi kui ka funktsionaalsuse kohta,
koodi dokumentatsioon on „sotsiaalne mälu“ nii testimise kui arendamise juures, võimaldades uut
ja olemasolevat funktsionaalsust kiiremini ja lihtsamini rakendada ning paketihaldus, andes
kasutajatele võimaluse paindlikuks uuendamiseks ja kasutamiseks, testijale läbi veahalduse ülevaate
koodi küpsusest, arendajale tagasiside funktsionaalsuse kasutatavuse ja veaparanduste efektiivuse
kohta ning palju-palju muudki (Pilt 4).
12
Pilt 4. Koodihalduse, paketihalduse, veahalduse ja koodi dokumentatsiooni seotus tarkara arendustsükli erinevate etappidega.
Seda kõike muidugi ideaaljuhul, kui tegevuste haldamine käib läbi mainitud tööriistade, mistõttu
peab nende kasutamine, kasutuselevõtmine ja koostoime olema kas võimalikult lihtne, võimalikult
efektiivne või mõlemat. Mis toobki meid vajaduse juurde määratleda ära see täpsem vajadus, mille
põhjal saaks hakata otsima parimat lahendust. Üks hea printsiip, mida siinjuures silmas pidada, on
KISS põhimõte: „Keep It Simple, Stupid“ ehk kõige suurema funktsionaalsusega vahend ei ole
tingimata alati parim, kui seda ei saa mugandada konkreetsetele vajadustele vastavaks. Samas tekib
ka küsimus, miks arendada ise, kui on võimalus võtta kasutusel juba valmistoode, mis pakub sama
funktsionaalsust? Ühest vastust on siinkohal raske anda, kuid vähemalt nendes osas, mille
arendamine on realistlik (koodihaldus seda kohe kindlasti ei ole), on seni töötanud kõige paremini
just ise valmistatud lahendused, eelkõige just selletõttu, et sidumine olemasoleva
funktsionaalsusega on üsnagi valutu.
Kui vaadata konkreetsemalt koodihalduse vajadusi, siis on peapõhjus uue otsimiseks CVS-i
funktsionaalsuse piiratus AutomatWebi arendamise tarvis. CVS töötab küll ideaalselt, kuid kuna on
tekkinud palju kliente, kelle rakenduses on kasutatud nendele spetsiifilist koodi, siis puudub hetkel
CVS-i vahenditega võimalus seda hallata. Umbes kaks aastat tagasi üritati arendust viia eri okste
peale, et üks oleks arendusversioon ja teine kliendiversioon, kuid kuna kahe erineva oksa
kokkusobitamine toimus CVS-i puhul käsitsi, ei tundunud iga nädal 50 erineva faili kokku
panemine ja konfliktide puhastamine absoluutselt hea mõttena. Pidades tulevikku silmas, on tähtis,
et peale kliendispetsiifika haldamise saaks arenduse ja kliendiversioonid erinevatesse harudesse
lahku aetud ning iga suurema arenduse või ümberkorralduse jaoks saaks teha erineva haru, mille
hiljem arenduskoodi ja sealt kliendi koodi ühendab. Üks põhilise probleeme praeguse ühe oksa
lähenemises ongi asjaolu, et puudub ülevaade, kas antud funktsionaalsus töötab või mitte, enne kui
see on lisatud koodibaasi ning kuskil testitud ning kui samal ajal on tekkinud vajadus kliendikoodi
uuendada, siis on õnnetud tagajärjed kerged tulema. Selletõttu peaks uus lahendus pakkuma peale
töökindluse ja lihtsuse ka korralikku funktsionaalsust.
Koodi dokumentatsiooni eesmärk on üle saada vaakumist praeguse puuduliku dokumentatsiooni
pakutu ning uute AW õppijate vajaduste vahel. Praegune dokumentatsioon on küll mingis osas
eksisteeriv, kuid vägagi hajutatud, olles eri aegadel eri meetoditel koostatud ning kohati vägagi
aegunud. Tulev lahendus kas seoks kogu olemasoleva ühtsesse süsteemi või siis laiendaks seda.
Koodi automaatse dokumenteerimise keskkond on küll AW DocGeni näol olemas, kuid hetkel veel
keeruline kasutada ning vähefunktsionaalne ning dokumenteerimisformaat puudulik, kuid selle
teema aktuaalsus sunnib kiiresti leidma optimaalse lahenduse nii funktsionaalsuse kui ka formaadi
13
osas. Pikemas perspektiivis on vaja pakkuda mingisugust tuge ka arendajatele, kes kasutavad AW-d
nii oma süsteemiga liidestamiseks kui ka litsentseerivad platvormi arendamiseks.
Veahaldus on seni olnud üks AW murelapsi, millest on üle saadud vaid tohutu koguse sündmuste
abil. Kuna AW on laialdaselt kasutatav süsteem, siis avastavad kasutajad mitmeidki vigu, mida
kliendikoodis õnneks väga ohtralt ei esine eelkõige lahenduste lihtsuse tõttu, kuid ärirakenduste
suuna keerukuse ja mahukuse tõttu hakkab üha enam esile kerkima. Praegune lahendus AW
BugTracki näol on alles arenemas staadiumisse, kus oleks võimalik vigu selle kaudu hallata. Selle
valmimisega seotud tegevustest on kindlasti üsnagi prioriteetne eraldi testija ametikoha loomine,
sest praeguste mahtude juures on üsnagi utoopiline ilma konkreetse tegevuseta tagada AW
veakindlus. Kuna testija töö nõuab pidevat tegelemist ka veahaldusega, saab tänu sellele veel
paremini spetsifitseerida ja arendada lõpuni vajadused nii vea- kui arendustegevusehalduses
üldisemalt.
Paketihaldus kui vajalik vahend arendustegevuse parandamiseks on olnud jututeemaks praeguseks
juba üle kahe aasta, kuid senimaani ei ole esialgsetest ideedest kaugemale jõutud. Ühest küljest on
see vägagi laialivalguv teema, nõudes enne arendamist ka konkreetsemat spetsifitseerimist just
tööprotsessi osas, samas on see tekitanud ka teatava „nokk-kinni-saba-lahti“ efekti, kus
paketihalduse arendamiseks vajalikud tegevused seisvad nii mingis osas nii otseselt kui kaudselt
paketihalduse puudumise taga. Konkreetse lähenemise kohta on raske ühtset seisukohta võtta, kuid
see peaks kindlasti võimaldama AW enda kaudu haldamist ning vajadusel ka mingi muu süsteemi
paketina väljastamist (nagu Windows Installer, rpm või dpkg).
14
4 PaketihaldusPaketihaldussüsteem on olemuselt kollektsioon tööriistu, mis automatiseerivad tarkvarapakettide
arvutile paigaldamise, uuendamise, konfigureerimise ja eemaldamise. Seda lähenemist kasutatakse
kõige sagedamine Unixilaadsete süsteemide puhul, eriti Linuxil, mis on väga tugevalt sellega seotud
ning kus tüüpiline esmapaigaldamine koosneb tuhandetest väikestest pakettidest. Tarkvaraarenduse
kontekstis on paketihalduse mõte hallata tarkvara elutsükli osasid valmimisest kuni hoolduseni (Pilt
5).
Pilt 5. Paketihalduse roll tarkvaraarenduse elutsüklis.
Tüüpiliselt on tarkvara sellistest süsteemides eraldi ühest failist koosnevate pakettide kujul, mis
sisaldavad tihti ka muud vajalikku informatsiooni, nagu täisnime, versiooni, arendajat,
kontrollsummat ja seotud pakettide kohta, mida vaja programmi käivitamiseks.
Paketihalduse ülesanne on hallata kõiki pakette, mis on süsteemi paigaldatud ning säilitada nende
kasutatavus, erinevad paketihaldused kasutavad erinevaid kombinatsioone järgnevatest selle
saavutamiseks:
● Verifitseeritakse faili kontrollsumma, et vältida erinevusi allalaaditud ja ametliku paketi
vahel;
● Lihtne paigaldamine, uuendamine ja eemaldamine;
15
● Sõltuvuste jälgimine, et tagada töötav tarkvara;
● Uuenduste kontroll, et saada alati kõige värskem versioon tarkvarast, sealhulgas
veaparandusi ja turvapaike;
● Pakettide grupeerimine funktsionaalsuse järgi, et vähendada kasutajate segadust
paigaldamisel ja haldamisel.
Tänapäeval on kasutusel palju erinevaid paketihaldussüsteem, millest tuntuimad on:
● dpkg, algupäraselt kasutatud Debian GNU/Linux-il ja praeguseks ka sellest põlvnevatele
distributsioonidel, kasutab .deb failiformaati ja oli esimene, kes võttis laiaulatuslikult
kasutusele sõltuvuste haldamise töövahendi, APT-i.
● FreeBSD Ports Collection, vahel tuntud ka kui ports, kasutab Makefile-isid tarkvara
paigaldamiseks binaaridest või lähtekoodist.
● Fink, kasutatakse Mac OS X-is, pärit osaliselt dpkg/apt-ist ja ports-ist. OS X kasutab samas
ka süsteemi nimega Installer.
● RPM Package Manager, loodud Red Hat-i poolt ja kasutatakse praegu mitmetes Linuxi
distributsioonides. Linux Standard Base on üritanud RPM-ist teha Linuximaailma
standardit, kuid Debiani toetajate vastuseisu ja liiga väikese kõlapinna tõttu ei ole see teoks
saanud. RPM-ile on ka palju lisatööriistu, nagu apt4rpm, Red Hati up2date, Mandriva
urpmi, SuSE YaST ja Fedora Core-i YUM.
● Windows Installer, kasutatakse suurema osa Windows-i tarkvara paigaldamiseks.
● Autopackage, loodud RPM-i ja dpkg täiendamiseks, lihtsustades pakettide haldamist
erinevate distributsioonide vahel.
Kuna kõik vaadeldavad paketihaldused on loodud konkreetse vajaduse rahuldamiseks (antud
tarkvaraversioonide paigaldamiseks antud süsteemi) ning on olemuselt keerukad ning mahukad,
hindame siinkohal neid pigem ideelisest küljest, pidades silmas, mis plusse ühel ja teisel on ning
vastavalt sellele koostada optimaalne lahendus konkreetseks otstarbeks. Kuna AutomatWebi puhul
on ilmselgelt paketihaldusega seotud koodihaldus (AutomatWebi kasutatakse otse lähtekoodi kujul),
üritame hindamisel vaadelda ka nende kahe koostoimimise võimalusi.
4.1 RPMRPM Package Manager (või RPM, algupärase nimetusega Red Hat Package Manager) on kõige
laiaulatuslikumalt kasutusel olev paketihaldussüsteem Linuxile. RPM haldab kogu pakettide
16
paigaldamist, eemaldamist, uuendamist, verifitseerimist ja päringuid. Algupäraselt arendatud Red
Hat Linuxi jaoks, on RPM nüüdseks kasutusel ka paljudes muudes Linuxi distributsioonides. RPM
on porditud ka teistele operatsioonisüsteemidele, nagu Novell NetWare ja IMB AIX.
RPM paketihalduse baassüsteemiks on RPM andmebaas, mis koosneb kõikide paigaldatud
pakettide informatsiooni sisaldavast topeltviidetega nimekirjast. Andmebaas peab arvet kõikide
failide üle, mis on paigaldatud või lisatud, tehes nende eemaldamise seeläbi lihtsaks. Kui
andmebaas katkeb (mida juhtub tihti, kui RPM-i klient vägisi peatada), siis topeltviited hoolitsevad
selle eest, et andmebaas oleks võimalik uuesti üles ehitada.
Igal RPM paketil on oma silt, mis sisaldab järgnevat infot:
● tarkvara nimi
● tarkvara versioon
● paketi versioon (mitmes pakett antud tarkvarast tehtud on), tihti kasutatakse seda välja ka
märkimaks, millise distributsiooni jaoks antud pakett mõeldud on, näiteks “fc4” Fedora
Core 4 jaoks, “rhl9” Red Hat Linux 9 ja “suse93” SuSE Linux 9.3 jne.
● Arvuti arhitektuur, mille jaoks see pakett sai tehtud (näiteks i386, i686, athlon, ppc jne)
ja RPM failil on tavaliselt järgnev formaat:
--..rpm
Näiteks:
nano-0.98-2.i386.rpm
Samas, paketi nimi ei pruugi ühtida sildil kirjeldatuga, kuna viimast hoitakse paketi sees eraldi.
Paketi võidakse abil jagada ka lähtekoodi, asendades arhitektuuri kirjelduse “src” märgendiga.
Näiteks:
libgnomeuimm2.0-2.0.0-3.src.rpm
Samamoodi levitatakse teeke pakettides kahe eraldi versioonina, üks eelkompileeritud koodiga ja
teine arendussfailidega, viimastel tavaliselt märgend “-devel” lisatud nime väljale. Kasutajad
peavad sellisel juhul väga tähelepanelikult jälgima, et arendusfailid vastavad kompileeritud
paketiga, vastasel juhul ei pruugi teek väga hästi töötada.
17
RPM võimaldab jagada ka arhitektuurist sõltumatuid pakette, nagu graafikat ja teksti teiste
programmide jaoks, märkides seda “noarch”-iga arhitektuurisildiga.
RPM-i nagu dpkg-d, ei kasutata tavaliselt iseseisvalt, vaid läbi automaatse sõltuvushalduste
programmi, nagu YUM või APT. YUM (Yellow Dog Updater Modified) loodi algselt Red Hati
pakettide haldamiseks Duke-i ülikoolis, kuid üsna pea võeti kasutusele ka mitmetes teistes Linuxi
distributsioonides, nagu Fedora Core, CentOS jpt. YUM-ile on tehtud ka mitmeid graafilisi
liideseid, nagu Kyum.
RPM pakettide plussid on ühtne programmide paigaldamise viis, populaarsus, automaatne
paigaldus, paketide verifikatsioon; samas miinuste kohapealt on RPM paketid tagasiühildamatud
pakettide formaatide muutumise korral, ebatäiuslik ja aegunud dokumentatsioon, vastuolulised
sõltuvusseosed sõltuvalt Linuxi distributsioonist jpm.
RPM-ile on ette heidetud järjepidevuse puudumist pakettide nimetamisel, tehes seeläbi automaatse
sõltuvusseoste haldamise raskeks, mis ei ole otseselt RPM formaadi, kui just erinevate RPM-i
kasutatavate distributsioonide haldajate koostöö puudulikkusest tulenev probleem. Kui kasutada
Fedora Core jaoks ainult Fedora Core-i pakette, siis suudavad automaatsed sõltuvustehaldused,
nagu apt ja yum, konfliktide lahendamisega hakkama saada, sama toimib ka teiste distributsioonide
puhul.
RPM paketi saab luua tehes spetsiaalse “.spec” lõpuga faili, kus on kirjas paketi nimi, versioon, y
RPM-i versioon, loomise ja eemaldamiseks vajalikud sammud ja changelog. Samast .spec failist
saab vajadusele luua ka mitmeid pakette, pakettide loomine toimub spetsiaalse rpmbuild tööriista
abil.
RPM-i käsitledes ei saa mööda minna sellisest mõistest nagu dependency hell või siis teisiti ka
RPM hell. Depenency hell on olukord, kus üks pakett tahab paigaldamiseks saada mingi teise paketi
olemasolu, kuid teine pakett ei ole kas kättesaadav või liiga uus, mille peale nii RPM ja dpkg
keelduvad soovitud toimingut sooritamast. Neid saab küll sundida seda tegema, kuid tagajärjeks on
tihti veelgi suurem segadus, mis võib viia kergesti süsteemi uuesti paigaldamiseni. Vahel võib ka
juhtuda, et üks pakett sõltub teisest, teine kolmandast ja see omakorda neljandast, mis tähendab
kokkuvõtteks meeletu pakikoguse paigaldamist, et esialgne tööle saada. Selliste olukordade
vältimiseks loodi paketihaldustele automaatsed tööriistad nagu yum ja apt, mis üldjuhul tirivad
pakette ühest veebis olevast baasist ning üritavad lihtsamaid segadusi ise parandada, kuid
keerukamate süsteemide korral jäävad nemadki hätta.
18
Oma kogemuse põhjal RPM-i paketihaldusega Fedora Core-i võin väita, et kuigi tavaseadetes
töötab see küllaltki rahuldavalt, lihtsamad uuendamised saab tehtud väiksema ja vahel ka suurema
vaevaga, ei saa yum ega apt hakkama kogu süsteemi uuendamisega, sest paketibaas muutub
distributsiooni versioonides vägagi palju, ning lõppeb tohutu segadusega, mille kõrvaldamiseks
peab kas meeletu koguse pakette käsitsi eemaldama või süsteemi nullist üles ehitama. RPM-i
paketihalduse puudus tundub olevat ka automaatsete töövahendite rpmi-i baassüsteemi vähene
koostöö, mis väljendub pidevas vajaduses pakette käsitsi paigaldada ning uuendada ja paketibaasi
väiksuses, mille tulemusele olen senimaani vältinud vastava paketihaldusega Linuxi
distributsioonide kasutamist.
Iseenest ei ole dependency hell uus nähtus, vaid eksisteeris juba Unixi hiilgeaegadel, kui tarkvara
paigaldati konfiguratsiooniskriptide abil, kus olid kirjas vajalikud sõltuvused teiste pakettidega.
Selliste segaduste vältimiseks on välja töötatud mitmeid lahendusi, üks nendest on
võrgufailisüsteem, kus kõik failid peale privaatsete on globaalselt unikaalsed. Seni ainus näide selle
kohta on Coda failisüsteem, mis on tasapisi jõudmas kasutusküpsuseni.
4.2 DpkgDpkg on Debiani ametlik paketihaldussüsteem, mis loodi 1993 Ian Jacksoni poolt. Dpkg on
olemuselt sarnane RPM-iga, kuna ta teeb samu operatsioone, kuid on tollest kõvasti vanem, seega
võib öelda pigem, et RPM on dpkg-ga sarnane. Dpkg, nagu RPM-gi, on ise madala taseme tööriist,
teised vahendid nagu APT, haldavad pakettide allalaadimist paketibaasidest ja lahendavad
keerukaid sõltuvusseoseid. Dpkg pakett ise koondab endas põhilise vahendeid pakettide
paigaldamiseks ja haldamiseks, dpkg-dev aga pakettide ehitamiseks.
Tavalise kasutatatakse dpkg pakettide tegemiseks tööriista nimega dpkg-buildpackage, mis tahab
nelja kohutuslikku faili, mille järgi paketi koostada:
● copyright, kus on kirjas litsentsitingimused;
● control, mis sisaldab paketi nime, kirjeldust ja sõltuvusi;
● rules, olles Makefile juhistega paketi koostamiseks;
● changelog, mis kujutab endast loogiliselt järeldades changelog-i.
Pärast paketi ehitamist testitakse seda tüüpiliselt lintian-i nimelise tööriistaga, mis otsib probleeme
ja ebakõlasid paketist.
19
Dpkg paketi nimi pannakse sarnaselt RPM-ile kokku järgnevalt:
_-.deb
ning koosneb peale programmi enda veel järgnevatest failidest:
● Makefile, paketihalduse jaoks jaoks;
● control, sisaldab informatsiooni ja seadeid, nagu sõltuvusi teiste pakettidega;
● skriptid, mingid tegevused peale või enne paigaldamist, mis on vaja ära teha (nt
konfigureerimine peale paigaldamist).
Dpkg puhul hallatakse pakettide paigaldamist tasemete järgi:
● Required – paketid, mis on süsteemi toimimiseks hädavajalikud ning mida dpkg eemaldada
ei luba. On vähetõenäoline, et ainult Required pakettidega süsteem töötab, kuid kindlasti
piisavalt, et paigaldada uusi pakette.
● Important – lisapaketid, ilma milleta on kasutamine raskendatud. Nende hulgas ei ole ühtegi
suuremat süsteemi, kõik on väiksemad lisakomponendid.
● Standard – kõik paketid, mida kasutajal tavaliselt vaja läheb, nagu gcc jms.
● Optional – suurem osa tarkvarapakette, nagu X11 ja Emacs.
● Extra – kõik, mida mingil põhjusel ei sobi Optional alla panna.
Sarnaselt eelnevaga, toimub sõltuvuste haldamine ka läbi erinevate juhtude:
● sõltuvus – pakett A sõltub pakett B-st;
● rangelt soovitamine – paketti peaks kasutama ainult koos paketiga B;
● soovitamine – pakett A soovitab ka pakett B paigaldamist;
● konflikt – pakett A ei sobi kokku paketiga B;
● asendamine – pakett A on loodud asendama paketti B (üks konflikti erijuhte);
● hõlmamine – pakett A sisaldab ka kogu paketi B funktsionaalsust.
Dpkg-d ainuüksi kasutatakse üldiselt vägagi vähe, peaaegu alati toimub kogu pakettide haldamine
läbi tema eesliidese, APT-i. APT (Advanced Packaging Tool) ise ei ole otseselt tööriist, vaid kogu
20
C++ programme, mis tegelevad erinevate paketihalduse osadega, neist kasutatavaim on apt-get.
APT on porditud ka RPM-i ja Mac OS X jaoks (Fink-i osana), kuid põhiliselt kasutatakse seda
siiski Debiani-põhistes süsteemides.
Apt kasutab paketihalduses Debiani paketibaasi, kus on kättesaadavad üle 17,000 erineva paketi.
Baase võib ka läbi konfiguratsioonifaili ise lisada, samuti saab seal ka määrata paketide
allalaadimise eeskirju (nt millisest versioonist kõigepealt paketti otsida, kas stable, testing või
unstable). Baasiks saab ka CD plaate või muid võrgus asuvaid andmehoidlaid kasutada.
Apt-i kasutamine on vägagi lihtne, erinevalt dpkg või RPM süsteemist, kus pead ette andma
olemasoleva faili ja siis see paigaldatakse, saad apt-i abil kõigepealt otsida vajaliku faili ning siis
vastavalt selle paketibaasi nimele paigaldada, igasugune arhitektuuri vms haldus toimub
automaatselt. Samuti suudab apt vajadusel automaatselt ise kogu süsteemi paketid uuendada,
näiteks iga pühapäeva öösel cron-i tööna.
Isiklikult olen ni Debiani süsteemi kui apt-i tõsine süsteem, eelkõige just selletõttu, et peale
erinevate Linuxi distributsioonide proovist, kus pakettide uuendamine oli kõige valusam teema,
kasutasin süsteemi, mille paigaldamine oli kohati problemaatiline, kuid uuendamine ja
tööshoidmine väga lihtne ja mõnus. Tavapäraselt üritavad erinevad Linuxi distributsioonid
kasutajaid meelitada mingite imeliste lisavidinatega, nagu automaatne WIFI tugi või ilus
kasutajaliides, mida Debianil vaikimisi vähemalt aasta tagasi ei olnud. Kuna minu kasutuses oli
sülearvuti, mis ei olnud väga üldlevinud riistvaraga (Bluetooth, kolmanda osapoole WIFI jms),
tundus esialgu mugava süsteemi paigaldamine väga utoopiline, kasvõi selletõttu, et Debian ei
suutnud isegi Pentium M protsessorit ära tunda ning arvuti kippus üle kuumenema, sai Interneti
kaasabil lõpuks nii sobilik Linuxi kernel kui ka vajalik WIFI draiver dpkg-buildpackage abil kokku
lastud ning paigaldatud, mis veelkord tõestas dpkg võimsust ja lihtsust minu jaoks, nimetamata
kahekäsulisi süsteemiuuendamisi.
4.3 FreeBSD Ports CollectionFreeBSD Ports Collection pakub lihtsat ja mugavat viisi paigaldada tarkvara FreeBSD-le, kasutades
Makefile-e, tehes paigaldamise ja eemaldamise võimalikuks make käsuga. Kui aplikatsiooni
paigaldatakse, ei pea kasutaja tavaliselt rohkem tegema, kui algkäskluse andma, ning programm
laetakse automaatselt Internetist alla, konfigureeritakse, kompileeritakse, paigaldatakse ja
registreeritakse pakettide andmebaasi ning võimaluse korral paigaldatakse ka sõltuvuse tõttu
vajatavad paketid ning uuendused.
21
Igat paketti haldab vabatahtlik paketihaldur, kelle ülesandeks on olla kursis kõigi selle paketi
arenduses toimuvaga ning hoiab seda ka kasutamiskõlblikuna. Igaüks võib saada paketihalduriks,
võttes siis kas mõne haldurita paketi oma hallata või pannes üldisse baasi mõne oma loomingu.
Kuna Ports Collectionisse lisatakse uusi pakette pidevalt, ei ole kasutajatel tihti tarvis kuskilt
väljastpoolt vajalikke programme otsima asudagi, sest 2006 märtsi seisuga on Ports'i paketibaasis
üle 14,100 paketi.
FreeBSD puhul eristatakse eelkompileeritud pakette lähtekoodiga pakettidest, mida on samuti
võimalik vabalt üldisest baasist alla laadida. FreeBSD-l on ka spetsiaalne “kompileerimisfarm”, mis
tegeleb pidevalt pakettide kompileerimisega erinevatele platvormidele ning pakub pidevalt
tagasisidet paketihalduritele vigade ning logide kohta, et viimane omaks head ülevaadet
platvormide sobivusest ning tarkvara puudustest ja saaks kompileerimisvead võimalikult kiiresti
kõrvaldada.
Nagu RPM-i ja dpkg puhul, jagatakse kompileeritud paketid erinevatesse kaustadesse. “-release”
kaustas on paketid, mis kompileeriti konkreetse FreeBSD versiooniga koos ning neid ei uuendata
peale seda enam, “-stable” ja “-current” kaustades on kõige värskemad versioonid, mida
uuendatakse keskeltläbi kord nädalas. Peaaegu alati saab vanema FreeBSD versiooni jaoks
kompileeritud paketti paigaldada ka uuemale versioonile, sest koguaeg pannakse rõhku ka
tagasiühilduvusele. IA32 binaarse ühilduvuse kiht lubab paljusid i386 pakette kasutada ka amd64
arhitektuuril.
Isiklik kokkupuude antud süsteemiga on puudunud, kuid tean, et paljud serveriadministraatorid
eelistavad FreeBSD-d peale töökindluse ka RPM hell-i puudumise tõttu, kus sa saad vajaliku
konfiguratsiooniga süsteemi ise kokku panna, sõltumata meeletust kogusest lisapakettidest.
4.4 AutopackageAutopackage on võrdlemisi uus ja arenev paketihaldussüsteem Linuxile, mõeldud kasutamiseks
ükskõik millise distributsiooni all, mis eristabki teda teistest paketihaldustest. Erinevalt RPM ja Deb
paketiformaatidest, kontrollib Autopackage pakettide sõltuvusseoseid tegelikul süsteemil, mitte
paketiinfo andmebaasil. Kuigi see lähenemine vähendab probleeme, mis tulenevad pakettide
erinevast nimesüsteemidest, teeb see Autopackage-i tegelikult aeglasemaks distributsiooni oma
paketihaldusest. Autopackage-i paketid on tegelikuses bash-i skriptid, mida saab paigaldada lihtsalt
neid käima lastes.
Autopackage sai loodud eelkõige eesmärgiga teha pakettide paigaldamine Linuxis kõige lihtsamaks
üldse, üritades olla kasutuselt sarnane nii Mac OS X-i “programmikaustadega” kui ka Windows
Installeri lihtsa liidesega.
22
Autopackage on mõeldud aplikatsioonide paigaldamiseks, nagu tekstiredaktoris, veebibrauserid ja
mängud, mitte baassüsteemi osade, nagu shell-id ja teegid, mille jaoks soovitatakse siiski
distributsiooni enda paketihaldust. Aplikatsioonide paigaldamine on omamoodi kahe otsaga
probleem, ühest küljest teeb Autopackage nende paigaldamise erinevatele süsteemidele võimalikult
lihtsaks, teisalt võivad tekkida sõltuvusprobleemid, kui distributsiooni enda paketihaldus tahab
kasutada teeke, mis on paigaldatud Autopackage-i poolt.
Autopackage kasutab platvormisõltumatuse saavutamiseks APbuildi, et eemaldada
mittevajaminevaid sõltuvusi, “ristkompileerimist”, et panna C++ programmid tööle erinevate g++
versioonidega ning parandab GLIBC versiooni sümboleid. Programmid, mis kasutavad
Autopackage-it peavad olema samuti lihtsasti ümberpaigutatavad, mis tähendab, et neid saab
paigaldada ükskõik kuhu failisüsteemis, ilma vajaduseta uuesti kompileerida. See teeb ka
võimalikuks paigaldada Autopackage-i ilma administraatori õigusteta kasvõi oma kodukausta.
Tasapisi on Autopackage hakanud populaarsust koguma, näiteks Gaim ja Inkscape on selle juba
kasutusele võtnud, samamoodi pakub Freshmeat.net infolisajatele võimalust sisestada ka
Autopackage-i paketi URL.
23
5 VeahaldusVeahaldus on süsteem, mis on spetsiaalselt kujundatud tarkvaraprobleemide haldamiseks.
Tüüpiliselt kasutab veahaldussüsteem n-ö “ticket tracking” meetodit, kus iga veateade2
salvestatakse süsteemi, määratakse prioriteet ja aeg spetsiaalse “pileti” kujul ning sellega
tegeletakse, kuni see on lõplikult suletud. Seeläbi hoolitsetakse, et viga saaks alati parandatud ning
kasutaja saaks vajadusel ka mingi tagasiside selle kohta. Tavaliselt lubab veahaldus kasutajatel
kiiresti sisestada veateateid ja neid otsida, mõned lubavad lausa määrata spetsiaalse workflow, mis
automatiseerib vea elutsükli. Veahaldus on vaadeldavatest vahenditest ainus, mis on seotud kogu
tarkvaarenduse elutsükliga ning mida käsitletakse selletõttu tihti laiendatud kujul (Pilt 6).
Pilt 6. Graafikult ilmneb selgelt veahalduse osatähtsus kogu tarkvaraarenduse jooksul.
Kuna projektide olemuse tõttu on veahalduse vajadused erinevad, lubavad süsteemid määrata, mida
vea kirjeldusse lisada võib. Julgelt võib väita, et veahaldus on infosüsteemi seisukohalt vägagi
kriitilise tähtsusega, sest ilma korraliku veahalduselt on oht, et veateated “kaovad” infomürasse ning
jäävad tähelepanuta või mingiks hetkeks koguneb neid nii palju, et puudub igasugune ülevaade
parandatutest ja allesolevatest.2 (märgiks siinkohal ära, et antud käsitluses on “veateade” seoses eestikeelse homonüümsusega inglisekeelses
tähenduses bug report, mitte error)
24
Iga veateade tähendab tihti tunde ja võibolla isegi päevi lisatööd, selletõttu on see väga tähtis, et
neid ka korralikult hallataks ja kaitstaks. Selletõttu peaks eahaldussüsteemiga töötades silmas
pidama mõningaid olulisi punkte:
1. Tööta alati tarkvara kõige viimase versiooniga – see võimaldab testijatel olla kindlad, et ei
teatata vigadest, mis on juba parandatud ja samas võimaldab see ka uued vead kiiremini ära
parandada, sest arendajatel on paremini meeles see, millega alles hiljaaegu tegeleti.
2. Kasuta tarkvara versioonide numereerimist – alati kui võimalik, tasuks kirja panna, mis
versioonis antud viga esines, mis versioonis see parandati ja mis versioonis tuvastati
parandus, sest tihti ei piisa ainult lähtekoodi numeratsioonist, kuna testimine ei oma sellest
alati ülevaadet.
3. Pane paika veateadete elutsükkel – see võimaldab olla kindlad, et vead ei suletud enne, kui
tegelikult oleks pidanud sulgema, näiteks võib see tähendada, et veateate lisaja saab ainult
seda sulgeda või on mingi muu tõhusam süsteem kasutusel. Veateate elutsükkel võiks alati
koosneda järgnevatest osadest: Uus, Määratud, Lahendatud, Testitud, Suletud.
4. Kasuta vea staatust – et hoida veateate elutsükkel võimalikult lihtsalt mõistetavana, kasuta
välja, kus on märgitud vea staatus. Võimalik väärtused võiksid olla: Parandatud,
Parandamatu, Kordamatu, Kordus, Disainist ja Väline.
5. Ära kasuta koosolekuid veateadete üle arutlemiseks – see võib kulutada palju töötunde,
mida võiks kasutada veateadete parandamiseks. Kui selline koosolek on plaanis, siis ei
tasuks vaielda veateadete sulgemise üle, sest see on testijate kvaliteedikontrollist
möödaminemist, vaid kasuta aega veateade reprioritiseerimiseks, parandamise
edasilükkamiseks või parandamatuks kuulutamiseks.
6. Halda feature request-e eraldi – tüüpiliselt juhtub seda tihti, kuid neid peaks hallatama eraldi
ja arutama nendele üle, sest muidu võivad need veateadetega segunedes ajada sassi tarkvara
kvaliteedi mõõdetavuse.
7. Kirjelda, kuidas viga uuesti tekitada – mida lihtsamini on viga uuesti tekitatav, seda
kiiremini saab arendaja seda parandama asuda.
8. Pea arvet selle üle, kuidas vigu avastatakse – arvepidamine aitab sul kõige paremini
planeerida, kuidas raha testimise peale kulutada. Põhilised testimisviisid on: interaktiivne
testimine, testiskripti kasutamine, unit testing, koodi ülevaatus, beetatestimine ja kasutajate
teated.
9. Hoia vigade teatamine võimalikult lihtne – ei ole mõtet teha veateatesse koguda rohkem
infot, kui tegelikult vaja on. Kui vigade teatamine on liiga keeruline, siis hakkavad kasutajad
25
neid saatma pigem e-kirjaga või suusõnaliselt, mis halvab tõsiselt veahaldussüsteemi
otstarbekuse.
Iseenest ei ole need 9 punkti tingimata nõutavad veahalduse juures, kuid teevad selle kindlasti
tükkmaad efektiivsemaks. Kui rääkida aga veateadetest, siis on korralikul veateatel alati need 3
omadust:
– sammud, kuidas see saada
– see, mida sa pidid nägema, ja
– see, mida sa tegelikult nägid.
Ilma nendeta on vägagi raske viga tuvastada, veel vähem parandada.
Kõige tüüpilisemad veahaldussüsteemid on Bugzilla, Flyspray, Mantis, Trac ja JIRA, kaks viimast
neid hõlmavad ka ka arendusprojekti juhtimist ja muid tegevusi.
Siinkohal on tähtis ära märkida ka fakt, et veahaldussüsteeme vaadeldes on raske esialgu hinnata
täpseid nõudmisi, kuna protsessi kirjeldus ei ole veel piisavalt täpselt välja töötatud. Kuid kuna läbi
veahaldussüsteemi hakkab esialgse kava kohaselt toimuma kogu AutomatWebi arendamine, peab
süsteem eeldatavalt võimaldama peale tavapärase vigade haldamise ka kontrollida tervet
arendusprojekti või siis vähemalt mingit osa sellest.
5.1 BugzillaBugzilla on üldotstarbeline veahaldustööriist, mis algupäraselt arendatud ja kasutatud Mozilla
Foundationi poolt. Kuna Bugzilla on veebipõhine ning avatud lähtekoodiga tasuta tarkvara,
kasutatakse seda ka mitmete avatud lähtekoodiga ning äriliste projekti juures, millest kuulsaimad on
KDE, Linux kernel, GNOME, Apache, OpenOffice. Bugzilla vajab töötamiseks Apache
veebiserverit, kas MySQL või PostgreSQL andmebaasi ja Perli. Tavaliselt võib veateateid sisestada
igaüks ning määrata neid kindlale arendajale. Kuna Bugzilla vea märge on väga üldine, kasutab
Mozilla seda ka näiteks feature request-ide haldamiseks.
Bugzillal on päris palju võimalusi, suuresti tänu sellele, et seda koguaeg aktiivselt arendatakse, ning
siinkohal tutvustaks mõnda nendest:
Üks vägagi omapärane võimalus on raportite genereerimine: võimalus vigade andmebaasis
hetkeseisust genereerida kas graafik või tabeli kujul esitlus. Oma olemuselt see väga palju otsingust
ei erine, lisandunud on veel valikud esitluse meetodi kohta, näiteks graafiku genereerimisel saad
määrata ära nii X, Y kui Z telgede omadused. Otsingu puhul saad valida nii lihtsa kui keerulise
26
otsing vahel, viimasel on terve lehekülg erinevaid omadusi ja valikuid, mille järgi leida.
Bugzillal on olemas ka request-ide süsteem, et saad määrata ära teatavad lipud teisele arendajale
ning siis tema siis peab nendele vastama, kas “lubatud” või “tagasi lükatud”. Selle tähtsus seisab
asjaolus, et see võimaldab märkida arenduse elutsükleid, näiteks uue versiooni väljastamist, kus
keegi peab kinnitama, et see on piisavalt küps.
Samamoodi on seal olemas ka võimalus määrata ära n-ö “insider” kasutajad, kes saavad teistele
omasugustele kommentaare jätta, mida teised kasutajad ei näe.
Üks vägagi hea omadus on vigade parandamiseks kulunud aja jälgimine: kogu vea elutsükli ajal
saab iga arendaja märkida, palju aega ta selle tegemiseks planeeris ja palju tegelikult kulus ning siis
hiljem statistika selle kohta vaadata, mille põhjal saab hilisemaid planeerimisi täpsemalt teha.
Vägagi omapärane asi on ka Sanity Check nimeline vahend, mis otsib pidevalt taustal andmebaasist
kokkusobimatusi, mille ta siis eraldi koos sellega seotud vigadega välja toob. Samuti otsib ta ka
meilide hulgast mingil põhjusel saatmata meile.
5.2 Mantis BugTrackerMantis on nagu Bugzillagi avatud lähtekoodiga veebipõhine veahaldussüsteem, mis erinevalt
Bugzillast töötab PHP ja MySQL-iga. Mantis sai alguse ühest videomängu projektist, mille jaoks oli
vaja veahaldust, kuid kõik sellel hetkel saadaolevad ei rahuldanud vajadusi ning selletõttu sai see
kirjutatud ning hiljem ümber kirjutatud ning avalikustatud. Mantis ei ole nii laialt kasutusel kui
Bugzilla, kuid kõige tuntumad kasutajad hetkel on Saab, phpBB ja WordPress.
Väga omapärane on Mantises otsingute tegemine: selleks, et otsida, pead sa koostama spetsiaalse
otsingufiltri, mis näitab vastavate filtrite järjekorra järgi tulemusi. Vägagi detailne on samas
graafikute ja statistika vaade, mis annab vägagi hea ülevaate tegevusest. Iseenest vägagi tore
vahend, kuid tundub, et kohati jääb Bugzillale omasest funktsionaalsusest ja kasutusmugavusest
puudu.
5.3 FlysprayFlyspray on samamoodi avatud lähtekoodiga veebipõhine veahaldussüsteem. See loodi Psi projekti
jaoks, sest ükski olemasolev ei vastanud nende vajadustele. Omades samu baasfunktsioone nagu
Bugzilla, erineb see paljuski all olevas koodis: Flyspray kasutab PHP-d ja võib ADOdb abil
kasutada paljusid erinevaid andmebaase ning omab Jabber-i tuge kasutajate teavitamisel. Kuigi
Flyspray-l ei ole veel nii keerukaid omadusi nagu Bugzillal, on tema üks tugevusi lihtne
paigaldamine ja kasutamine. Üks puudus (kui seda üldse puuduseks lugeda) on infomaterjali
puudumine (ei ole selgitatud funktsioone ja võimalusi) ja dokumentatsiooni vähesus, kuid samas
27
see tundub olevat üks kõikide veahalduste omadusi.
Flyspray kasutamine on tõesti lihtne, seal ei ole mingeid keerulisi menüüsid ja valikuid, välimus on
lihtne HTML koos JavaScriptiga, mis peidab lisavalikud ning toob need vajadusel nähtavale.
Esimese asjana antakse kohe ette tabel lahtiste bugidega, mida saab siis vastavalt sorteerida või
otsida nende hulgast. Lihtsus ongi üks peapõhjusi, miks arendajad selle üle nii uhked on. Kahjuks ei
õnnestunud mul katsetada töötavat näiteversiooni, selletõttu pidin funktsionaalsuse uurimiseks
kasutama limiteeritud näidist.
5.4 JIRAJIRA erineb teistest veahaldustest eelkõige selletõttu, et ta koondab endas peale tavapärase
veahalduse ka projektihalduse, keskendudes eelkõige meeskonnatöö tähtsusele. JIRA on ka
vaadeldavatest ainus, mis on kommertstoode (standardlitsentsi hind algab 1,200 dollarist) ja
ehitatud J2EE platvormile. JIRA-l on ka mitmeid kolmandate osapoolte tehtud lisasid, näiteks
integratsioon Eclipse-iga. JIRA üks tugevusi seisnebki selles, et ta suudab peale vigade hallata kogu
arendusprotsessi üldiselt. Mõned näited funktsionaalsusest:
• Ettevõtte äriprotsesside workflow ülekandmise võimalus;
• Võimalus jälgida muutusi, lisandeid jms;
• Üleüldine täistekstiotsing koos võimalusega otsing salvestada;
• Võimalus siduda väliste süsteemidega (nt e-post, RSS, Excel, XML, koodihaldus jpt)
• Web-Services tugi üle SOAP-i, XML-RPC ja REST-i;
• Lihtsasti mugandatav töölaud, saad välja tuua kõik, mis sinule vajalik.
JIRA-t pakub ka väga laiaulatuslikku õiguste süsteemi, mis laseb määrata erinevad
kasutajatasandiõigused ja vaated: juhtidel projekti staatust uuendada, arendajatel tegevusi hallata,
analüütikutel äriprojektidel silma peal hoida, kasutajatoel probleemide kulgu jälgida, testijatel
kiiresti probleemid kirja saada ilma, et topelt asju tehtaks, projektijuhtidel osade tähtsusi hinnata ja
neid määrata.
Võrreldes teiste vaatluse all olevate süsteemidega, on JIRA nendest kõvasti parema ning
läbimõelduma ülesehitusega, suuresti tänu asjaolule, et tegemist on puhtalt kommertstootega, millel
on vägagi nimekad kasutajad. Samas ei pakuta „everything but the kitchen sink“ stiilis
funktsionaalsusega üle, vaid jäetakse vaba voli kasutada seda, mida sul on vaja ning natuke
enamatki.
JIRA-t kasutavad hetkel üle 2600 organisatsiooni, teiste hulgas Adobe, Hewlett-Packard, Oracle,
28
Samsung, Siemens jpt.
5.5 TracTrac on samamoodi nagu JIRA, teistest funktsionaalsem, sisaldades peale veahalduse ka
projektihaldust ja -jälgimist, kuid erinevalt JIRA-st on Trac avatud lähtekoodiga ning tasuta
saadaval. Trac on inspireeritud CVSTrac-i nimelisest tööriistast ja seda arendab Edgewall Software.
Trac ühendab endas veebipõhiselt veahalduse, versioonihalduse ja Wiki ning täidab ka Subversioni
veebiväljundi ülesannet ehk kokkuvõtteks peaks Trac täitma nii koodihalduse, koodi
dokumentatsiooni ja veahalduse ülesannet. Trac on kirjutatud tervenisti Python-is. Trac on
samamoodi nagu Bugzilla ja JIRA üsnagi laialt kasutusel, üks kuulsamaid on NASA Jet Propulsion
Laboratory, kes kasutavat seda mitmete süva- ja lähikosmose projektide haldamiseks.
Trac-i arendajate lähenemine on, et arendusvahendid peaksid võimalikult vähe segama arendaja
tegutsemisvabandust ja toetama seda võimalikult palju. Selletõttu istub kogu süsteem Wiki ja
vigade andmebaasi core-i peal, st kõik projektidesse puutuv (veateated, feature request-id,
milestone-id, teated, versioonid jne) on omavahel seotud, lastes arendajal keskenduda kõige
tähtsamale: tarkvara arendamisele. Trac peaks eeldatavalt ära katma nii projektijuhi, arendaja, testija
kui analüütikute vajaduses, andes täieliku ülevaate projektis toimuvast. Trac-i arendajad lubavad ka,
et Trac-i saab väga kergesti siduda olemasolevate süsteemidega. Kuna Trac on nagu paljud teisedki
käsitluse all olevad süsteemid suuresti alles arenemisjärgus, puuduvad sealt nii mõnedki
komponendid, mis selle kasutatavust laiendaksid, nagu e-postiga teavitamine, teiste andmebaaside
tugi ja laiendatud otsing.
Trac, nagu JIRA-gi, pürgib laiendama veahalduse kasutusvõimalusi ka teistesse sellega seotud
tegevustesse, nagu projektihaldus ning uurimustöö raames vaadeldavad koodi ning
dokumentatsiooni haldused. Trac-i lähenemine on vaadeldutest kõige lihtsam, tehes vigade lisamise
ja haldamise läbi teiste tegevuse kiireks, kuid vaatamata funktsionaalsusele jätab kuidagi pooliku
mulje, erinevad osad ei tundu esmapilgul piisavalt seotud olevat, et nende põhjal mingigi workflow
saaks tekkida. Süsteemi üldidee ning eesmärk on vägagi innovaatiline ning haldamise kergendav,
kuid näin nagu oleks lihtsalt kokku pandud osad, mis võiks kokku sobida, proovimata neid
tegelikult koos toimima panna. Kohati häirib ka marginaalse, kuid mingis etapis vägagi tähtsa
kasutajatasandite ning e-posti teel teavitamise võimalused.
5.6 AW BugTrackAW BugTrack sai oma alguse 2005 kevadel, kui tekkis vajadus selle järgi seoses AW visuaalse
29
arenduskeskkonna väljatöötamisega. AW-l on veahaldus olnud ka varem, kõige esimene versioon
sisaldas seda, kuid kuna lähenemine polnud piisavalt hästi läbi mõeldud ja struktureeritud
(kasutajad said vigu oma liidesest lisada, kuid haldus nende üle puudus), kogunes neid veateateid
lõpuks tuhandeid, kuni otsustati see kinni panna. Uus veahaldus sai küll esimesed koodiread kirja,
kuid seoses tööde suure mahuga jäi see kuni käesoleva aasta kevadeni seisma, kui antud kirjatüki
autoril oli vaja kuskile süsteemist avastatud vead kirja panna nii, et need ei jää lihtsalt infoks
kuskile. Aktiivne arendamine on toimunud 2006 jaanuarist alates, praegu ollakse vägagi lähedal
selleni, et kasutuse saaks võtta, kuigi plaanitud funktsionaalsusest on olemas vaevalt 1/5.
Üks põhjus, miks ei võetud kasutusele mõnda valmis süsteemi, on see, et omaenda loomine on küll
ajamahukas ja keeruline, kuid vastab kõige paremini vajadustele, on sidus ja lihtne kasutada ning
kasutatav ka muus otstarbes koos teiste vahenditega, kui ainult AutomatWebi arenduses (nt
projektihalduses projektielutsükli täiendamisel). AW BugTracki kuvapildistus on ära toodud Lisas
3.
Oma olemuselt AW BugTrack teistest sarnasest süsteemidest väga palju ei erine, samamoodi saab
vea elutsüklit jälgida, sulgeda, avada, teateid saata jne., kuid erinevused tulevad sisse eelkõige AW
spetsiifikast lähtudes:
1. Esimene neist on kindlasti vigade puu struktuuri kuvamine. Kuna AW “failisüsteem” on
puukujuline, siis oli üks eeldusi ka see, et veateateid saaks kategooriatesse ja
alamkategooriatesse jaotada ning üksteise alla panna, et tekiks ka visuaalne pilt
järgnevustest. Üks küsimusi, mis tekib on ka see, et kui see puu struktuur väga sügavaks
läheb, kuid olen üpriski kindel, et kasutajad ise hoolitsevad selle korrahoidmise eest.
2. Teine oluline lähenemine on AW BugTracki sidumine kirjakastiga, mille ülesanne on täpsem
ülevaade liikuva e-posti osas, mis on seotud veahaldusega ning kõik kasutaja meilihaldus
käiks ühe süsteemi kaudu. Üks spetsiifilisem vajadus on seotud ka AW arendamisega, kuna
AW-l on spetsiaalne vigadelist, kuhu kõik AutomatWebid saadavad tekkivaid vigu ning sealt
oleks võimalikult lihtne veateateid lisada süsteemi.
3. Kolmas lähenemine on veahalduse sidumine projekti ja kliendiga, mis annab esiteks
võimaluse saada ülevaade konkreetse kliendiga seotud vigadest ning samas ka konkreetse
projekti põhistest. Kliendiga sidumine võimaldab hinnata ka temale esitatavaid
hooldusarveid ning projektipõhisus luua lisaväärtust seotuna projektielutsükliga
projektihalduses.
4. Neljas lähenemine on AW BugTracki sidumine kasutaja kalendriga. Senimaani on kogu AW
arendus käinud niimoodi, et tekitatakse arendaja kalendrisse sündmus, kus on kirjas kõik,
30
mis on konkreetse ülesande piires vaja teha. Tihti kasvab see nimekiri vägagi pikaks ja ei ole
vägagi ülevaatlik, kuna peab ka kommentaare tegevuste kohta kirjutama ning ülesannete
pikaajalisuse tõttu kaovad need tegevused kalendrivaatest ära, kuid jäävad tegevuste ribasse
alles. Selletõttu on kõikidel arendajatel hästi palju tegemata toimetusi ja tühi kalendrivaade.
Eesmärk on tekitada kalendrisse spetsiaalne vaade, kust näed veateateid lisaks tavapärasele,
kus on kirjas ainult konkreetsel päeva/nädala/kuu tegevused, mis ei ole otseselt arendusega
seotud.
5. Viies lähenemine on veateadete import. Kuna AW BugTrack peaks lõpuks koondama kogu
AW-ga seotud arendustegevused, ei tule sinna ainult veateated. Tihti pannakse kogu projekti
spetsifikatsioon kirja tavalisse tekstifaili ning sealt ridade kaupa sisestamine on
ebaotstarbekas. Mis toob omakorda sisse vajaduse teha veateate piires ka väiksemaid n-ö
“alamvigu”, mida saaks märkida tehtuks lihtsamalt, kui üldist veateadet ennast, et ei peaks
iga pisi asja jaoks tegema eraldi teadet, vaid hallata neid grupeeritult.
31
6 KoodihaldusInformaatikas ja telekommunikatsioonis ei käsitleta eraldi terminit koodihaldus, vaid
konfiguratsioonihaldus, millel on kaks tähendust:
1. Automaatse infosüsteemi turvaline seadete, tarkvara, riistvara, dokumentatsiooni, testide jms
majandamine kogu arendamis- ja töötamisaja jooksul ehk SCM. Koodihaldus on üks osa
sellest.
2. Keeruliste süsteemide arenemise kontroll ja adaptsioon ehk meetodid, kuidas hoida tarkvara
arenemine kontrolli all, tagades piisav kvaliteedi ja kuluva aja suhted, jagunedes omakorda
kaheks: vanem osa tegeleb tarkvara arendamise käigus tekkinud seadete eest, uuem
hoolitseb nende seadete muutmise ja kasutamise eest.
Meie vaatluse alla jääb esialgu vaid esimene lähenemine ning sellest just täpselt koodihalduse osa,
teist osa sellest hõlmab eeldatavasti paketihaldus (Pilt 7).
Pilt 7. Koodihalduse seotus erinevate elutsükli osadega.
Kuna SCM on oma olemuselt vägagi keerukas ja kõikehõlmav lähenemine (kontrollides nii
projekti, koodi, seadeid, elutsüklit kui kõike selle juurde kuuluvat), ei ole antud töö raames
võimalik seda niivõrd laiaulatuslikult käsitleda, seega piirduma vaid kõige põhilisema ehk koodiga.
Kuigi vahe üldise SCM-i ja koodihalduse vahel on pigem lähenemises, kui funktsionaalsuses, võib
seda skeemi vaadata niipidi: SCM-i osa on versioonihaldus, mis omakorda spetsifitseerides
moodustab koodihalduse.
32
Versioonihaldus on vahend ühe informatsioonikoguse erinevate versioonide haldamiseks. Seda
kasutatakse tavaliselt inseneriteaduses ja tarkvaraarenduses, kus tihti muutuvad dokumendid,
lähtekood vms kiiresti ning on vaja neid muutusi kuidagi hallata. Kõige lihtsam versioonihalduse
viis on hallata neid muutusi käsitsi, hoides alles kõiki tehtud versioone, kuid see on vägagi
ebaefektiivne, sest vajab palju aega, on infomahukas (kõik versioonid peavad alles olema), nõuab
väga tugevat distsipliini arendajatelt ning võib seetõttu väga lihtsalt vigadeni viia. Põhimõtteliselt
on võimalik automaatset versioonihaldust kasutada ükskõik millise informatsiooni haldamiseks,
kuid praktikas on seni seda vaid tarkvaraarenduses kasutatud. Nüüd hakkavad ka CAD failide puhul
üha enam kasutusele tulema automaatne versioonihaldus vana manuaalse asemel.
Tarkvaraarenduses on vägagi tavaline, et korraga on kasutuses mitu tarkvara versiooni ning nendega
tegelevad eri arendajad. Vead ja muud probleemid eksisteerivad tihti ainult ühes versioonis (sest
arenduses asenduvad ühed vead tihti teistega), selletõttu on vaja näiteks debugger-il võrrelda
erinevaid versioone, et tuvastada algallikas. Vahel on arenduses ka tarkvara mitu versiooni ning siis
peab olema kuidagi võimalik parandada vigu niimoodi, et ei tehtaks topelttööd.
Traditsiooniliselt on versioonihaldussüsteemid kasutanud tsentraliseeritud mudelit, kus kõik
kontrollifunktsioonid on ühe koduserveri käes. Mõned aastad tagasi hakkasid süsteemid nagu
TeamWare, BitKeeper ja GNU Arch kasutama jagatud mudelit, kus igal arendajal on oma kohalik
baas ning muutused baasi vahel jagati eraldi sammuna. See lähenemine lubab arendajatel töötada
võrguühenduseta ja annab ka täieliku kontrolli baasi üle, ilma et peaks õigusi tsentraliseeritult
haldama. Üks juhtivaid jagatud versioonihalduse propageerijaid on Linus Torvalds, Linuxi kernel-i
looja.
Enamuses tarkvaraprojektides tegelevad mitmed arendajad ühe ja sama programmiosaga korraga.
Kui kaks arendajat üritavad muuta ühte ja sama faili samal ajal, siis nad võivad väga kergesti
kirjutada üle üksteise tööd. Suurem osa versioonihaldusi lahendavad selle probleemi ühel või teisel
moel. Samas on see probleemiks ainult tsentraliseeritud lähenemise puhul, sest jagatud mudeli
põhiidee ongi lubada mitme arendaja poolt korraga muutmist.
Mõned süsteemid kasutavad probleemi lahendsamiseks failide lukustamist, kus üks pool ei tohi
enne muuta, kui teine on enda muudatused üles pannud. Teised, näiteks CVS, lubavad korraga
muutmist ning annavad võimaluse pärast muudatused ühendada. Selle üks võimalusi on ka
reserveeritud muutmine, kus ei tohi muudatusi üles panna enne, kui teine on üles pannud, isegi kui
mõlemad saavad muuta. Selle üks tagasilööke on asjaolu, et kui muudatuste tsükkel ei ole piisavalt
kiire, siis võib üks kasutaja oma muudatuse lihtsalt süsteemi eirates käsitsi üles panna, mis võib viia
veel suuremate probleemideni. Mõned süsteemid üritavad hallata muutmisõigusi vastavalt sellele, et
mitu arendajat tohib muuta ja oma muudatusi lisada korraga, kuid nende järjekord sõltub õigustest
33
või on hallatav ühe arendaja poolt. Suurem osa versioonihaldustarkvaradest kasutab delta
kompressiooni, mis hoiab alles ja tegeleb ainult kahe versiooni erinevustega, hoides kokku mahtu
nii andmesidelt, kui andmehoiult.
Mitmed arenenumad versioonihaldused pakuvad ka võimalust liidestamiseks, mida on ära
kasutanud mitmed IDE-d, nagu Eclipse, MS Visual Studio, NetBeans IDE ja paljud teised.
Versioonihaldustarkvarasid on päris palju, siinkohal toome ära tuntumad, kuid lähemalt käsitleme
vaid antud seminaritöö piires olulisi:
• GNU Arch, üks omapärasemaid versioonihalduseid, erineb CVS-ist ja tema analoogidest
selle poolest, et kasutab detsentraliseeritud hoidlat;
• CVS, RCS-i järglane;
• RCS, loodi asendama SCCS-i oma efektiivsema lähenemise tõttu;
• Subversion, loodud CVS-i asendama;
• SCCS, algupärane UNIXi SCM tööriist;
• TeamWare, loodud Sun Microsystemsi poolt ning põhiliselt nende enda poolt kasutuses;
• Perforce, kasutusel üle 3,600 organisatsiooni poolt, BitKeeperi suurimaid konkurente;
• BitKeeper, kasutati pikalt Linuxi kernel-i lähtekoodi haldamiseks, kuni arendaja ja Linuxi
meeskonna vahel litsentsileping läbi sai ja Linuxi meeskond endale ise vahendi ehitas,
arendatud sama inimese poolt, kes juhtis TeamWare-i arendamist ning on selletõttu
mitmedki lähenemised sealt pärinud;
• Bazaar-NG, põhineb GNU Arch-il, kuigi praeguseks täiesti from scratch ümber kirjutatud,
senimaani siiski veel varajases arengujärgus.
Kuna AutomatWebi arendamine on algusest peale toimunud CVS-i kaasabil, on selle vajaduste osas
juba mõningane eelteave ja pilt olemas, mis on samas piiratud väheste arendajate arvust tingitud
väiksemate nõudmiste tõttu. Uus ja eeldatav vahend peaks peale praegustele nõudmistele parema
vastamise olema võimeline ka jätkusuutlikuseks arendajate arvu kasvamisel suureks, ilma, et tekiks
vajadus olulisel määral tegevusi omavahelise suhtlemise tasandil muuta. Ühest küljest peale
ilmselgete puuduste on CVS-i nõrk külg ka väheste võrguprotokollide toetamine, mis väljendub
tihti selles, et kasutaja serverisse paigaldatakse AutomatWeb üle FTP. Teisalt, kuna paketihaldus ja
koodihaldus on AutomatWebi kontekstis hetkel vägagi seotud (praeguse seisuga AutomatWebi ei
eelkompileerita), siis võib paketihalduse teke ära katta nii mõnegi koodihalduse praeguse puuduse,
kuid ainult klientidega, mitte üldisemalt arendusega seotud tegevustes.
34
6.1 GNU ArchGNU Arch on versioonihaldusprogramm, mis vaatamata oma analoogiaga CVS-ile ja Subversion-
iga, kasutab nendest erinevalt jagatud meetodid muudatuste haldamiseks, kus iga muudatus on
globaalselt identifitseeritav, tehes süsteemi väga skaleeruvaks ühendamaks ja muutmiseks täiesti
erinevatest allikatest.
GNU Archi detsentraliseeritud lähenemine tähendab, et read-only koopia algsest koodist tehakse
vabalt loetavaks kõikidele kasutajatele, mida siis igaüks saab muuta ja oma muudatused üles
laadida, ning projekti juhtarendaja ühendab muudatused käsitsi, mis omakorda jõuavad taas
algsesse koopiasse. Tsentraliseeritud lähenemise simuleerimiseks saab peaarendaja lasta üle SSH,
FTP või WebDAV-i kasutajad ligi ka peakoodile.
GNU Arch kasutab sarnaselt Subversioniga atomaarsete muudatuste põhimõtet, kus muudatused ei
jõustu enne, kui kogu muudatuste hulk on edukalt valideeritud. Samamoodi on kasutusel ka mitmed
muud Subversioni lähenemisega sarnase võimalused: muudatused on projekti, mitte failipõhised;
oksade tegemine on tehtud lihtsaks ja kiireks; ümbernimetamine toimub baasipõhiselt jpm.
Lisaks on GNU Archil ka vägagi põhjalik muudatuste ühildaja, mis suudab kolmepoolselt
muudatusi kokku panna (algbaas, esimene muutja, teine muutja) ning arvestab sealjuures ka kõikide
muudatuse ajalooga. Samuti tehakse igast muudatuste hulgast krüptoräsi, mida on võimalik ka
signeerida, et ei oleks võimalik lubamatut baasi muutmist.
GNU Arch-i esialge versioon loodi Tom Lordi poolt, millest ka käsurealühend tla (Tom Lord's
Arch). Alguses oli see vaid kogumik shelli skripte, mis olid mõeldud CVS-i asendama, kuid 2003
aastal sai see osaks GNU projektist ning augustis 2005 teates Tom Lord, et lahkub projektist (varsti
peale 2.0 versiooni avaldamist) ning soovitas Canonical Ltd-i Bazaari projekti Archi asendajaks.
Peale Bazaari, on Archist veel mitmeid eri versioone tehtud, nagu Arch ja hiljutine Bazaar-NG.
Paljud suhtuvad vägagi kriitiliselt Arch-i, eelkõige selletõttu, et seda on vägagi raske õppida,
kasutades suurel hulgal käskusid, mis võivad algajat kohutada. Mõningat kriitikat saab see ka
asjaolu tõttu, et kasutab vägagi omapärast failinimede süsteemi (hüüdnimega FunkyFileNames),
mis teeb selle portimise teistele operatsioonisüsteemidele vägagi raskeks. Peale raske kasutamise,
on Arch-i puhul ka teada, et probleeme tekib ka suurte koodipuude haldamisega. Archi pooldajad
samas väidavad, et tarkvara alles areneb ning suuremad probleemid saavad arenduse käigus
kindlasti lahendatud, kuid kuna Archi uus 2.0 versioon (mis muideks on from scratch ümber
kirjutatud, eemaldab failinimede probleemi ning ei kasuta üle 10 põhikäsu) ei paista veel kuskilt
tulemas olevat, eelkõige selle tõttu, et eelmisest arendajast tekkinud seisaku tõttu.
35
6.2 BazaarEsialgne Bazaar sai alguse GNU Arch protokolli implementatsioonina, mis väljastati oktoobris
2004. Canonical Ltd toetas selle arendamist kuni 2005 alguseni kui kogu toetus ja arendus läks üle
uue ja parema disainiga versioonil väljatöötamiseks. Praegusel hetkel on esialgne Bazaar hüljatud.
Veebruaris 2005 teatas Martin Pool, kes oli eelnevalt võrrelnud ja kirjeldanud mitmeid
versioonihaldussüsteeme, et ta töötab Canonical Ltd ülesande peal teha “hajutatud
versioonihaldussüsteem, mida häkkerid armastaks kasutada”. Avalik lehekülg ja meilinglist pandi
üles aadressile http://www.bazaar-ng.org/ ning projektile anti nimeks Bazaar-NG, kus NG tähistab
“uut põlvkonda” (Next Generation), sest Bazaari nimeline projekti oli siis juba olemas. Augustis
2005 teatas Canonical Ltd, et kogu uue põlvkonna versioonihalduse arendus läheb üle Bazaar-NG
toetuseks, mis väljastatakse Bazaar 2.0 nime all 2006 alguses
Praegune Bazaar ei oma esimese Bazaariga ühist koodibaasi, neid ühendab peale nime veel mõned
lähenemised ja algideed: teha Archilaadne versioonihaldustarkvara, kus ei ole vajadust keskse
halduse jaoks ning säilitaks kõik varasemad versioonid ning muutused.
6.3 BitKeeperBitKeeper on versioonihaldustarkvara, mis tänu oma võimalustele, võistleb suurtegijatega nagu
Rational ClearCase ja Perforce. BitKeeper on BitMover Inc-i toode ning mille arendamist juhib
Larry McVoy, sama inimene, kes disainis Sun-i TeamWare-i, selletõttu jagab BitKeeper mitmeid
TeamWare-i lähenemisi. BitKeeperi üks põhilisemaid müügiargumente on võimalus hajutatud
arendusmeeskondadel hoida enda lokaalne baas ja keskne baas sünkroonis võimalikult lihtsalt.
BitKeeper on kinnise lähtekoodiga tarkvara, mida müüakse või liisitakse osana kasutajatoe paketist
korporatsioonidele. Täpne hind sõltub kliendi vajadustest, kuid keskmine kulu ühe arendaja kohta
on keskmiselt üle 1000 dollari, tehes selle kättesaadavaks vaid suurimatele.
BitMover pakkus tasuta kasutamist mitmetele avatud lähtekoodiga ja tasuta tarkvaradele, millest
kõige kuulsam ja samas ka vastuolulisem on Linuxi kerneli lähtekood. “Ühiskondliku” versiooni
leping lubas BitKeeperit kasutada arenduses tasuta vaid juhul, kui kasutajad ei arenda samal ajal
konkureerivaid tooteid (nt CVS, GNU Arch, Subversion vms) BitKeeperi kasutamise ajal pluss üks
aasta. Sama leping nõudis ka, et mingi osa koodimuutuste metainfost säilitataks ka BitMoveri
serverites, mis tegi võimatuks projektide arendamise, millest BitMover ei olnud teadlik.
Otsus 2002 aastal võtta Linuxi kerneli arendamisel kasutusel BitKeeper, tekkis vägagi vastakaid
arvamusi. GNU projekti algataja Richard Stallman väljendas oma muret ärilise tarkvara
kasutamisest vaba tarkvara tegemiseks. Samal ajal kui Linus Torvalds ja teised põhitegijad võtsid
36
http://www.bazaar-ng.org/
BitKeeperi kasutusse, keeldusid mõned häälekalt (nagu Linuxi veteran Alan Cox) ning
kommenteerid BitKeeperi litsentsitingimusi, millest võis välja lugeda, et projekti juhtimise võib üle
võtta mõni ärilise suunitlusega arendaja. Nende probleemide kõrvaldamiseks lisas BitMover
gateway-d, mis lubasid kasutada limiteeritult CVS-i ja Subversionit BitKeeperi serveritega. Isegi
nende täiendustega tekkisid vahel pikad sõnasõjad Linuxi kerneli meilinglistis, milles võttis tihti osa
ka Larry McVoy, kes on ise ka Linuxi arendaja.
Aprillis 2005 teatas BitMover, et lõpetab tasuta BitKeeperi versiooni pakkumise, eelkõige vaidluste
tõttu Linus Torvaldsi tööandja, ODSL-iga (Open Source Development Labs), mille üks töötaja
Andrew Tridgell üritas BitKeeperit “lahti muukida”, et saaks arendada tasuta tarkvara, mis seda
asendaks. Varsti peale seda avaldust teatas Linus git projekti algatamisest, mis pidi asendama
BitKeeperit Linuxi kerneli versioonihalduses. Ametlik tugi lõppes 1. juulil 2005 ja kasutajad pidid
kas ostma tasuta tarkvara või minema üle mingile muule vahendile. Ka hiljem on BitMover vägagi
häälekalt võidelnud igasuguste projektide vastu, mis võivad BitKeeperit ohustada: oktoobris 2005
tegi McVoy ettekirjutuse ühele kliendile, kelle töötaja arendas GPL lähtekoodiga
versioonihaldussüsteemi Mercurial,
Recommended