Automatiseerimisest tarkvaraarenduses

Tarkvara arendamisel ettetulevate korduvate protsesside automatiseerimise väärtuses kahtlevad vist üsna vähesed kogenud arendajad ja projektijuhid. Tegelikus elus aga paraku ei ole automatiseerimine kõige prioriteetsem. Sellest võibolla räägitakse projekti alguses, aga töö käigus jääb see tihti unarusse.

Iga arendaja või testija, kes nüri järjekindlusega ühe ja sama toimingu sooritamise asemel eelistab midagi kasulikku oma projekti jaoks teha, peaks tundma automatiseerimise põhimõtteid. Projektijuht, kes teab meeskonna oskuste ja aja efektiivse kasutamise eeliseid ja ei soovi riskida projekti ebaõnnestumisega, peaks oma meeskonda julgustama leidmaks aega ja võimalusi automatiseerimise rakendamiseks.

 

Miks üldse automatiseerida?

Põhjuseid, miks tarkvaraarenduses automatiseerimist rakendada, on mitmeid. Mõned olulisemad:

  • Korratavus. Skript on korduvalt käivitatav ja kui arvuti, millel skripti jooksutatakse, ei ole just väga kummalisel seisus, siis võib üsna kindlalt eeldada, et kirjeldatud tegevused tehakse iga kord täpselt samas järjekorras.
  • Usaldatavus. Skript, kui see on koostatud korrektselt, ei tunne mõistet “inimlik eksimus”.
  • Efektiivsus. Skript on kiirem, kui inimene.
  • Testitavus. Skriptitud protsesse testitakse nende arendamise käigus pidevalt, nagu ka rakenduse koodi. Lõpptulemusena on automatiseeritud skriptide näol tegu küpse ja tõestatult toimiva, korratavate protsesside kogumiga.
  • Versioneeritavus. Skriptid on versioonihaldussüsteemidega hallatavad. Käsitsi tehtavate toimingute puhul on versioneeritavad äärmisel juhul vaid vastava tegevuse juhised ja dokumentatsioon. Inimfaktori versioneerimine tänapäevaste vahenditega veel kahjuks võimalik ei ole.

Igasuguste infrastruktuuriga seotud tegevuste automatiseerimine võimaldab meeskonnal pühendada rohkem aega kasuliku töö tegemisele. Näiteks saab automatiseerida rakenduse buildimise protsessi, testimiseks vajalike andmete tekitamise, erinevate keskkondade seadistamise ja uuendamise jne. Kuid võib esineda ka olukordi, kus automatiseerimisele kulub rohkem aega ja ressurssi, kui sellega lõpuks kokku hoitakse, näiteks kui automatiseeritakse valesid protsesse, tehakse seda halvasti või püütakse automatiseerida liiga palju. Mida ja millal automatiseerida, sellest juba allpool.

 

Mida automatiseerida?

Kui automatiseerimise vajaduses on selgusele jõutud, on järgmine loogiline küsimus, mida automatiseerida. Vastus sõltub muidugi konkreetsest projektist ja selle spetsiifikast, kuid mõned jooned on erinevatel projektidel siiski ühised. Mõned näited:

  • Rakenduse buildimine ja testkeskkonda paigaldamine
  • Unit testimine
  • Funktsionaalne testimine
  • Koormustestimine
  • Koodi testidega kaetuse kontroll, kvaliteedimeetrikate koostamine, konventsioonidele vastavuse kontroll jne
  • Testitulemuste raportite genereerimine

Nimekiri ei ole loomulikult täielik, kuid võib kasutada rusikareeglit – automatiseerimist tuleks kaaluda iga tegevuse ja protsessi puhul, mida tõenäoliselt tuleb projekti jooksul korduvalt sooritada. Mida rohkem on ette näha mõne tegevuse kordumist, seda suurem on võit selle automatiseerimisest.

Kuid ei piisa vaid tõdemisest, mida peaks automatiseerima, tuleb mõelda ka, kuidas midagi automatiseerida – uurida ja võrrelda erinevaid vahendeid, hinnata automatiseerimiseks kuluvat ressurssi võrreldes olukorraga, kus sama tegevust tehtaks käsitsi. Nagu iga äriotsuse puhul, nii ka siin taandub kõik lõpuks tehtavate kulutuste ja saadava kasu suhte analüüsile.

