-
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,