DevOps

Kuva: Adobe Stock

DevOpsin määritelmä

Työkaverini kysyi DevOpsin määritelmää...

Onnistuin kyllä vastaamaan suhteellisen järkevästi sen olevan "toimintamalli sähköisten palvelujen tuotantoon: malli pyrkii automatisoimaan ohjelmistokehitykseen, testaamiseen ja ylläpitoon liittyvät IT-palvelutoiminnot. Ohjelmistokehityksessä käytetään ketterän kehityksen ja jatkuvan integraation sekä toimituksen menetelmiä." Mutta kysymys ja vastauksen ymmärtäminen jäivät vaivaamaan.

Koska ohjelmia ajalta ennen DevOpsia on yhä käytössä, on vertailu nykyisiin DevOps -mallilla kehitettäviin ohjelmiin helppoa. Ennen vastuuni kehittäjänä, eli "devaajana" loppui ohjelman valmistumiseen ja onnistuneen projektin päätteeksi ohjelma jäi ajoon ylläpidon huolehtimana. Kehittämisen muoto oli projekti, jolla oli selkeä loppu.

Ennen vastuuni kehittäjänä, eli "devaajana" loppui ohjelman valmistumiseen.

Jo tuolloin tavoitteena oli ohjelman pitkä elinkaari riippuvuudet minimoiden, jotta vaikkapa käyttöjärjestelmän päivittäminen olisi helppoa. Koska ohjelmat ovat viimeiset 20 vuotta olleet www-ohjelmistoja ja CSC:llä yli 10 vuotta Haka-autentikoituja, ovat käyttöjärjestelmäpaketin httpd ja shibd tietysti olleet kaikissa käytössä. Mutta, niiden asetukset ja päivitykset ovat kuuluneet ylläpidon Opsille, eikä minulla kehittäjänä ole ollut aina edes pääsyä tuotantokoneille niitä tutkimaan.

CSC:llä Ops-käytäntönä on ollut testikone, jossa ylläpito on kokeillut käyttöjärjestelmän ja pakettien muutokset ennen tuotantoa.  Malli on toiminut vaihtelevasti. Esim. isompi shibd-päivitys 2:sta 3:een on onnistunut joissain palveluissa ja toisissa ei. DevOps on konkreettisimmillaan tämän automatisointia (ja yleensä siirtämistä kehittäjän työksi).

Automatisoinnissa on paljon työtä ja monelle kehittäjälle myös uutta opeteltavaa, joten sen käyttöä on harkittava varsinkin, kun kehittäjistä on kova pula. Mutta työ on kallista ja ylläpitäjistäkin taitaa olla pulaa, joten DevOps on selvästi kehityksen suunta.

Ohjelman kehittäminen muuttuu jatkuvaksi.

Suurin ongelma on muutosten tuntemattomuus ohjelman kirjoitusajankohtana. Tämä pakottaa luomaan testit monille asioille, jotka eivät muutukaan tulevaisuudessa, mutta nämäkin ovat hyödyllisiä varmistaessaan ohjelman toiminnan. Lisäksi, täydellinen onnistuminen on mahdottomuus. Varsinkin pitkällä ajalla muutoksen suuruus yllättää, eivätkä testit pysty sitä kattamaan: ohjelman kehittäminen muuttuu jatkuvaksi.

Lisää tästä aiheesta » Siirry sisältöihin ja uutisiin »

 

Pekka Järveläinen

Pekka Järveläinen on työskennellyt CSC:llä pitkään ohjelmistokehitysprojektien parissa.