Ülaltoodud nimekirjas on olulise punktina välja toodud testitulemuste raportite genereerimine – iga automatiseeritud testimistegevuse väljundiks peaks olema kogu meeskonnale kättesaadav ja üheselt mõistetav raport. Selliste raportite eesmärk on meeskonda tekkinud probleemidest võimalikult operatiivselt teavitada, kuvades näiteks testide tulemused suurele ekraanile või saates buildi ebaõnnestumisel asjassepuutuvatele meeskonnaliikmetele teate e-postiga. Samuti saab sellise süsteemi toimimisel ka juhtkonnale pakkuda käegakatsutavat ülevaadet projekti käekäigust.

 

Millal automatiseerida?

Automatiseerimisele tuleks hakata mõtlema niipea, kui mõnda eelkirjeldatud tegevust hakatakse korduvalt sooritama. Pole näiteks mõtet automatiseerida rakenduse buildimise protsessi projekti lõpus, kus sellest saadav kasu sisuliselt puudub. Samas automatiseerides selle niipea, kui arendus algab, säästetakse kokkuvõttes väga palju aega (ja raha).

Kuid enne, kui kõike automatiseerima asuda, tuleb olla kindel, et automatiseeritav tegevus tegelikult ka projekti käigus toimuma hakkab, et see leiab kasutust rohkem, kui loetud korrad kogu projekti jooksul ja et automatiseerimisega tegelev inimene teab täpselt, mismoodi automatiseeritav protsess toimib. On tegevusi, mida projekti käigus väga tihti ette ei tule ja nende puhul võib autoamtiseerimisele kuluv ressurss osutuda saadavast kasust suuremaks.

Kui protsesside puhul, mille automatiseerimine on mõistlik, automatiseerija ei tea täpselt, mismoodi protsess toimib, tuleb suure tõenäosusega kogu asi mingil hetkel ümber teha. Ümbertegemine on hoopis keerukam ja mahukam, kui skriptide optimeerimine või refaktoorimine. Tehtud töö minemaviskamine ja otsast alustamine tähendab, et automatiseerida üritati enne, kui automatiseeritavast protsessist täielikult aru saadi.

Veel üks ohukoht on lubada oma projektil muutuda automatiseerimise “katsepolügooniks” ülejäänud ettevõtte jaoks. Kui ettevõttes pole juba väljakujunenud metoodikat ja infrastruktuuri projektides arendusprotsesside automatiseerimiseks, tuleks piirduda konkreetses projektis vajalikuga. Meeskond, kelle eesmärk on luua toimivat tarkvara, ei saa olla vastutav ettevõtte-ülese strateegia ja tööriistade arendamise eest. Selliste ülesannete lahendamiseks on sobivaim panna kokku eraldi meeskond, kelle ainsaks tööülesandeks saabki automatiseerimise infrastruktuuri väljatöötamine. Kui see töö on tehtud, on ka lihtsam otsustada, millal automatiseerida ja kuidas seda teha väiksemate kuludega.

 

Takistused

  • Kliendipoolne surve. Kui tahetakse saavutada käegakatsutavaid tulemusi varakult ja kiiresti edasi liikuda, lükatakse kõrvale või jäävad märkamata lahendused, mis tol hetkel ei tundu töötava koodi võimalikult kiiresti väljastamisele otseselt kaasa aitavat.
  • Nõuetekeskne fookus. Soovides näidata kohest ja kiiret arengut, hakkab meeskond võimalikult kiiresti looma koodi ja teste, mida saab ka reaalselt demonstreerida. See tundub palju huvitavam, kui protsesside automatiseerimiseks skriptide koostamine.
  • Juhtkonnapoolne toetus on nõrk või puudub. Juhtkonnal ei pruugi olla arusaama sellest, mis on automatiseerimine – kuidas see toimib ja mis on sellega seotud kulutused ja sellest saadav kasu.
  • Infrastruktuur on puudulik. Puudub ettevõtte-ülene lähenemine või infrastruktuur arenduse automatiseerimisele (standardid, töövahendid, kogemused jne).
  • Puudub järjepidevus. Isegi kui projekti alustatakse sooviga kõikvõimalikud protsessid automatiseerida, kipub kaduma järjepidevus selliste asjadega tegelemisel.

