Jatkuvien päivitysten aikakausi

Tietoturva-aukot, taukoamaton kehitys, osaamisen happaneminen… Monet tekijät pakottavat sovelluksia päivittymään koko ajan. Voiko softa koskaan levätä, vai pitääkö vähintään sen käyttämistä kirjastoista huolehtia herkeämättä?

Ainainen päivittäminen on uinut kuluttajienkin arkeen. Uuni tahtoo uuden firmwaren, puhelin viettää säännöllisin väliajoin vartin asennellen itseensä uutta käyttöjärjestelmää – ja kokouksen keskeyttävät Windowsin päivitykset nyt ovatkin jo kaikille tuttua juttua.

Siihen nähden miten paljon päivitysten asentaminen on esillä arkielämässä, siihen suhtaudutaan monesti yllättävän yliolkaisesti ammatillisessa mielessä. Ei toki kaikilla tasoilla: kaikki tietävät, että päivittämättömät palvelimet ovat tietosuojariski. Mutta kun palvelimet jäävät historiaan ja Azure-ulkoistus siirtää perusylläpitovastuut Microsoftille, niin eikös nyt voi unohtaa tämän päivitysrumban?

Ei aivan.

Jokainen sovellus tarvitsee huoltonsa

Jos käytössä on sovelluksia, ne perustuvat aina johonkin joukkoon valmiskirjastoja tai ajoympäristöjä. Microsoft-maailmassa sovellusten alta löytyy tyypillisesti .NET-sovelluskehikko, mutta alusta voi toki yhtä hyvin olla vaikkapa Oraclen Java Runtime, PHP tai vaikka Node.js. Jos sovellukset on hankittu SaaS-pohjalta, toimittaja (toivottavasti) huolehtii näistä asioista. Erityisesti räätälöityihin sovelluksiin kannattaa kuitenkin kiinnittää huomiota, sillä niiden osalta päivitysvastuu jää aina asiakkaalle itselleen.

Tyypillisesti sovellukset rakennetaan liimaamalla yhteen useita – helposti kymmeniä – avoimen lähdekoodin valmiskirjastoja, jotka ratkovat yleisiä ohjelmointiongelmia ja säästävät näin työmääriä. Useimmat näistä kirjastoista kuitenkin hyödyntävät nippua toisia valmiskirjastoja, ja näinpä päädytään tilanteeseen, jossa erityisesti verkkopalveluissa suht’ yksinkertainenkin toteutus nojaa satoihin tai jopa tuhansiin GitHubissa kehitettäviin ilmaiskirjastoihin.

Kuten määristä voi arvata, myös päivityksiä satelee. Aamulla julkaistu uusi verkkosivusto on kirjastoriippuvuuksiensa osalta todennäköisesti vanhentunut jo iltapäivällä, mutta toki valtaosa päivityksistä on luonteeltaan vähämerkityksisiä. Ylipäätään vain hyvin pieni osa käytetyistä kirjastoista on ratkaisuissa sellaisessa roolissa, että niiden virheet voisivat vakavasti vaarantaa esimerkiksi palvelun tietoturvaa. Tuuriin on kuitenkin vaikea luottaa, jos lajina on ammattimainen tietotekniikkaan nojaava liiketoiminta.

Mikä on päivittämisen arvo?

”Mikä tää viritys oikein on, jotain viis vuotta vanhaa koodia vai?”

Laajan verkkosovelluksen kaikkien riippuvuuksien pitäminen ajan tasalla on työtä, joka vaatii aidosti aikaa. Suurin osa bugikorjauksista asentuu hyvin vaivattomasti, mutta isommat versiopäivitykset voivat olla työläitäkin. Jos päivityksiin käyttää päivän silloin tällöin, mitä sillä saa?

Useimmat kirjastot kehittyvät ajan mittaan. Bugeja korjataan, suorituskykyä parannetaan, ominaisuuksia lisätään. Vain pieni osa näistä muutoksista on aidosti palveluiden kannalta kriittisiä, useimpia ei edes käytännössä huomaa. Toisaalta ajantasaisuus on myös varautumista tulevaisuuteen: kun sitten jonain päivänä törmää esoteeriseen virheeseen, harva avoimen lähdekoodin projektin ylläpitäjä on innostunut kuuntelemaan bugiraportteja kolme vuotta vanhasta versiosta, ja ensimmäinen suositus on aina päivittää tuoreimpaan. Päivitys voi korjata ongelman tai sitten ei, mutta yleensä se on tehtävä ennen kuin asia etenee – toivottavasti ei tule kova kiire.

Joissain kirjastoissa päivitykset myös suorastaan mullistavat kehitysparadigmaa. Verkkopalveluiden käyttöliittymien taustalla paljon käytetty React on hyvä esimerkki tästä: pääversiot ovat tuoneet niin merkittäviä ohjelmointiparadigman muutoksia, että vuoden 2022 käytäntöjen mukainen React-koodi on jo aika kaukana viiden vuoden takaisesta toteutuksesta. Tällöin päivittämisestä tulee myös osaamiskysymys: alalla on aika paljon uusia tekijöitä, jotka eivät edes osaa suoraan käyttää kirjastojen vanhoja versioita.

Onko tuella väliä?

Osin päivitysten takana voi olla myös tarvetta muodolliselle tuelle. Tämä ei ole avoimen lähdekoodin kirjastojen kohdalla se tyypillisin syy päivitykselle, mutta kaupallisin ehdoin käytettyjen komponenttien elinkaaret vaikuttavat siihen, miten sovellusta on vastuullista ylläpitää.

