Oletko kuullut tiimissäsi tai muualla organisaatiossasi jonkin seuraavista väittämistä?
Joonas Jauhiainen
DevOps Lead
Joonas is a DevOps lead with experience in telecom, banking, insurance, and manufacturing, among other industries. His hobbies include investigation of IT devices, developing games and other SW projects not to mention underwater rugby!
”Palautesykli on liian pitkä.”
”En ole varma, mitä testejä ajamme.”
”En tiedä, missä testituloksemme ovat.”
”En ymmärrä testituloksiamme.”
Tällaiset kysymykset tarkoittavat yleensä, että olet ottanut CI/CD-toimintatavat onnistuneesti käyttöön kehityksessä ja automaatio vapauttaa aikaa jatkokehitykselle. Mutta miten vastaat näihin kysymyksiin, ennen kuin niistä tulee todellisia ongelmia ja ihmiset alkavat menettää kiinnostuksensa?
Onneksi vastaus on ulottuvillasi! Sinun on määriteltävä olennaiset mittarit ja tehtävä ne näkyviksi koko organisaatiolle, erityisesti tiimillesi.
Mitä mittareita tarvitsen?
Saamme tämän kysymyksen usein. Valitettavasti vastaus on pahamaineinen ”se riippuu”. On parempi näyttää jotain kuin ei mitään, joten aloita yksinkertaisesti jostain.
Kun organisaatiosi pystyy keräämään, tallentamaan ja esittämään dataa, alat yleensä huomata, mitä mittareita tarvitaan. ”No eihän tästä ole juuri apua”, saatat ajatella. Siksi haluamme esitellä mielenkiintoisen artikkelin, johon törmäsimme. Sen kirjoittajat esittelevät seuraavat mittarit:
Käyttäjien tyytyväisyys
Tuotannossa löydetyt virheet
Testitapausten kattavuus
Virheet sprinttien välillä
Sovitut ja toimitetut user storyt
Näitä tarkastellessamme huomasimme, että ne ovat osittain päällekkäisiä DORA-mittareiden kanssa.
Käyttöönottojen tiheys
Tämän pitäisi korreloida korkean ”(1) Käyttäjien tyytyväisyyden” kanssa. Itse asiassa se on edellytys sille, että sitä voidaan edes havaita.
Muutosten läpimenoaika
Tämä kertoo, kuinka nopeasti pystyt viemään idean tuotantoon asti, mikä vastaa mittaria ”(5) Sovitut ja toimitetut user storyt”.
Muutosten epäonnistumisaste
Tämä kertoo, kuinka monta virhettä olet löytänyt ja kuinka kauan niiden korjaamiseen kului. Toisin sanoen ”(3) Testitapausten kattavuus” auttaa sinua analysoimaan tarkemmin muutosten epäonnistumisasteen juurisyitä.
”(4) Virheet sprinttien välillä” on tarkempi esimerkki yleisestä epäonnistumisasteesta.
Palveluiden palautumisaika
Tämä kertoo, kuinka nopeasti pystyt ratkaisemaan tuotantohäiriöt. Se on seuraava kysymys, kun olet selvittänyt ”(2) Tuotannossa löydetyt virheet”.
Koska mittarit ovat osittain päällekkäisiä ja DORA-mittareiden on todistettu toimivan, pidämme niitä hyvinä lähtökohtina.
Mistä aloittaa?
Nyt kun olemme määritelleet useita järkeviä mittareita, miten voimme kerätä niitä?
Eficodella uskomme automaatioon ja siihen, että raporttien ja dashboardien datan tulisi olla mahdollisimman reaaliaikaista. Siksi käynnistimme muutama vuosi sitten pari open source -projektia tukemaan tällaisia hankkeita:
Asiakasprojekteissamme Jenkins CI on ollut käytetyin CI/CD-ratkaisu. Olemme jo toteuttaneet onnistuneen proof-of-conceptin mittareiden tuottamiseen käyttämällä open source -aikasarjatietokantaa nimeltä InfluxDB yhdessä dashboardien rakentamiseen tarkoitetun open source -työkalun Grafanan kanssa.
Open source -ratkaisut voivat vaatia hieman omaa työtä, mutta ne ovat edullisin vaihtoehto, koska ne ovat täysin ilmaisia. Näin pääset nopeammin alkuun – muista, että dataa kannattaa alkaa tarkastella mahdollisimman pian, jotta voit kehittää mittareita edelleen.
Esimerkki toteutuksesta:
Miten edetä, kun dataa on saatavilla?
Kun olemme rakentaneet infrastruktuurin datan keräämiseen ja visualisointiin, luomme yleensä muutaman kuvaajan vastaamaan useimmin esitettyihin kysymyksiin. Esimerkiksi: ”Mikä on Continuous Integrationissa ajettavien testien läpäisyaste?” Tämä kertoo esimerkiksi aiemmin mainitusta muutosten epäonnistumisasteesta tai sprintin aikana havaituista virheistä.
Data tulee suoraan CI/CD-työkalustasi, joten se on mahdollisimman ajantasaista. Kun data on kaikkien nähtävillä, tiimilläsi on paremmat edellytykset ymmärtää nykytilanne.
Seuraavaksi kannattaa pohtia sidosryhmiesi kanssa tuotetta, jota sinä ja tiimisi rakennatte. Kaikki data ei ole yhtä tärkeää kaikille. Esimerkiksi esihenkilöt haluavat nähdä koko kuukauden läpäisyasteen, kun taas kehittäjiä kiinnostavat tuoreimmat tulokset ja se, läpäiseekö ympäristö smoke testit.
Onneksi Grafana ja muut ratkaisut tukevat useita dashboardeja. Näin voit helposti visualisoida erillisiä mittareita johdolle, tiiminvetäjille, QA-tiimeille ja muille.
Suosittelemme tarjoamaan jokaiselle sidosryhmälle olennaisen datan ja mahdollisuuden tarkastella tarvittaessa kaikkea dataa.
Olemme usein nähneet, että kun nykyistä dataa aletaan näyttää, syntyy lisää ideoita siitä, mihin kannattaisi tarttua seuraavaksi. Useimmiten tämä saa tiimit tekemään päätöksiä faktojen pohjalta sen sijaan, että syitä keksittäisiin hatusta.
Miksi et syventäisi osaamistasi ja oppisi lisää laadun rakentamisesta ohjelmistoosi?
- DevOps
- Efilife
- CI/CD
Subscribe to our newsletter
Related blogs