Jatkuva integraatio

Jatkuvan integraation hyödyt korostuvat suurissa projekteissa

Suuressa ohjelmistoprojektissa työskennelleet ovat todennäköisesti huomanneet, miten vaikeaa on saada kaikki ohjelmiston osat toimimaan moitteettomasti yhteen, kun ohjelmiston uuden version julkaisu lähestyy. Kaikki eri osiin tehdyt muutokset pitäisi saada toimimaan saumattomasti, ja julkaisuun liittyvät yksityiskohdat pitäisi saada kuntoon. Usein tähän kuluu enemmän aikaa kuin alun perin on suunniteltu, jolloin projektin loppumetreillä tulee kova kiire tai julkaisu viivästyy.

Jatkuvan integraation (Continuous Integration) perusajatuksena on integroida ohjelmistoon tehdyt muutokset kehitettävään kokonaisuuteen mahdollisimman aikaisessa vaiheessa. Kokemuksemme mukaan suurin hyöty jatkuvasta integroinnista saavutetaan suurissa ohjelmistoprojekteissa. Kuitenkin nimenomaan suurissa projekteissa uskotaan usein, että jatkuva integraatio ei sovellu tämän kokoluokan projekteihin tai että se on liian hankalaa ja työlästä suhteessa hyötyihin.

Seuraavassa käydään läpi eräs käytännön esimerkki jatkuvasta integraatiosta. Tarkoituksena on valottaa jatkuvan integraation merkitystä suuressa projektissa ja antaa joitain käytännön vinkkejä, miten siitä saadaan suurin hyöty irti.

Case: suuri kansainvälinen ohjelmistoprojekti

Esimerkkitapauksessa kyseessä on suuren, kansainvälisen yrityksen ohjelmistotuote, joka käyttöönotettaessa asennetaan asiakkaan omaan ympäristöön ja asiakas hoitaa ylläpidon itse. Tuotteen eri versiot ovat koko ajan aktiivisessa ja kriittisessä käytössä ympäri maailmaa. Tuotteella on takanaan pitkä historia, mutta se on uusi sukupolvi entisestä versiosta. Käytännössä tämä tarkoittaa, että suuria osia ohjelmistosta on kirjoitettu uudelleen, mutta se sisältää myös paljon vanhaa koodia. Sekä uutta että vanhaa koodia on miljoonia rivejä, ja käytössä on monia eri ohjelmointikieliä ja teknologioita. Ohjelmistokehittäjiä on satoja, ja kehitystiimit sijaitsevat useassa eri maassa.

Lähtötilanne oli se, että tuotteella oli ”daily build”, eli tuotteesta rakennettiin kerran päivässä uusi versio ja testattiin se. Mikäli kaikki meni suunnitellusti, tähän kului kahdeksan tuntia. Kehittäjät työskentelivät usein pitkään omissa kehityshaaroissaan, ennen kuin julkaisivat muutoksensa. Koska muutoksia tuli kokonaisuudessaan paljon ja ne oli usein tehty vanhan version pohjalle, integraatio-ongelmia oli runsaasti.

Koska ongelmien huomaaminen meni lähes aina vähintään seuraavaan työpäivään, oli niiden korjaaminen hidasta. Tästä seurasi tilanne, että ”daily build” raportoi tuotteen olevan koko ajan enemmän tai vähemmän rikki. Nämä raportit eivät juuri kiinnostaneet kehittäjiä. He halusivat keskittyä tekemäänsä muutokseen, eivät sen vaikutuksiin muualle. Myös tuotteen hallinta oli vaikeaa: oli hankalaa hahmottaa, kuinka kaukana julkaisukelpoisesta tuote oli ja kuinka kauan ongelmien korjaaminen kestäisi.

Oikeat työkalut tukemaan jatkuvaa integraatiota

Näiden ongelmien seurauksena projektissa tehtiin päätös panostaa jatkuvaan integraatioon. Ensin vaihdettiin työkalut jatkuvaa integraatiota paremmin tukeviin. Versionhallinta vaihdettiin ClearCasesta Subversioniin, ja tuotteen uuden koodin rakennustyökalu (build tool) vaihdettiin Antista Maveniin.

Vanha versionhallinta tuki työtapaa, jossa kehittäjät tekevät työtään välittämättä muiden tekemistä muutoksista. Uusi versionhallinta pakotti huomioimaan muiden tekemät muutokset. Samalla tehtiin päätös, että erilaisten kehitysaikaisten haarojen määrä minimoidaan, ja kaikki kehittäjät pyrkivät yhdessä kehittämään yhteistä haaraa, tuotteen viimeisintä versiota.

Aiempi ohjelmiston rakennustyökalu (Ant) tuki työtapaa, jossa kaikki tuotteen rakentamiseen liittyvä logiikka piti kirjoittaa itse. Lisäksi kaikenlaiset riippuvuudet tuotteen muihin osiin ja ulkopuolelle piti hallita käsin. Suuressa ohjelmistossa tällaista rakennuslogiikkaa kertyy ajan mittaan paljon. Lisäksi ohjelmiston sisäisten riippuvuuksien hallinnointi manuaalisesti on hankalaa, kun muutoksia tehdään paljon. Uusi rakennustyökalu (Maven) hoiti automaattisesti riippuvuuksien hallinnan ja sisälsi runsaasti valmista rakennuslogiikkaa. Käyttäjän harteille jäi ainoastaan työkalun konfigurointi. Työkalun muuttaminen vähensi tuotteen rakennusohjeiden määrää huomattavasti ja teki rakennusohjeista helpommin ymmärrettäviä jokaiselle, joka tunsi uutta työkalua.

