DevOps on yksi IT-alan trendeistä joka on ollut näkyvästi esillä viime aikoina. Mitä DevOps tarkoittaa ja pitäisikö minunkin olla siitä kiinnostunut?

Perinteisissä organisaatioissa tai projekteissa ohjelmistokehitys ja asennusten sekä tuotantoympäristöjen ylläpitäminen ovat olleet eri tiimien vastuulla. Pahimmassa tapauksessa tiimien välillä on eri organisaatioihin liittyviä raja-aitoja, jotka vaikeuttavat yhteistyön tekemistä. Devaajat ja asennuporukka ovat pöydän eri puolilla ja pahimmillaan vastakkainasettelu on ilmeistä.

Devaajat haluavat tuottaa ja julkaista uusia ominaisuuksia, korjata bugeja ja muokata sovellusta asiakkaan ja projektin toiveiden mukaisesti. Ylläpitotiimi taas haluaisi tehdä muutokset, jos niitä on tehtävä, mahdollisimman hallitusti ja siten että järjestelmä toimii luotettavasti, ilman turhia katkoja tai ongelmia.

DevOps on tiimien välisten raja-aitojen purkamista

DevOps-mallissa ohjelmistokehitystiimin ja ylläpitoporukan välinen raja on häilyvä tai poistettu. Voidaan ajatella, että on vain yksi tiimi joka tekee ohjelmistokehitystä ja sen lisäksi pitää huolen myös tuotanto- ja testiympäristöjen asentamisesta ja ylläpidosta. Ohjelmiston asennus ja tuotantopäivitysten hoitaminen on osa projektia ja tiimin vastuulla. Näin vältetään hommien ja vastuiden pallottelu eri tiimien välillä.

DevOps mahdollistaa säännölliset julkaisut

Perinteisissä ohjelmistoprojekteissa julkaisuja ja tuotantoon siirtoja tehdään harvoin, projektista riippuen esimerkiksi kaksi tai kolme kertaa vuodessa. Tämä johtaa siihen, että julkaisuihin kertyy paljon muutoksia ja uusia ominaisuuksia. Viime hetkellä tehdään vielä muutoksia ja tungetaan uusia ominaisuuksia mukaan, koska seuraava julkaisu tehdään ehkä vasta useamman kuukauden päästä.

Julkaisun ja tuotantopäivityksen tekeminen on pelottavaa ja stressaavaa, koska niitä tehdään niin harvoin, että siihen ei muodostu rutiinia. Muutoksia on paljon ja pitkältä ajalta, joten kehitysympäristöihin tehtyjä asetuksia on vaikea palauttaa mieleen ja pahimmassa tapauksessa on asetuksia ja muutoksia, joita ei ole dokumentoitu. Harvoin tehtäviä päivityksiä ja asennuksia ei tule automatisoitua niin helposti, koska niiden tekemiseen ei ole selkeää prosessia, jonka voisi automatisoida. Toisaalta päivityksiä tehdään “niin harvoin”, että niiden automatisoinin vaatima työaika ja kehitys ei tunnu järkevältä.

Kun tuotantoympäristöjen asentaminen ja päivittäminen on ohjelmistokehitystiimin vastuulla on luontevaa miettiä tuotantoympäristöjä ja niihin tehtäviä asennuksia jo aikaisessa vaiheessa kehitysprojektin aikana. Asennusten ja päivitysten automatisointi on helpompaa, koska tämä tarve voidaan huomioida jo sovelluksen kehitysvaiheessa, kun mietitään projektin teknologioita ja teknisiä ratkaisuja. Jälkikäteen, kun sovellus on jo julkaisuvalmis, tämän ominaisuuden toteuttaminen on vaikeampaa ja työläämpää. Automatisoinnin hyödyt ovat myös huomattavasti ilmeisemmät, koska tiimi voi helpottaa omaa työtään automaation avulla.

Ketterässä ohjelmistokehitykssä on tavoitteena, että projektista voidaan tehdä julkaisuja lyhyellä syklillä, jolloin voidaan esitellä asiakkaalle projektin etenemistä ja tuotettavaa ohjelmistoa. Tällaisessa kehitysprosessissa päivitysten ja asennusten automatisointi tuottaa suurimman hyödyn, koska niitä tehdään melkein jatkuvasti.

Usein tapahtuvat tuotantojulkaisut ovat tällöin osa normaalia päivärutiinia, jolloin niitä ei tarvitse pelätä, koska ohjelmistoon tehtäviä muutoksia on vähemmän ja asennusproseduuri on tuttu.

DevOps asettaa vaatimuksia tiimille ja organisaatiolle

DevOps asettaa vaatimuksia organisaatiolle ja ohjelmistokehitystiimille. Tiimissä on oltava laaja-alaista kokemusta ja näkemystä siitä ympäristöstä, jossa ohjelmistoa käytetään. Ohjelmistoa ei voi kehittää omassa kuplassa, miettimättä millaisessa ympäristössä ja miten sitä tulla ajamaan.

Eikö riitä, että ohjelmistokehittäjät osaavat ohjelmoida? Onko kaikkien osattava kaikkea?

Jos tiimissä ei ole valmiiksi osaamista ja näkemystä siitä millaisessa ympäristössä ohjelmistoa ajetaan, olisi tärkeää saada tiimin avuksi henkilöitä, jotka voivat kantaa vastuuta tästä.

Tiimillä on oltava valtuudet tehdä omaa työtään ja projektia koskevia päätöksiä ja ratkaisuja. Jos erilaisten ratkaisujen ja kokeilujen tekemiseen on haettava hyväksyntä joltain erilliseltä taholta organisaatiossa, muuttuu DevOpsin tai ketterän kehittämisen toteuttaminen hyvin vaikeaksi.

Hyvät ideat, kuinka hommaa voitaisiin automatisoida tai helpottaa, kaatuvat helposti organisaation ylemmissä kerroksissa, kun asioita jyrätään vetoammalla yrityksen IT-strategiaan ja sen asettamiin vaatimuksiin.

Entäs käytännössä?

Teoriassa kaikki tämä olisi tietysti kivaa, mutta miten homma toimii käytännössä? Onko DevOps “kaiken sen vaivan” arvoinen ja hyötyykö projekti siitä todellisuudessa?

Itse uskon, että DevOps lähestymistavalla voidaan saavuttaa huomattavia hyötyjä ohjelmistokehityksessä ja omien kokemusteni pohjalta sen avulla tekemisestä saadaan mielekkäämpää, mukavampaa ja vähemmän stressaavaa.