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,