SharePoint lahenduste pakkimine
12.01.2010 | Gunnar
SharePointi lahenduste loomisel aetakse tihti omavahel segi arendamine ja kohendamine. Selle tulemuseks on lahendused, mille paigaldamine uude keskkonda eeldab suhteliselt palju aeganõudvat käsitööd. Inimesed unustavad kiiruga dokumenteerida sammud, mis on kohenduste tegemiseks vajalikud ja pärast kulub veel hulk aega sellele, et sammud õiges järjekorras läbi teha. Probleemi saab vältida lahenduste korrektse pakendamise abil.
Paljud arendajad on võtnud seisukoha, et kohendused SharePointi keskkonnas – eriti need, mis on tehtud SharePoint Designer abil – on saatanast. DT seisukoht on siin ühene: pigem on saatanast inimesed, kes ei suvatse omale tehnilisi vahendeid selgeks teha ja lahmivad pealiskaudsete teadmiste tasemel.
Mis on arendus ja mis on kohendus?
Kohenduseks tuleb lugeda kõik muudatused, mis on tehtud SharePoint enda keskkonna vahendusel või SharePoint Designer abil. Arenduseks loeme SharePointi lahendused, mis paigaldatakse serverisse selleks ettenähtud pakettide abil. Paketid on failid, mis antakse tellijale ja mis paigaldatakse tellija tehnilisse keskkonda. See tähendab seda, et arendustööde käigus tehtud kohendused peavad jõudma ka pakettidesse.
Pakettide koostamine
Pakettide koostamine on suures osas automatiseeritav. Garanteerida tuleb see, et testserveris elavasse lahendusse tehtud kohendused jõuaksid ka Visual Studiosse, mille projektides hoitakse lisaks SharePointi objektide definitsioonidele ka kohendusi ja nendega seonduvat.
Soovitan kellegi arendajatest määrata pakettide halduriks – see arendaja hoolitseb selle eest, et kõik vajalik saaks Visual Studiosse ja et pakendamise tulemusena tekkivad paketid on terviklikud. Lisaks on pakettide halduri ülesandeks paigaldusskriptide loomine ja testimine. Samuti pakettide loomine ja testimine.
Kuigi pisemate lahenduste korral pole paigaldusskripte alati vaja, võib suuremate lahenduste juures see äärmiselt vajalikuks osutuda, sest pakette on mitu ja need tuleb paigaldada õiges järjestuses.
Pakettide halduri ülesandeks on ka Visual Studios pakettide paigaldamisega seotud koodi kirjutamine (näiteks meetodid, mida käivitatakse erinevate objektide loomisel ja aktiveerimisel).
Pakettide valmimise töövoog
Pakettide valmimise töövoog võiks lihtsustatud kujul olla selline. Arendajad teevad oma igapäeva tööd, mille kõrval valmivad pakettide halduri käe all paigalduspaketid. Valmis lahenduse struktuur, projektiline koosseis ja pakettide struktuur loksuvad paika töö käigus. Kohe alguses midagi 100% ette määrata on mõttetu.
Ülaltoodud töövool käib protsess pakettide osas selliselt:
- Arenduse käigus testitakse valmivat lahendust kohalikus testserveris. Sinna võidakse teha ka kohendusi (ja tihti see nii ongi – võib vastu vaielda küll, kuid mina ei põe vaimset tõve nimega idealism ja lähtun sellest, mis elus juhtub).
- Pakettide haldur loob Visual Studio projektidesse kõikide paigaldatavate objektide definitsioonid ning leiab võimalused ka keerukamate kohenduste kajastamiseks kas XML-definitsioonide või siis aktiveerimis- või paigaldamiskoodi tasemel. Võib juhtuda, et kohenduse paketti lisamiseks on vaja mõlemat.
- Pakettide haldur testib paigalduspaketid ära ning viimane pakettide ja skriptide koosseis on alati kättesaadav kõikedele projektis osalevatele tehnikutele.
- Testitud paketid paigaldab administraator tellija testserverisse, kus toimub lahenduse testimine enne tööserverisse minekut.
- Kui paketid toimivad tellija testserveris, siis paigaldatakse need edasi tellija tööserverisse.
Pakettide testimine
Pakettide testimisel tuleb kindlasti testida selliseid asju:
- Pakettide paigaldamine puhtasse keskkonda.
- Paigalduse tulemuste testimine.
- Aktiveerimismeetodite ja muu koodi tasemel lahendatud paigaldusfunktsionaalsuste testimine.
- Uute pakettide paigaldamine viimasele tööversioonile.
- Paigaldamise tulemuste testimine.
Ka neid protseduure annab automatiseerida. Kui automatiseerimine on korra ühes projektis edukalt läbi elatud, siis järgmistes läheb kõik juba libedamalt.
Kokkuvõte
Pakettide loomine on mu senise praktika põhjal oluline asi, mis aitab vältida äärmiselt raskesti hinnatavaid, kuid see-eest väga mahukaid ajakulusid lahenduste tööshoidmisel.
Ilma Visual Studio keskkonda vahepeal maandumata on kohendused tihti äärmiselt salakavalad, sest inimeste teadmatus ja tihtipeale ka laiskus tekitab olukorra, kus osa lahendusest hakkab elama oma elu ja teave kohenduste kohta elab inimeste mälestuses.
Jah, pakettide loomine, selle teema selgeks tegemine ja sünnivalude üleelamine pole ei ajaliselt ega rahaliselt odav lõbu. Kuid kindlasti on see ajateljel mõõdetuna oluliselt odavam kui heade klientide kaotamine.