Nagu igasuguse põhimõttelise muutuse puhul, peab ka automatiseerimise juurutamise protsessi juures olema keegi, kes on ühtlasi nii pühendunud kui ka omab autoriteeti tagamaks, et arendusmeeskonnad vastuvõetud plaane järgivad. Automatiseerimise käigus on võimalik avastada ja lahendada ka muid potentsiaalseid probleeme, seetõttu võib automatiseerimise poole projekti pealt unarusse jätmine olla isegi halvem, kui olukord, kus automatiseerimise võimalusi üldse ei uuritagi. Mis aga on veel olulisem, kui automatiseerimise plaanid ei teostu järjepidevuse puudumise tõttu ja järgmises projektis automatiseerimise võimalusi kaalutakse, viidatakse tõenäoliselt eelmisele projektile – “aga see ju ei toiminud”.

 

Baby steps

Nagu iga asjaga, nii tuleks ka automatiseerimisega alustada algusest ja tasapisi. Kui meeskonnas pole just mitmel inimesel korralikku kogemust arendusprotsesside automatiseerimisel, ei tasu proovida korraga liiga palju ette võtta. Kuna ootused ja ka eesmärgid on seatud kõrged, siis katse üritada kogenematu meeskonnaga kõike võimalikku automatiseerida kukub üsna tõenäoliselt läbi. Alustada tasuks ühest-kahest asjast, mille puhul on ette näha, et nende automatiseerimise ebaõnnestumise risk on madal ning saadav kasu kõrge, ja sealt edasi liikuda.

Parem võtta ette vähem ja õnnestuda, kui teha suuri plaane ja põleda.

 

Kokkuvõte

Niipalju, kui on erinevaid projekte, on ka võimalusi nendes automatiseerimise rakendamiseks. On vaja kogemusi, pühendunud meeskonda, pädevat strateegiat, toimivat infrastruktuuri. Tihti tuleb teha kompromisse. Ja otse loomulikult on selleks kõigeks vaja piisavalt aega.

Kui automatiseerimine oleks lihtne, ei oleks vaja sellest ka nii palju kirjutada – kõik juba teaksid, mida teha, ja tegeleksid sellega.

2 thoughts on “Automatiseerimisest tarkvaraarenduses”

  1. Sa oled jätnud defineerimata kõige olulisema – misasi on see automatiseerimine, millest sa räägid?

    Sa tõid välja, et unit-testimise võiks automatiseerida – mida sa täpsemalt silmas pead? Ma väga hästi ei kujuta ette, kuidas keegi mitte-automatiseeritud unit-testi teeb – selle jaoks, tahad või mitte, on vaja kirjutada koodi, mida saab jooksutada. Pead sa silmas seda, et unit-test automaatselt genereeritakse või seda, et unit-testi jooksutamine peaks olema masina poolt algatatud? Ka build on enamasti automaatne (vähemalt osaliselt) – selle jaoks on olemas makefile, IDE projektifail vm. skript. Seda, et keegi buildi käsitsi teeb, on väga harva näha. Jälle sama küsimus kas see build’i automatiseerimine on build’i algatamine masina poolt?

  2. Nii automaatse buildimise kui ka unit-testimise all pidasin tõepoolest silmas pigem masina poolt algatatud tegevust – näiteks trigerdab neid koodi commit reposse või tehakse ühte või teist tegevust mingi scheduleri alusel vms. Unit testide puhul saaks kindlasti vähemalt osaliselt neid ka automaatselt genereerida, mis samamoodi võiks kvalifitseeruda nende automatiseerimiseks.

    Käsitsi buildimist võib veel kohata (harva küll), aga manuaalne unit-testimine tundub endale ka pisut kummaline, selles suhtes ei olnud sõnastus võibolla kõige parem.

    Aga mis see automatiseerimine siis on? Hästi lühidalt defineeriks automatiseerimist kui misiganes korduvate tegevuste vormistamist masina poolt jooksutatavaks (võimalusel ka algatatavaks).

    Minu mätta otsast muidugi paistab rohkem kätte automaattestimine, kuid nende kahe mõiste vahele võrdusmärki panna ei saa. Automatiseerida saab põhimõtteliselt ju mida iganes – andmete genereerimist testiks, keskkondade seadistamist, koodi buildimist mõne trigeri alusel jne.

Leave a Reply

Your email address will not be published. Required fields are marked *