Jos jotkin seuraavista ongelmista ovat vielä korjaamatta, nyt ne kannattaa korjata:
- Ominaisuuksien kehittämisessä alkaa kestää kauan ja aika tuntuu menevän muuhun kuin uusien ominaisuuksien kehittämiseen.
- Ohjelmistossa tulee odottamattomia bugeja, vaikka se oli kehittäjän koneella testattu.
- Julkaisut ovat työläitä.
- Ylläpito on työlästä.
- Manuaalisissa toimenpiteissä tapahtuu inhimillisiä virheitä.
- Tieto ohjelmiston virheistä tulee sen käyttäjiltä.
Millä käytänteillä pitäisi lähteä liikenteeseen?
Versiohallinta
Koodi on hyvä säilyttää versiohallintajärjestelmässä (VCS). Historian on oltava tallessa ja menneisyyteen pitää pystyä palaamaan. VCS:ssä on hyvä säilyttää myös mm. koodia käyttävien ohjelmien ja automaattiseen julkaisuun liittyvät määrittelyt.
Ympäristönhallinta
Perinteisesti koodia käyttävät ohjelmat dokumentoidaan, asennetaan ja päivitetään erikseen. Menetelmä on työläs ja aiheuttaa paljon virheitä. Nykyään esimerkiksi Docker–konttiteknologialla voidaan määritellä koodin vaatima ympäristö ja määrittelyn perusteella voidaan rakentaa eristetty kontti. Kontti voidaan esimerkiksi pystyttää palvelimelle. Siellä se toimii vähän kuin palvelimen sisäisenä minipalvelimena, johon on asennettu vain määrittelyn mukaiset ohjelmat.
Sama kontti saadaan pystyyn identtisenä niin tuotantoympäristöön, testiympäristöön kuin kehittäjän omalle koneelle. Palvelinohjelmien dokumentointi, asentaminen ja päivitys voidaan siis tehdä yksittäisten määrittelytiedostojen kautta.
Julkaisunhallinta
Muutosten yhteydessä on hyvä rakentaa muutoksista julkaistava ”artefakti”. Artefaktin tarkoitus on olla muuttumaton palikka, jonka voi laittaa pyörimään minne vaan ja sen saa toimimaan vaivatta. Artefakti voi olla mm. Docker image.
Artefaktia olisi hyvä testata ennen julkaisua. Tätä varten voi olla erillinen testiympäristö. Testiympäristössä tapahtuvassa testauksessa painotetaan etenkin ohjelmiston eri osien välistä toimintaa sekä sitä, miten ohjelmisto toimii käyttäjän näkökulmasta.
Testausta on sekä manuaalista että automaattista. Suurin osa testauksesta olisi hyvä olla automaattista. Automaattitestauksella varmistetaan, että asiat toimivat odotetulla tavalla. Manuaalitestauksella selvitetään, miten joku asia suoriutuu tai miltä se vaikuttaa ihmisen näkökulmasta. Manuaaliset ja toistuvat toimiihan tämä -testit tulisi automatisoida.
Virheenhallinta
Virheistä tulee aina ilmoitus. Jos ei automaation kautta, niin manuaalisesti käyttäjiltä. Koodatut palvelut on hyvä rakentaa siten, että ne kirjoittavat virhelokia odottamattomissa virhetilanteissa. Kaikkien palveluiden virhelokit tulee kerätä ja näistä kannattaa rakentaa hälytykset, jotta tiimi saa tietää heti, kun odottamaton virhe tapahtuu. Odotettuihin virheisiin kannattaa rakentaa automaattiset korjaavat toimenpiteet.
Virhelokien lisäksi on hyvä kerätä metriikkatietoja. Tietoja voidaan kerätä mm. järjestelmän vastausajoista, liikenteen määrästä tai laskentatehon riittävyydestä. Odottamattomista poikkeamista on hyvä taas tulla hälytys tiimille, mutta odotettuihin voisi rakentaa automaattisia korjaavia toimenpiteitä.
Jos esimerkiksi laskentatehoa on liian vähän tai paljon, sitä voi automaattisesti lisätä tai vähentää ja jos levytila on loppumassa, tiedostoja voi arkistoida jne. Kun uusi odottamaton virhe sattuu, on hyvä miettiä, voiko siitä jatkossa tehdä odotetun virheen.
Ensimmäinen askel
Tie DevOpsin luvattuun maahan on täynnä sudenkuoppia, joihin uppoaa aikaa ja rahaa. Oppaaksi matkalle kannattaa ottaa joku alkuperäisasukas. Käytänteet ja strategiat pitää valita ja muovata liiketoimintalähtöisesti. Tätä varten on hyvä tietää, mitä vaihtoehtoja on ja mitkä niiden keskeiset erot ovat. Ensimmäiset askeleet kannattaa suunnata potentiaalisen kumppanin luo. Hänen kanssaan on syytä ihan ensimmäiseksi ensin selvittää, missä ollaan ja minne kannattaa mennä.
