Laitetaanko DevOpsilla vai ilman?
- DevOps
- ohjelmistokehitys
10-vuotias DevOps on saavuttanut kunnioitettavan aseman nykyaikaista ohjelmistokehitystä kuvaavana terminä. Softafirmat kouluttautuvat ja miettivät kehtaako projektia enää myydä ilman DevOpsia. Asiakkaat nyökyttelevät hyväksyvästi tai ihmettelevät mistä tässäkin taas on kyse. DevOpsin keskiarvomääritelmä lienee “Ohjelmistokehityksen menetelmä, jossa kehitys (Dev) ja tuotanto (Ops) saadaan toimimaan ketterästi yhdessä, jolloin prosessi nopeutuu ja laatu paranee”. Mutta miten tähän päästään ja onko kyseessä ideologia vai teknologia – molempia kun innokkaasti myydään.
Ideologisesti DevOps juontuu perinteisestä ohjelmistoprosessin kompromissista. Siinä missä tuotanto haluaisi, että tuotetta ei rikota muutoksilla, kehityksessä pyritään maksimivauhtiin ja halutaan välttää tylsiä rutiineja kuten mekaanista testausta. Lystin maksaja haluaa kaiken edellä mainitun edullisesti. Kompromissina testaus ja julkaisu tapahtuu harvakseltaan synnyttäen tiimien välille kitkaa ja odottamattomia tilanteita. Tämä toimii kehitysjarruna Agile-periaatteille, jotka vaativat nopeaa läpimenoa, mutta eivät itsessään tarjoa käytännön ratkaisua tekniseen toteutukseen.
Nopea reagointi on yhteinen vastuu
DevOpsissa ohjelmistoprosessi rakennetaan jatkuvan muutoksen varaan. Periaatteen hahmottaa parhaiten karrikoidulla liukuhihnaesimerkillä: eri osastojen peräkkäiset hihnat pidetään jatkuvassa liikkeessä ja matkan varrella ihmiset sekä koneet suorittavat tuotteelle toimenpiteitä. Jos havaitaan virhe tai odottamaton muutos, koko hihna pysähtyy.
Mitä tällä saavutetaan? Tiimit hakeutuvat luontaisesti yhteistyöhön ja selvittävät ongelman saadakseen tuotannon jälleen käyntiin, katkokset ovat lyhyitä eikä muutoksia pääse kasaantumaan tai kalliita katastrofeja syntymään. Tämä vaatii kehittäjän perinteisen vastuualueen laajentamista ja sen tukemista tuoreella teknologialla. Siinä missä hihnan alkupään innovointi herää uuteen kukoistukseen, loppupään tehtävät muuttuvat tylsiksi ja ylikuormitetuiksi – selkeiksi automatisoinnin kohteiksi.
Kaikki menee putkeen
Se ideologiasta – pääosa DevOps-työstä tapahtuu käytännön tasolla, työkaluista ja työtavoista koostuvan DevOps-putken toteutuksessa. Automatisoinnin tuoma tehokkuus on päivänselvä tavoite, mutta DevOpsin varsinainen elinehto on automaattinen, nopea, ratkaisuun tähtäävä ja kohdennettu palaute. Putken kehitys on syytä aloittaa läheltä kehittäjää, koska tämä synnyttää vastuuntunnon ja luottamuksen järjestelmää kohtaan. Keskitetty kehitysympäristön hallinta ja CI-järjestelmän antama välitön palaute jokaisesta muutoksesta ovat selkeitä ensiaskeleita. Seuraavaksi automatisoidaan muu testaus, julkaisu ja lopulta infrastruktuurin ylläpito. Putken edetessä joudutaan kauemmas kehittäjän mukavuusalueelta ja sykli voi hidastua minuuteista päivätasolle – avainasemaan nousee palautteen laatu ja kohdentuminen oikeille henkilöille. Matkan varrella ei saa unohtaa, että huipputeknisenkin ratkaisun kuuluu palvella ihmistä eikä itseään.
Tämä kaikki ei tapahdu hetkessä, varsinkaan jo olemassa olevien tuotteiden kohdalla. Lisäarvoa tuotetaan jokaisella askeleella, mutta on huomattava sen keskittyvän alkutaipaleella laatuun ja ennustettavuuteen, tehokkuuden ja nopeuden seuratessa myöhemmissä vaiheissa. Teknologiakumppanina Wapice ei tyydy vain hyödyntämään parhaita DevOps-käytäntöjä, vaan tarjoaa asiakkaalle mahdollisuuden erottua strategisesti räätälöidyillä ja huippuunsa viritetyillä ratkaisuilla.
Rajoittuuko tämä sitten vain moderneihin web-, mobiili- ja palvelusovelluksiin? Ei toki, vaikka suuri osa DevOps-työkaluista ja tietämyksestä niihin keskittyykin. Syynä lienee yksinkertaisesti kyseisten sovellustyyppien säännönmukaisuus, standardinomaiset automaattitestimenetelmät ja palvelinympäristöt. Sulautettujen tai laitteistoläheisten järjestelmien tai perinteisten työpöytäsovellusten toimintakenttä on hyvin erilainen ja ensiksi onkin syytä miettiä, miten Ops ylipäätään määritellään. Nyrkkisääntönä DevOps-kokonaisuus päättyy prosessissa viimeiseen toimijaan, joka hyötyy nopeudesta. Sen ei tarvitse olla loppukäyttäjä, vaan myös esimerkiksi erillinen QA-osasto tai alihankintaketjun seuraava porras ovat mahdollisia päätepisteitä.
Palvelinmaailmaan verrattuna validoinnin vaiheet saattavat olla paljon raskaampia laitteistorajoitteista johtuen, joten tarvitaan innovatiivisia ratkaisuja niiden kiihdyttämiseksi DevOps-sykliin sopiviksi. Tärkeä kysymys onkin resurssien riittävyys: ollaanko testilaitteiden hankintaan ja DevOps-putken kehitykseen valmiita sijoittamaan riittävästi? Ohjelmistotoimittajan kokemus punnitaan siinä, osaako se analysoida järkevän DevOps-laajuuden ja taajuuden, sekä valita tai toteuttaa sopivat työkalut sekä asiakkaalle että itselleen. Suosittelen siis korjaamaan otsikon kysymyksen muotoon ”Millaisella DevOpsilla laitetaan?”.
Alkuperäinen kirjoitus julkaistu Tekniikka ja Talous kumppaniblogissa 28.5.