Drupal 9-le uuendamise väljakutsetest ja võimalustest praktikas
Drupal 7 on kõige laialdasemalt kasutatav Drupali versioon. Praeguse seisuga on aga Drupali kogukond teavitanud, et novembris 2023 saab Drupal 7 eluiga ametliku lõpu, mis tähendab, et lõppevad tasuta turvauuendused ja peatatakse ka Drupal 7 lisamoodulite arendus. Just praegu on õige aeg alustada versiooni uuenduse planeerimist, et vältida ootamatuid eelarveridu ja üllatusi tööde mahu osas.
Meie vanemarendaja Ragnar Punak ja projektijuht Peeter Ossip räägivad, miks ei ole tarkvara uuendusest pääsu ning toovad näiteid ja annavad nõu, millega peab arvestama Drupal 7-lt Drupal 9-le üleminekul.
Miks on oluline uuendada Drupal 7-lt 9-le?
Mõnikord arvatakse, et arendusfirmad suruvad uuenduste näol peale oma lisateenuseid. Tegelikult on tegemist tarkvaraarenduse elutsükli loomuliku osaga.
Kirjutasime hiljuti ka oma tarkvara hoolduse artiklis, et kui sinu veeb või infosüsteem on valmis arendatud, siis sellega ei ole töö veel lõppenud. Tarkvara ei saa piltlikult öeldes riiulile paigutada - regulaarne hooldus (mh uuendused) on eelkõige just turvalisuse seisukohalt kriitilise tähtsusega.
Probleemi näiteid uuendamata tarkvarast: üks meie klientidest soovis kasutada testserverit sama PHP versiooniga - üks rakendus oli tal Drupal 7, teine aga Drupal 9 peal. Teatavasti Drupal 9 - kui kõrgem versioon - nõuab ka uuemat PHP versiooni ja kliendil tekkisid probleemid. Veebipoe puhul aga ei pruugi ühest hetkest enam toimida liidestused andmebaaside ega lisamoodulitega (nt Facebooki moodul, laoseisu- ja raamatupidamisprogrammid jne).
Rääkides rätsepmoodulitest, siis neil puudub Drupali kogukonna tugi ja tuge pakub konkreetne arendaja ise. Vahest võib minna ka nii, et rätsepmoodulist võib saada Drupali ametlik moodul.
Arvata võib, et Drupal 7 lõppu ootavad pikisilmi küberkurjategijad. Ilmekas näide, kui kiiresti ja tõsiseks võib olukord uuendamata lehtede jaoks muutuda, oli 2014 aasta oktoobris avastatud turvarisk hüüdnimega "Drupalgeddon".
“Edasilükkamine on tehnilise võla suurendamine,” tõdeb Peeter Ossip.
Tehnilisest võlast oleme täpsemalt juttu teinud oma varasemas blogiartiklis Metoodilisest tarkvaraarendusest ehk millega peab arvestama, kui väikesest projektist saab suur.
Kui klient loodab Drupal 7 peale jäädes raha kokku hoida, siis paraku nii see ei lähe. Mõnda aega on arendajal tõesti võimalik vana versiooni paikadega lappida. Kui võtta aga arvesse rätseplahendusena tehtavad lisaarendused, on kokkuvõttes mõttekam arvestada selle kuluga oma eelarves ja uuendada õigel ajal kõrgemale versioonile.
Kas on alternatiive, kui kohe ei ole eelarvet?
Nagu öeldud, siis eluea lõpu kuupäeva kukkudes suure tõenäosusega kohe midagi ei juhtu. Oluline on aga endale teadustada, kuidas uuendamata jätmine mõjutab sinu veebi või infosüsteemi pikemas perspektiivis.
Jooksvalt koguneb väiksemaid probleeme, mis tekitavad lumepalli efekti. Kui ühel hetkel on asi kriitiline ja tarvis kiiresti tarkvara päästa, siis võib ajastuse osas olla väga ebasobiv hetk kliendile (näiteks jõulukampaania) või ei pruugi arendustiimil just sel hetkel ressurssi olla. Sellise olukorra vältimiseks soovitamegi aegsasti versiooni uuendust ette planeerida.
On alternatiive, kuid need ei ole kindlasti piisavad ja neile lootma jääda meie omalt poolt ei soovita:
- võimalus, et eluea lõpp lükatakse veel kord edasi;
- kolmandate osapoolte (mitte Drupali kogukonna) poolt pakutavad tasulised turvauuendused;
- tõsta turvalisust serveri poolt asju/funktsionaalsusi kinni keerates või ära peites.
Uuendamine Drupal 7’lt – mis muutub?
Kasutajate (administraatorite) jaoks
Üldiselt näeb Drupal 9 haldusliides välja väga sarnane 7 omale. Tõenäoliselt on kasutajate jaoks kõige suurem muudatus see, et failihalduseks on soovitav nüüdsest kasutada Media Library’t, kus erinevalt varasematest versioonidest, on üleslaetud failid taaskasutatavad.
Neile saab lisada juurde ka välju (täiendavad kirjeldused, metaandmed). Media Library kasutamise õpib ära väga lihtsasti - tavaliselt piisab, kui korra ette näidata.
Kasutaja jaoks võib Drupal 7-lt 9-le uuendamise puhul paralleeli tõmmata Windowsi update’ga, kus peale uuendust on kõik mugavam ja parem, kuid veidi on võibolla vaja harjuda. Enamasti ei ole administraatoritele isegi koolitust vaja. Lõppkasutajate ehk veebi külastajate jaoks ei muutu märkimisväärselt midagi.
Arendajate jaoks on muudatusi rohkem
Suurim muudatus arendajate jaoks on see, et 8ndast versioonist alates baseerub Drupal osaliselt Symphony nimelisel PHP raamistikul. Kui Drupal 7 puhul oli kood pigem protseduraalne, siis kõrgemate versioonide puhul kasutatakse seega valdavalt objekt orienteeritud lähenemist.
Lisaks muutus ka kujundusmallide "mootor" (phptemplate asemel tuli Twig), mis tähendab, et kujundus nõuab täielikult uuesti sidumist.
Tekkis Composer’i ehk populaarse PHP sõltuvushalduri kasutamise võimalus nii Drupali tuuma kui ka lisamoodulite haldamiseks. Composer võimaldab rakendust ja selle toimimise jaoks vajalikke teeke/lisamooduleid, automaatselt paigaldada ja uuendada.
Muutus ka konfiguratsiooni haldus. Drupali haldusliideses tehtud seadistusi, mis varem asusid ainult andmebaasis, on võimalik failide kujul eksportida ja importida. See omakorda tähendab, et lisaks koodile saab versioniseerida ka seadistust.
Koos Composeri võimalustega on sellest väga palju abi moodsate ja mugavate automaatsete tarneahelate seadistamisel (CI/CD). Keskkondade põhiselt (test/staging/production) on nüüd väga lihtne seadistada soovitud erisusi, mida automaatsel tarnimisel arvestatakse.
Üldjuhul käib vana saidi sisu viimine ühelt Drupali versioonilt teisele kiiresti. Mahukamad tööd on tavaliselt seotud rätsepmoodulite ajakohastamisega. Lisaks võib ajakulu lisanduda juhul kui on kasutusel mooduleid, mis pole veel kogukonna poolt ära uuendatud Drupal 9ga ühilduvaks. Kõige hullemal juhul tuleb mõne “hüljatud” mooduli puhul kogu lahendus ümber teha.
„Tarkvara uuendust planeerides soovitame läbi mõelda ka facelift’i (kujunduse ajakohastamise) vajaduse,“ soovitab Ragnar Punak.
Kliendi jaoks näeksime kõige suuremat võimalust ja “käega katsutavat” kasu just viimases punktis. Kuna Drupal 7 veebileht on tõenäoliselt juba üsna mitmeid aastaid vana (ja kujundus võibolla enam mitte nii kaasaegne), siis oleks ratsionaalne teha nii kujunduse uuendus kui ka uuele Drupalile üleminek koos. See nõuab küll veidi rohkem tööd, aga oleks ressursi parem kasutamine ja leht saaks ka visuaalselt kaasaegsema lõpptulemuse.
4 peamist väljakutset, millega oleme põrkunud
1. Selgitustöö kliendile – ajakulu ja eelarve planeerimine
Drupal 7-lt 9-le üleminekuga kaasnevad fundamentaalsed muudatused, mis põhimõtteliselt sunnivad Drupalile ehitatud lahendust uuesti nullist üles ehitama.
Sageli aga kliendid ei oska aimata, et tegemist on nii mastaapse tööga. Seepärast, olles oma vigadest õppinud, teeme TWNis aegsasti klientidele põhjalikku teavitustööd. Kui klient on teadlik ja mõistab uuendamise vajadust ning on sellega arvestanud nii ajaliselt kui oma eelarves, siis on kõik suurepäraselt läinud.
Ajakulu võib olenevalt rätsepmoodulite mahust, kujundusest ja sisust küündida 50-75%ni esialgse veebi programmeerimise mahust. Näiteks infosaitide ja korporatiiv veebide puhul, kus on vähe rätsepmooduleid ja suhteliselt standardne sisu ning disain ja HTML jäävad samaks, saab hakkama kuni 50%ga uue lehe tegemisele kuluvast ajast. Funktsionaalsuse kasvades (nt veebipoed, iseteeninduskeskkonnad, infosüsteemid, siseveebid) kulub ka aega rohkem.
2. Testimise pealt ei tasu kokku hoida
Sageli ei mõista kliendid tarkvara uuendamise käigus tehtava testimise vajalikkust. Funktsionaalsuse testide tegemine enne veebilehe/infosüsteemi avalikustamist on aga väga oluline ja selle pealt ei tasu raha kokku hoida.
Aga miks testida? Tegemist on mahuka uuendusega ja kui tarne puhul ei ole piisavalt testitud, võib kasutaja jaoks ilmneda palju ebameeldivaid bugisid. Avalikus keskkonnas nende parandamine on tülikas kõigile osapooltele. Testimiseks soovitame arvestada ca 20% projekti eelarvest.
3. Jälgi jõudlust
Tuleb jälgida, et jõudluse osas ei tehtaks järeleandmisi. Teinekord tuleb arvestada, et suur süsteem vajab täiendavat optimeerimist (nt Google page speed insights’i puhul ei pruugi saada uue lehega sama tulemust, mis oli vana saidiga).
4. Mahuhinnangute tegemisel oleme realistlikumad
Kui varasemalt olime kohati ehk liiga optimistlikud, siis kogemuse kasvades oskame arvestada mahuhinnangutesse näiteks nii testimised kui puuduliku dokumentatsiooniga kaasnevad kulud. Teatud juhtudel tuleb arvestada ka administreerimiskuludega, et uus sait saaks parem (nt sisutekstide struktureerimine).
Kuidas edasi, kas iga aasta uus uuendus ja uus investeering?
Üleminek Drupal 6-lt 7-le läks kiiresti ja lihtsalt, kuid 7-lt 9-le uuendus tehtigi mastaapses mahus selleks, et tulevikus ei peaks rohkem selliseid suuremahulisi üleminekuid tegema.
Üks on kindel - tarkvara uuendustest ei ole kellelgi pääsu. Drupal ei ole ainus ja versiooniuuendusi tuleb teha ka teiste platvormide kasutajatel. Meie soovitus on vaadata, kuidas saada uuendustest maksimaalselt kasu - seda nii mugavama arendusprotsessi, suurema turvalisuse kui ka parema kliendikogemuse näol.