Jos kirjastoa ei enää ylläpidetä tai sille ei ole saatavilla tukea – yleensä lähinnä neuvontaa – onko sillä merkitystä? Arjessa ei välttämättä. Kurjia tilanteita voi silti syntyä. Tulee mieleen esimerkiksi vuosien takainen Microsoftille avattu Azure-tukitiketti, jossa pyrittiin selvittämään sovelluksessa yllättäen ilmennyttä hidasteluongelmaa. Vastaus valitettavasti oli, että Microsoftin ei enää tarjonnut tukea ongelman selvitykseen, koska käytössä oli niin vanhoja komponentteja, ettei niitä tuettu. Ongelma ei lopulta edes ollut näissä komponenteissa, mutta se selvisi vasta myöhemmin. Ikä tuli tässä diagnoosin esteeksi.

Muodollinen elinkaaripolitiikka on tärkeä tukijalka monissa kriittisissä järjestelmissä, joiden jatkuvan toiminnan vaatimukset ovat kriittisiä. Silti esimerkiksi 10 vuoden tukisitoumusten hakeminen on monesti nykyaikana tehoton tapa varmistaa elinkaarta – aktiivinen maailman seuraaminen voi hyvinkin tulla halvemmaksi. Joskus tämä voi vaatia jatkoinvestointejakin: esimerkiksi avoimen lähdekoodin IdentityServer-kirjaston päivittäminen loppui taannoin, kun aktiivitekijät siirtyivät jatkamaan kehitystyötä kaupalliselta pohjalta. Toisaalta maltillinen vuosilisenssi voi lopulta olla pieni hinta mielenrauhasta ja jatkuvasta tuesta.

Voisiko päivittämisen automatisoida?

Osittain, ja varsinkin teknisestä näkökulmasta katsoen vastaus on ”kyllä”. Esimerkiksi GitHubin kehittelemä Dependabot on nimenomaan sovellus, joka on tarkoitettu helpottamaan päivityksiä. Se seurailee uusia kirjastojulkaisuja ja tekee automaattisesti ehdotuksia – teknisesti pull requesteja – kirjastopäivityksistä.

Automaatiolla voidaan hoitaa perustason päivityksiä silloin, kun ne eivät vaadi käytännössä mitään muuta kuin viitattavan paketin versionumeron vaihtamisen. Tällöinkin täytyy toki miettiä, miten muutos testataan. Automaatio voi ajaa kaikki automatisoidut testit, mutta vain ani harva sovellus on niin hyvin automaattitestattu, että laajoja päivityksiä uskaltaisi julkaista pelkästään näiden testien perusteella. Kun monet kirjastopäivityksistä vielä käytännössä vaikuttavat sovellukseen hyvin laajalla alueella, testaaminen onkin yksi isoimmista koordinoitavista asioista päivityksissä.

Käytännössä vastaus otsikon kysymykseen onkin ”Ei, jos haluat tehdä sen kunnolla”. Dependabotin kaltaiset automaatiot vähentävät päivittämisen työmäärää, mutta vain yksinkertaisimpien päivitysten osalta. Laajemmat ja vaikeammat päivitykset vaativat käsityötä, kenties jopa arkkitehtuurimuutoksia.

Lopulta tärkeintä kuitenkin on ymmärtää, että sovelluksen riippuvuuspaletin harkittu ylläpito on osa ohjelmiston elinkaarenhallintaa, eikä harkintaa voi automatisoida. Jos jokin kirjasto on lakannut päivittymästä, pitäisikö sitä ajatella kustannussäästönä vai uhkana? Jos jonkin työvälineen ekosysteemi on hajonnut ja ”kilpailija” vallannut markkinat, mitä se tarkoittaa osaamisen saatavuudelle tulevina vuosina? Nämä ovat kysymyksiä, joihin on vastattava ammattilaisten aivoilla, teknologista ja liiketoiminnallista ymmärrystä yhdistellen.

Useimmille riittää kvartaalikatsaus

Todellisuudessa erittäin suuri osa varsinkin vähemmän kriittisistä sovelluksista pärjää mainiosti ilman mitään päivityksiä. Tällöin luotetaan osin tuuriin, mutta säästetään sillä rahaa. Mitä laajemmassa ja jatkuvammassa käytössä sovellus on, sitä suuremmaksi riskit kuitenkin kasvavat.

Suosittelemme usein, että jatkuvassa käytössä olevien sovellusten riippuvuuksien ajantasaisuus tarkistettaisiin kvartaaleittain. Sovelluksen laajuudesta riippuen perustyöhön voi kulua työaikaa parista tunnista pariin päivään. Tällä työmäärällä helpot hedelmät poimitaan ja vaikeat viidakot tunnistetaan, jotta tarpeista, niiden ratkaisuista ja mahdollisista kompromisseista voidaan vaikka keskustella.

Viisasta on kuitenkin tehdä jotain pysyäkseen kartalla oman sovelluksen tilanteesta. Auditoinneissa tulee välillä vastaan järjestelmiä, joiden päivitysvelka on venynyt vuosi vuodelta. Päivitystuska vain pahenee, mitä enemmän sitä joutuu tekemään kerralla. Kun modernisoinnin kertatyömäärä alkaa lähestyä esimerkiksi sataa päivää, alkaa koko softan roskiinheittäminen houkuttaa. Silloin hiljaa hiipivä vanhentumisen home on syönyt alkuperäisen investoinnin.

Lisää aiheesta