Työkalujen vaihto oli mittava operaatio. Operaatio paljasti paljon ongelmia vanhassa mallissa ja pakotti ratkaisemaan ne. Lisäksi uusien työkalujen opettelu vei aikansa ja vaati uudenlaista ajattelua. Jälkeenpäin lähes kaikki kehittäjät ovat olleet sitä mieltä, että uudet työkalut ovat paremmat kuin vanhat.

Työkalujen vaihdon yhteydessä toteutettiin ”daily buildin” korvaava, uusille työkaluille perustuva automaattinen ohjelmiston osien integraatio. Tässä muutokset laukaisivat tuotteen uuden version rakentamisen, asentamisen ja testaamisen. Käytössä oli sekä rakentamisen aikaan ajettavia automaattisia yksikkötestejä, että asennuksen jälkeen ajettavia automaattisia hyväksymistestejä. Tilanne parani aiemmasta, mutta silti jatkuva integraatio raportoi tuotteen testien olevan rikki koko ajan ja testituloksia piti odottaa liian kauan.

Parempaa laatua, työmotivaatiota ja tuloksia

Ongelmia ryhdyttiin ratkomaan tärkeysjärjestyksessä. Tulosten saantia pyrittiin nopeuttamaan yksinkertaistuksilla, optimoinneilla, rinnakkaistuksilla ja paremmilla koneilla. Mitä luotettavammaksi ja nopeammaksi jatkuva integraatio saatiin, sitä suuremmat olivat hyödyt. Buildi pysyi vihreänä yhä pitemmän aikaa, ja kehittäjät kiinnostuivat sen tuloksista. Työmotivaatio kasvoi, ja tuotteen ongelmat korjattiin nopeammin kuin aiemmin. Kehitystiimien välinen kommunikaatio lisääntyi. Tuotteen ja projektin hallinnoinnista vastaavat ihmiset olivat tyytyväisiä, kun he saivat lähes reaaliaikaista tietoa tuotteen tilasta. Tuotteen laatu parani jatkuvan integraation tulosten mukana.

Kun alkuperäisen daily buildin kahdeksan tuntia oli lyhentynyt puoleentoista tuntiin ja uusia tuloksia saatiin täysin automaattisesti 35 minuutin välein, ryhdyttiin tuotteen jatkuvasta integraatiosta puhumaan yrityksen sisäisenä menestystarinana. Vastaavanlainen jatkuva integraatio haluttiin ottaa käyttöön myös muissa yrityksen suurissa ohjelmistoprojekteissa.

Hyödyt merkittäviä yksinkertaisellakin toteutuksella

Perinteisessä jatkuvassa integroinnissa lähdekoodiin tehty muutos laukaisee uuden version rakentamisen. Rakentaminen sisältää usein yksikkötestejä. Kehitystiimin työtilassa on monitori, joka näyttää, ovatko kaikki testit menneet läpi vai eivät. Näin yksinkertainen malli ei kuitenkaan skaalaudu, jos uuden version tekemiseen kuluu paljon aikaa ja muutoksia tulee samaan aikaan runsaasti.

Yllä mainitussa esimerkissä jatkuva integraatio oli laaja systeemi, jossa tuotteen eri osien muuttaminen laukaisi tiettyjen osien uudelleenrakentamisen. Taustalla pyöri kaikkia osia yhdistävä prosessi, jonka tuottama uusi versio asennettiin automaattisesti testipalvelimille, joilla sitä testattiin. Lisäksi joitain versioita testattiin vielä asentamalla ne eri ympäristöihin ja ajamalla näille laajempia testejä. Koko systeemi tuotti paljon erilaisia raportteja ja näkymiä ja keräsi kiinnostavaa dataa prosessin aikana.

Jatkuvan integraation voi toteuttaa siis myös isossa skaalassa. Tämä ei tarkoita, että suuren ohjelmistotuotteen jatkuvan integraation toteutuksen tulisi aina olla suuri. Hyvin yksinkertaisellakin toteutuksella saavutetaan merkittäviä hyötyjä, kunhan se on riittävän luotettava ja nopea. Edellä mainittu jatkuva integraatio on lähtenyt yksinkertaisesta toteutuksesta, jota on pikkuhiljaa parannettu käytöstä saadun palautteen pohjalta.

Laadukkaampi lopputulos nopeammin

Jatkuva integraatio parantaa kehittäjien kommunikaatiota ja yhteishenkeä, tuo tuotteen ongelmat näkyviksi, nopeuttaa virheiden korjaamista ja parantaa tuotteen laatua. Samalla on pakko automatisoida mahdollisimman paljon uuden version julkaisemiseen ja testaamiseen liittyviä työvaiheita.

Oma kokemukseni on, että nopea ja luotettava jatkuva integraatio on äärimmäisen hyödyllinen suurissa ohjelmistoprojekteissa. Jatkuvan integroinnin käyttöönotto voi olla työlästä, mutta tämä vaiva kannattaa nähdä ja tehdä se pienin askelin keskittyen aina tärkeimpään ongelmakohtaan. Pienilläkin parannuksilla voi olla suuri merkitys. Jos automaation määrä kasvaa ja kehittäjät pitävät kunnia-asiana, että kaikkien tuotteen testien on mentävä läpi, on vaikutus koko tuotteen kehitykselle valtava. Jatkuvaan integraatioon panostaminen maksaa itsensä helposti takaisin, kun kehitys ja tuotteen hallinnointi helpottuu ja julkaisuvaihe nopeutuu.

Samuli Siivonen, ohjelmistoarkkitehti

Samuli on kokenut ohjelmistoarkkitehti, joka viihtyy haastavissa toteutustehtävissä. Viime vuosina hän on työskennellyt tiiviisti laajojen ohjelmistoprojektien ja niiden kehitysympäristöjen parissa.