DevOps on toimintatapa, joka oikein käytettynä ratkaisee monia ohjelmistokehityksen ongelmia. Digian Tero Niemistö kertoo, mikä on DevOps ja avaa käsitteen taustaa.
Ensiksi täytyy myöntää, että otsikko ei ole omaa käsialaani. Keskustelimme erään myyjämme kanssa muutamia kuukausia sitten lounaalla. Koetin selittää, mikä on ketteryyden ja DevOpsin suhde toisiinsa. Lopulta myyjän silmissä kirkastui: ”Ahaa! DevOps on niin kuin ketteryyden liukkari!” Riemuitsin kahdestakin syystä. Ensinnäkin hän ymmärsi asian ja toisekseen vihdoinkin joku puki sen tiivistetysti sanoiksi paremmin kuin kukaan ennen.
Ketterän ohjelmistokehityksen historia juontaa juurensa aina vuoteen 1970, jolloin Winston Royce julkaisi kuuluisan artikkelinsa ”Managing the Development of Large Software Systems”. Artikkelissaan Royce esitteli useamman mallin, kuinka isoa ohjelmistokehitysprojektia pitäisi hallita. Artikkelissa hän esitteli ensimmäisenä maailmassa vesiputousmallin, josta totesi: ”…implementation described above is risky and invites failure”. Niinpä hän artikkelin lopussa päätyi suosittelemaan mallia, joka perustui iteraatioon ja inkrementaalisuuteen. Kyseisen mallin kuva tosin oli artikkelin viimeisellä sivulla ja niin epäselvä ja monimutkainen, että se sivuutettiin lähes tyystin ja kaikkien huomio keskittyi jo sivulla kaksi esitettyyn vesiputousmalliin, joka näytti niin helpolta ja yksinkertaiselta. Niinpä kaikkialla maailmassa adoptoitiin ohjelmistokehitykseen vesiputousmalli.
31 vuotta myöhemmin ja lukemattomien epäonnistuneiden ohjelmistoprojektien jälkeen 17 ohjelmistokehityksen ammattilaista kokoontui epäformaalisti Snowbirdin laskettelukeskuksessa Utahissa. Siellä ollessaan he laativat spontaanisti ketterän manifestin ja 12 ketterän kehityksen periaatetta, joka toimii edelleen ketterän kehityksen kulmakivenä maailmanlaajuisesti. Oli jotenkin ironista, että ketterän kehityksen yleisimmäksi ilmentymäksi nousi Scrum, joka perustui nimenomaan iteratiiviseen ja inkrementaaliseen kehitykseen.
Ketterä kehitys painotti ennen kaikkea nopeaa reagoimista muutokseen. Vesiputousmallin suurimpia ongelmia oli toistuvasti puutteelliset, vajaat tai epätäydelliset vaatimusmäärittelyt. Ketterä kehitys perustui siihen, että muutokset kesken ohjelmistokehityksen otettiin mielellään vastaan sen sijaan, että niitä vastustettiin pitäytymällä suunnitelmassa.
Ketterän kehityksen yhdeksi ongelmaksi 2000-luvun alkupuoliskolla muodostui nimenomaan reagoiminen muutoksiin. Muutoksiin kyllä reagoitiin, mutta laivan kääntäminen tapahtui hitaasti. Jos oli tarve vaihtaa sovelluspalvelin, sen vaihtaminen saattoi olla oma miniprojektinsa. Jos järjestelmää piti skaalata ylöspäin uusilla palvelimilla, se kesti useita päiviä. Jokainen muutos ohjelmistoon ja alkuperäiseen arkkitehtuuriin aiheutti hallitsematonta teknistä velkaa ja lisäksi kasvatti virheherkkyyttä. Ohjelmistojen modulaarisuus ja hajautus vain kasvattivat kompleksisuutta, ja moni järjestelmä muuttui nopeasti henkilöriippuvaiseksi.
Näihin – ja moniin muihin – ongelmiin toi vastauksen DevOps-toimintamalli ja sen räjähdysmäisesti kasvaneet työkalut, joiden avulla on mahdollista: provisioida palvelimia ohjelmallisesti, hallita ja versioida konfiguraatioita, automatisoida ohjelmien kääntäminen, paketointi, integraatiotestaus sekä jopa asennus, keskittää hajautetun järjestelmän lokitiedostot yhteen paikkaan ja monia muita asioita.
Se, mikä aiemmin aiheutti teknistä velkaa, pysyy DevOps-työkaluilla hallinnassa esimerkiksi keskitetyllä konfiguraatiohallinnalla. Kun aiemmin manuaaliset prosessit aiheuttivat lukemattomasti inhimillisiä virheitä käännöksissä, paketoinnissa ja tuotantoon viennissä, automatisaatiolla ne pystytään eliminoimaan lähes kokonaan pois. Automaatiotestauksella varmistetaan, että mikään pieni yksittäinen muutos ei aiheuta järjestelmässä odottamattomia poikkeamia.
DevOps-työkalut ja automaattinen laadunvarmistus ovat vieneet kehityksen niin pitkälle, että joissakin yrityksissä pyrkimyksenä on, että aloittavan työntekijän kirjoittamaa koodia viedään tuotantoon heti ensimmäisenä työpäivänä. DevOpsin tuoma muutos ohjelmistokehitykseen on suurin muutos, joka ohjelmistokehityksessä on ollut 2010-luvun alkupuoliskolla. Nähtäväksi jää onko se suurin muutos myös 2010-luvun loppupuolella vai varastaako Docker ja konttiteknologia sen tittelin.
Ilman DevOpsia ketteryys koki jatkuvaa muutoskitkaa. Muutoksia haluttiin tehdä, mutta niiden implementointi kesti liian kauan tai aiheutti liikaa teknistä velkaa. DevOps siis toi ketterään kehitykseen mahdollisuuden nopeisiin muutoksiin ja lähtöihin poistaen muutoskitkan, toimien ketteryyden liukuvoiteena.