LAURI KORISEVAJATKUVAN TOIMITUKSEN KÄYTTÖÖNOTTOOHJELMISTOPROJEKTISSADiplomityö

Tarkastaja: Prof. Hannu-Matti Järvi-nen

Tarkastaja ja aihe hyväksytty 1. lo-kakuuta 2018

i

TIIVISTELMÄ

LAURI KORISEVA: Jatkuvan toimituksen käyttöönotto ohjelmistoprojektissaTampereen teknillinen yliopistoDiplomityö, 50 sivua, 2 liitesivuaMarraskuu 2018Tietotekniikan koulutusohjelmaPääaine: OhjelmistotuotantoTarkastaja: Prof. Hannu-Matti Järvinen

Avainsanat: jatkuva toimitus, Jenkins, testausautomaatio

Ohjelmistokehittäjillä on yleinen tarve julkaista kehittämäänsä ohjelmakoodia nopeastija turvallisesti loppukäyttäjien saataville. Monet ohjelmistoalan yritykset julkaisevat oh-jelmistotuotteita ja -palveluita perinteisen toimitusprosessin mukaisesti, mutta se sisältäälukuisia käytännöllisiä ongelmia. Jatkuva toimitus ratkaisee kyseiset ongelmat automati-soimalla julkaisua edeltävät toimenpiteet.

Tämän työn tavoitteena oli tutkia erilaisia jatkuvan toimituksen työkaluja ja toteuttaa va-litulla työkalulla automatisoitu liukuhihna yrityksen ohjelmistoprojektille. Jatkuvaa toi-mitusta varten pystytettiin virtuaalikoneympäristö, johon toteutettiin sekä käännös- ettädemoympäristö. Valittua työkalua käyttämällä toteutettiin liukuhihna, joka suorittaa oh-jelmakoodin päivittämisen, kääntämisen, tuottamisen sekä hyväksymistestauksen.

Toteutettu liukuhihna suorittaa määritellyt vaiheet säännöllisesti ongelmitta, ja se tarjo-aa hyväksymistesteistä saatavia tuloksia. Liukuhihnaa on alettu hyödyntämään aktiivi-sesti kohdeprojektin kääntämisessä ja testauksessa. Liukuhihnaa on tarkoitus hyödyntäätulevissa julkaisuissa, mutta sitä ennen hyväksymistestausta täytyy kehittää ja tuotteestapitäisi jakaa vastuuta tasapuolisemmin koko projektitiimin kesken.

ii

ABSTRACT

LAURI KORISEVA: Applying continuous delivery to a software projectTampere University of TechnologyMaster of Science Thesis, 50 pages, 2 Appendix pagesNovember 2018Master’s Degree Programme in Information TechnologyMajor: Software EngineeringExaminer: Prof. Hannu-Matti Järvinen

Keywords: continuous delivery, Jenkins, test automation

Releasing code quickly and safely to the end users is a common problem faced by soft-ware developers. Many information technology companies apply the traditional deliveryprocess in releasing software products and services despite the process containing mul-tiple practical problems. Continuous delivery solves such problems by automating taskspreceding the release.

The goal of this thesis was to examine different tools for continuous delivery and to im-plement an automated pipeline in a company’s software project by utilizing the chosentool. A virtual machine environment containing environments for building and stagingwas built for the continuous delivery. By utilizing the chosen tool, a pipeline was imple-mented that updates, builds, deploys and applies acceptance testing to the code.

The implemented pipeline performs the specified steps flawlessly and provides resultsfrom the acceptance tests. The pipeline is now actively used in building and testing thetarget project. The pipeline will be utilized in the upcoming releases of the application.Nevertheless, the acceptance testing needs to be improved, and the responsibility for theproduct should be shared more evenly among the project team.

iii

ALKUSANAT

Kiitän Atostek Oy:ta, joka tarjosi tälle työlle aiheen ja rahoituksen. Sen lisäksi kiitänAtostek Oy:ta sen tarjoamasta runsaasta ajasta työn toteuttamiselle ja kirjoittamiselle.

Kiitän sekä työni tarkastajaa Hannu-Matti Järvistä että ohjaajaa Matti Helmistä ohjaami-sesta ja tukemisesta työn saralla. Kiitän myös Atostek Oy:n ylläpitotiimiä ja automaatti-testien tekijöitä auttavaisuudesta ympäristön pystyttämisessä. Lisäksi kiitän muita työto-vereitani heidän luomastaan kannustavasta ja rennosta työilmapiiristä.

Tampereella, 19.11.2018

Lauri Koriseva

iv

SISÄLLYSLUETTELO

1. JOHDANTO .......................................................................................................... 1

2. JATKUVA TOIMITUS .......................................................................................... 32.1 Perinteinen toimitusprosessi ....................................................................... 42.2 Läheiset menetelmät ................................................................................... 6

2.2.1 Jatkuva integraatio ........................................................................ 62.2.2 Jatkuva käyttöönotto ..................................................................... 8

2.3 DevOps........................................................................................................ 82.4 Liukuhihna .................................................................................................. 92.5 Ympäristöt................................................................................................... 102.6 Virtualisointi ja kontitus.............................................................................. 122.7 Testaus......................................................................................................... 14

3. JATKUVAN TOIMITUKSEN TYÖKALUT ........................................................ 173.1 Jenkins......................................................................................................... 18

3.1.1 Pääpalvelin ja agentit .................................................................... 193.1.2 Tehtävät......................................................................................... 213.1.3 Liukuhihnat................................................................................... 21

3.2 Travis CI...................................................................................................... 223.3 CircleCI....................................................................................................... 233.4 Codeship ..................................................................................................... 24

4. JATKUVA TOIMITUS ERASSA.......................................................................... 254.1 eRAn kehittäminen ..................................................................................... 254.2 Työkaluratkaisu........................................................................................... 264.3 Ympäristö.................................................................................................... 27

4.3.1 eRAPublish ................................................................................... 294.3.2 eRABuild ...................................................................................... 304.3.3 eRAServer..................................................................................... 304.3.4 eRATest......................................................................................... 31

4.4 Liukuhihnan suoritus .................................................................................. 324.4.1 Päivittäminen, kääntäminen ja tuottaminen demoympäristöön.... 344.4.2 Tietokantojen tyhjentäminen ........................................................ 354.4.3 Demoympäristön alustus .............................................................. 364.4.4 Käyttöliittymätestaus .................................................................... 364.4.5 Rajapintatestaus ............................................................................ 37

5. ARVIOINTI JA JATKOKEHITYS........................................................................ 405.1 Tulokset....................................................................................................... 405.2 Jatkokehitys................................................................................................. 42

6. YHTEENVETO..................................................................................................... 44

LÄHTEET...................................................................................................................... 46

v

LIITE A: MASTER-LIUKUHIHNA............................................................................. 51

LIITE B: ERA-LIUKUHIHNA ..................................................................................... 52

vi

KUVALUETTELO

Kuva 2.1. Jatkuvan toimituksen kulku [53]. ........................................................... 4Kuva 2.2. Perinteisen toimitusprosessin julkaisukierto [32]. ................................. 5Kuva 2.3. Jatkuvan integraation, toimituksen sekä käyttöönoton välinen suhde

[40]......................................................................................................... 6Kuva 2.4. Osa-alueiden välinen suhde DevOps-kulttuurissa [32]. ........................ 9Kuva 2.5. Jatkuvan toimituksen liukuhihnan suoritus [14]. ................................... 10Kuva 2.6. Sekventiaalisen ja rinnakkaisen liukuhihnan ajankäytön vertailu, jos-

sa kuviot edustavat tehtäviä [7]. ............................................................ 11Kuva 2.7. Jatkuvassa toimituksessa usein käytettävät ympäristöt kehittämisel-

le, testaamiselle ja tuotannolle............................................................... 12Kuva 2.8. Konttien ja virtuaalikoneiden välinen ero [18]. ..................................... 13Kuva 2.9. Testaustapoja, joita voidaan hyödyntää jatkuvassa toimituksessa [32]. 15Kuva 2.10. Testausmenetelmien painoarvot pyramidissa esitettynä [15]. ............... 16Kuva 3.1. Esimerkkikuva Jenkinsin käyttöliittymästä............................................. 19Kuva 3.2. Pääpalvelimen ja agenttien välinen vuorovaikutus [32]........................ 20Kuva 4.1. Tietojärjestelmän liittäminen Kanta-palveluihin eRAn välityksellä [5]. 25Kuva 4.2. Jatkuvan toimituksen ympäristö eRAssa. ............................................... 28Kuva 4.3. Liukuhihnojen suoritus eRAn toimituksessa........................................... 33

vii

OHJELMALUETTELO

Ohjelma 3.1. Deklaratiivinen liukuhihna, joka tervehtii käyttäjää.............................. 22Ohjelma 4.1. Esimerkki Robot Frameworkin testitiedostosta, jolla tutkitaan sisään-

kirjautumista. ......................................................................................... 37Ohjelma 4.2. Esimerkki rajapintatestitiedostosta, jolla testataan työkalun ja eRAn

välistä yhteyttä........................................................................................ 38Ohjelma A.1. Master-liukuhihnan toteutus. ................................................................. 51Ohjelma B.1. eRA-liukuhihnan toteutus. ...................................................................... 52

viii

LYHENTEET JA MERKINNÄT

ASP.NET Avoimeen lähdekoodiin perustuva viitekehys web-sovelluksilleATDD Acceptance test–driven development, suom. hyväksymistestivetoinen

ohjelmistokehitysC# Microsoftin kehittämä oliopohjainen ohjelmointikieliCD Continuous Delivery (suom. jatkuva toimitus), jatkuviin julkaisuihin

perustuva ohjelmistokehitysmenetelmäCI Continuous Integration (suom. jatkuva integraatio), jatkuviin integraa-

tioihin perustuva ohjelmistokehitysmenetelmäDevOps Development and Operations, suom. kehitys ja toimenpiteeteRA e-ReseptiArkisto, Atostekin kehittämä pilvipalvelu, joka tarjoaa raja-

pinnan Kelan Kanta-palveluihinGUI Graphical User Interface, suom. graafinen käyttöliittymäHTTP Hypertext Transfer Protocol, tiedonsiirtoprotokollaHTTPS Hypertext Transfer Protocol Secure, HTTP:n laajennos, jossa kommu-

nikaatio salataanIP Internet Protocol, Internet-kerroksen protokollaJava Tulkattava oliopohjainen ohjelmointikieliIDE Integrated Development Environment, suom. integroitu ohjelmoin-

tiympäristöIIS Internet Information Services, Microsoftin kehittämä palvelinohjel-

mistokokonaisuus web-sovelluksilleJenkins Avoimeen lähdekoodiin perustuva automatisointityökaluMVC Model-view-controller, mallin, näkymän ja käsittelijän eriyttämiseen

perustuva ohjelmistoarkkitehtuurimalliPython Korkean tason tulkattava ohjelmointikieliQA Quality Assurance, suom. laadunvarmistusRDP Remote Desktop Protocol (suom. etätyöpöytäyhteys), Windows-

käyttöjärjestelmien välinen yhteyskäytäntöSaaS Software as a Service, suom. ohjelmiston hankkiminen palvelunaSVN Subversion, suosittu versionhallintajärjestelmäSQL Structured Query LanguageTCP Transmission Control Protocol, tietoliikenneprotokollaVM Virtual Machine (suom. virtuaalikone), tietokonetta emuloiva ohjelmaXML Extensible Markup Language, rakenteellinen kuvauskieli

1

1. JOHDANTO

Ohjelmakoodin julkaiseminen nopeasti ja turvallisesti on yleinen ongelma, jonka oh-jelmistokehittäjät kohtaavat ohjelmistoprojekteissa. Useimmissa projekteissa sovelletaanperinteistä toimitusprosessia, jossa ohjelmiston toimittaminen jaetaan kehittämis-, laadun-varmistus- sekä julkaisuvaiheiseen. Perinteinen toimitusprosessi sisältää kuitenkin lukui-sia heikkouksia ja sen soveltaminen johtaa usein tyytymättömyyten niin kehittäjien kuinasiakkaidenkin osalta. [32]

Jatkuva toimitus ratkaisee perinteisessä toimitusprosessissa esiintyvät ongelmat tarjoa-malla automatisointia. Ketterien menetelmien tutkija Jez Humble on esittänyt tarkan mää-ritelmän jatkuvalle toimitukselle: "Jatkuva toimitus on kyky viedä kaikentyyppisiä muu-toksia, kuten uusia ominaisuuksia, konfiguraatiomuutoksia, ohjelmointivirheiden (bug)korjaamisia ja kokeiluja, tuotantoon tai suoraan loppukäyttäjlle turvallisesti, nopeasti se-kä kestävästi [32]". Jatkuvan toimituksen avulla ohjelmistotuotteista voidaan tuottaa laa-dukkaampia hyödyntäen säännöllisiä ja tehokkaita julkaisuja.

Työn tavoitteena on ottaa jatkuva toimitus käyttöön ohjelmistoprojektissa, jossa on tois-taiseksi noudatettu perinteistä toimitusprosessia. Tavoitteen saavuttamiseksi työssä pereh-dytään tarkemmin ketteriin menetelmiin, työkaluihin sekä eri tapoihin pystyttää ympäris-tö toimitukselle. Sen jälkeen projektille valitaan parhaiten soveltuva jatkuvan toimituksentyökalu ja projektille pystytetään erillinen ympäristö, jossa jatkuva toimitus suoritetaantoteutettavan liukuhihnan avulla ja suorituksesta saadaan palautetta testaustulosten muo-dossa. Täten tulevat julkaisut voidaan suorittaa liukuhihnan tarjoaman palautteen perus-teella.

Luvussa 2 tarkastellaan perinteistä toimitusprosessia ja kartoitetaan sen heikkoudet jat-kuvaan toimitukseen verrattuna. Jatkuvan toimituksen käsitettä avataan yksityiskohtai-semmin ja sitä vertaillaan muihin samankaltaisiin menetelmiin. Lisäksi luvussa kerrotaanliukuhihnan toiminnasta, ympäristöjen eriyttämisestä ja niiden tehtävistä sekä eri testaus-menetelmien soveltamisesta.

Luvussa 3 esitetään potentiaalisia työkaluratkaisuja, joita voidaan hyödyntää jatkuvassatoimituksessa. Tarkastelun kohteena on vain muutama suosittu vaihtoehto, koska jatkuvantoimituksen työkaluja on lähes rajattomasti saatavilla.

Luvussa 4 esitetään eRA-palvelu, jonka ympärille työssä rakennetaan jatkuvan toimituk-sen ympäristö. eRA on Atostek Oy:n kehittämä web-palvelu, jota käytetään pääasias-sa sosiaali- ja terveydenhuollon toimintayksiköiden liittymiseen Kelan tarjoamiin Kanta-palveluihin. Luvussa valitaan perustellusti sopivat työkalut ja menetelmät jatkuvan toi-mituksen toteuttamiselle. Ympäristö suunnitellaan ja toteutetaan palvelulle soveltuvaksi.

2

Lisäksi jatkuvan toimituksen suorittavan liukuhihnan rakenne kuvataan yksityiskohtaises-ti.

Luvussa 5 esitetään tulokset, jotka saatiin, kun liukuhihnalla olevat tehtävät suoritettiin.Hyväksymistestauksesta saatavat tulokset arvioidaan tuotteen julkaisun kannalta. Lisäk-si luvussa arvioidaan jatkokehitystarpeita sekä jatkuvalle toimitukselle että yksittäistentehtävien automatisoinnille yrityksen ohjelmistoprojekteissa.

3

2. JATKUVA TOIMITUS

Jatkuva toimitus (Continuous Delivery, CD) on perinteisen määritelmän mukaan ohjel-mistotuotannon menetelmä. Se on käsitteenä muilta osin hieman hämmentävä ja sen mer-kitys on kiistanalainen. Sen käsite sisältää kokonaisuudessaan jatkuvan integraation (Con-tinuous Integration, CI) yhdistettynä sekä kääntämisautomaatioon että konfiguraatiohal-lintaan. Yritykset käyttävät jatkuvaa toimitusta ja sen työkaluja päivittäessään sovelluksiaja ohjelmistotuotteita luodakseen saumattoman käyttäjäkokemuksen. [6]

Jatkuvan toimituksen toiminta perustuu testitapausten, hyväksymisien ja julkaisujen ym-pärille. Toimitus jakaantuu useaan eri vaiheeseen kuvan 2.1 mukaisesti. Ohjelmakoodinkääntäminen voidaan suorittaa jokaisen kehityksestä johtuneen muutoksen yhteydessä,jonka jälkeen suoritetaan automatisoitua testausta. Testien tulokset palautetaan kehitystii-mille, joka puolestaan voi julkaista käännöksen tuotantoon. Muutokset voidaan julkaistaautomaattisesti hyödyntäen jatkuvaa käyttöönottoa (continuous deployment), mutta muu-tokset voidaan myös julkaista manuaalisesti, mikä on tavanomaista jatkuvassa toimituk-sessa. [6]

Jatkuvan toimituksen avulla muutokset ohjelmistossa voidaan toimittaa tuotantoon taisuoraan loppukäyttäjille nopeasti ja turvallisesti. Muutokset voivat olla esimerkiksi uusiaominaisuuksia, konfiguraatiomuutoksia, ohjelmointivirheiden korjauksia tai kokeiluja. Sentavoitteena on muodostaa toimituksesta rutiininomainen toimenpide, joka voidaan suorit-taa aina tarpeen mukaan. Toimituksia voidaan suorittaa muun muassa laajan mittakaavanhajautetuissa järjestelmissä, monimutkaisissa tuotantoympäristöissä ja sulautetuissa jär-jestelmissä. Ohjelmakoodi on aina valmiina toimitukseen, vaikka useat kehittäjät muok-kaisivatkin sitä säännöllisesti. Perinteisessä ohjelmistotoimituksessa koodi-integraatiot,testaamiset ja ohjelmointivirheiden korjaamiset saattavat viedä viikkoja tai jopa kuu-kausia. Kun tiimit työskentelevät yhdessä automatisoidakseen kääntämisen, tuottamisenja testaamisen, kehittäjät voivat sisällyttää integraation ja testaamisen päivittäiseen työs-kentelyynsä. Täten voidaan myös vältellä suurta määrää toisteista työtä. [49]

Jatkuvan toimituksen ansiosta ohjelmistokehitystiimeille jää enemmän aikaa keskittyäkäyttäjätutkimukseen ja korkeamman tason testamiseen, kuten tutkivaan testaamiseen,käytettävyystestaamiseen, kuormitustestaamiseen ja turvallisuustestaamiseen. Kyseisiätoimenpiteitä voidaan suorittaa jatkuvasti toimituksen aikana rakentamalla sille liukuhih-na (pipeline). Täten tuotteista ja palveluista voidaan kehittää laadukkaita alusta alkaen.Menestyksekkäillä ohjelmistotuotteilla ja -palveluilla on tapana kehittyä huomattavastielinaikanaan. Panostamalla kääntämiseen, testaamiseen, tuottamiseen ja ympäristön au-tomaatioon voidaan merkittävästi leikata kuluja, jotka menevät ohjelmiston muutoksiinja toimituksiin. Myös monia julkaisuun liittyviä menoja pystytään täten vähentämään.

4

Kuva 2.1. Jatkuvan toimituksen kulku [53].

Julkaisemalla tiheämpään tahtiin tiimit voivat olla aktiivisemmin asiakkaiden kanssa te-kemisissä, havaita toimivat ratkaisut ja nähdä suoralta kädeltä työnsä lopputulokset. [49]

Verrattuna perinteiseen toimitusprosessiin, jatkuvassa toimituksessa ohjelmisto voidaantoimittaa pienemmällä määrällä ohjelmointivirheitä ja matalammalla riskillä. Kun jul-kaistaan pieniä muutoksia tiheään tahtiin, virheitä voidaan havaita jo kehitysvaiheessa.Kun automatisoitua testaamista hyödynnetään jokaisella kehityksen tasolla, koodi ei ete-ne myöhempiin vaiheisiin testien epäonnistuessa. Lisäksi pienien muutosten palauttami-nen edeltävään tilaan on helppoa. Uusia ominaisuuksia saadaan julkaistua tiheämpääntahtiin kaupalliseen käyttöön, jolloin myös palautetta saadaan tiheämpään tahtiin, jostavoidaan ottaa opiksi seuraavia iteraatioita ajatellen. Asiakkaiden värvääminen kehitys-kumppaneiksi antaa heille osaomistajuuden ja uskollisuuden tunteen, ja kaupallisiin vaa-timuksiin pystytään vastaamaan nopeammin. Jatkuvan toimituksen ansiosta vastuu leviäälaajasti, jolloin yhteistyö on helpompaa. Se poistaa myös paljon paineita ohjelmiston jul-kaisuista. Pienien muutosten julkaisun ansiosta kaikki tottuvat säännölliseen julkaisutah-tiin, jolloin aikaa jää enemmän suunnittelemiseen ja kehittämiseen. [19]

2.1 Perinteinen toimitusprosessi

Perinteistä toimitusprosessia on nimensä mukaisesti hyödynnetty jo vuosia, ja suuri osaohjelmistoalan yrityksistä soveltaa sitä edelleenkin. Toimitusprosessit alkavat asiakkaanvaatimusmäärittelyillä ja päättyvät tuotteen julkaisuun. Kuvassa 2.2 on havainnollistet-tu perinteisen toimitusprosessin julkaisukierto. Julkaisukierto alkaa siitä, kun asiakastaedustava tuotteen omistaja (product owner) laatii vaatimukset toteutettavalle järjestelmäl-le. Sen jälkeen työ liikkuu kolmen eri vaiheen välillä, jotka ovat kehitys-, laadunvarmis-tus- (Quality Assurance, QA) sekä toimenpidevaihe. Kehitysvaiheessa ohjelmistokehittä-jät työstävät tuotetta. Kehittäjät käyttävät usein ketteriä tekniikoita sekä nopeuttaakseenkehitystä että parantaakseen kommunikointia asiakkaan kesken. Demotilaisuuksien pitä-

5

Kuva 2.2. Perinteisen toimitusprosessin julkaisukierto [32].

minen on yleinen tapa hankkia asiakkaalta palautetta nopeasti. Kun toteutus on valmis,koodi viedään laadunvarmistustiimille. Laadunvarmistusvaihe edellyttää pääkehityshaa-ran koodin jäädyttämistä, eli vaiheen aikana pääkehityshaaraan ei saa tehdä muutoksia.Täten varmistetaan, ettei laadunvarmistuksen aikana tapahtuva rinnakkainen kehittämi-nen johda testien rikkoutumiseen. Laadunvarmistajat suorittavat kaikenlaista testaamista,kuten integraatiotestausta, hyväksymistestausta sekä ei-toiminnallista testausta. Löydetytvirheet palaavat takaisin kehitystiimille korjattaviksi. Kun tuote on todettu tarpeeksi laa-dukkaaksi, laadunvarmistustiimi hyväksyy seuraavaan julkaisuun sisältyvät ominaisuu-det. Viimeisessä ja usein lyhyimmässä toimenpidevaiheessa suoritetaan julkaisu ja tuotan-non käyttäytymistä seurataan. Julkaisukierron pituus on usein viikon ja muutaman kuu-kauden välillä riippuen kehitettävästä järjestelmästä ja organisaatiosta. [32]

Perinteisellä toimitusprosessilla on lukuisia heikkouksia. Toimitus on hidasta, ja asiakasjoutuu odottamaan tuotetta kauan vaatimusten määrittelyn jälkeen, jolloin myös asiak-kaalta tulevan palautteen saaminen viivästyy. Palaute viivästyy myös yrityksen sisällä,koska laadunvarmistusvaiheessa voidaan löytää virheitä, jotka ilmaantuivat koodiin esi-merkiksi pari kuukautta aiemmin. Siten pienetkin virheet voivat viivästyttää julkaisuahuomattavasti. Harvoin tapahtuvat julkaisut eivät rohkaise hyödyntämään automaatiota,jolloin julkaisujen ajankohtia on vaikea ennustaa. Pikaiset korjaustarpeet eivät voi useinjäädä odottamaan koko laadunvarmistusvaiheen suoritusta, jolloin niitä täytyy testata eritavalla tai jättää kokonaan testaamatta. Lisäksi arvaamattomat julkaisut ovat stressaaviatoimihenkilöiden kannalta. Julkaisukierteet ovat myös usein tiukasti aikataulutettuja, mi-kä lisää kehittäjien ja testaajien stressiä. Työn välittäminen tiimiltä toiselle edustaa vesi-putousmallia, jossa työntekijät ovat todennäköisemmin kiinnostuneita vain omasta työ-osuudestaan koko tuotteesta vastaamisen sijaan. Ongelmatilanteet saattavat tällöin johtaatoisten syyttelyyn yhteistyön sijaan. Tiimit eivät ota kokonaisvaltaista vastuuta, vaan työn

6

Kuva 2.3. Jatkuvan integraation, toimituksen sekä käyttöönoton välinen suhde [40].

valmiuden määritelmät ovat vaihekohtaisia. Kehittäjät ottavat vastuun ainoastaan vaati-musten toteuttamisesta, laadunvarmistustiimi testaamisesta ja toimihenkilöt palvelun jul-kaisemisesta ja seurannasta. Työtyytyväisyys voi kärsiä, jos ei halua työskennellä kokoaikaa samalla osa-alueella, vaan esimerkiksi haluaa kehittää koodia testaamisen ohella.Kyseisten heikkouksien takia ohjelmistoyrityksillä on noussut tarve hyödyntää ketteriämenetelmiä, kuten esimerkiksi jatkuvaa toimitusta. [32]

2.2 Läheiset menetelmät

On olemassa kaksi menetelmää, jotka ovat keskeisiä jatkuvan toimituksen kannalta: jat-kuva integraatio sekä jatkuva käyttöönotto. Jokainen menetelmä pyrkii tekemään sekäohjelmistokehityksestä että ohjelmistojen julkaisemisesta tehokkaampaa [1]. Termien sa-mankaltaisten nimien johdosta niitä näkee usein käytettävän sekaisin keskenään.

Sekä jatkuvan toimituksen että jatkuvan käyttöönoton tarkat määritelmät jäävät usein vä-hälle huomiolle kirjallisuudessa ja teollisuuden piirissä. Jatkuva käyttöönotto perustuusiihen, että koodimuutokset julkaistaan automaattisesti tuotantoympäristöön ilman ma-nuaalista vuorovaikutusta. Jatkuvassa toimituksessa puolestaan ihminen tekee päätöksen,milloin tuotantoa varten valmis koodi julkaistaan tuotantoon. Kuvassa 2.3 on esitetty me-netelmien välinen suhde sekä sovelluksen tuottaminen eri ympäristöihin [40]. Jatkuvaintegraatio on osa kumpaakin menetelmää, jonka aikana sovellus käännetään ja yksikkö-testataan.

2.2.1 Jatkuva integraatio

Jatkuva integraatio on kehitysmenetelmä, jossa kehittäjät vievät työstämäänsä ohjelma-koodia versionhallintaan (commit) mahdollisimman usein. Sen avulla koodimuutoksetsaadaan tallennettua keskitetysti, jolloin esimerkiksi virhetilanteissa voidaan palata aiem-min toimineeseen versioon koodista. Automatisoitu kääntäminen tarkistaa aikaansaan-noksen, jolloin kehitystiimit voivat huomata ongelmia ajoissa. Mitä tiheämpään tahtiin

7

koodia viedään versionhallintaan, sitä nopeammin voidaan löytää ja paikantaa virheitä.Siten jää enemmän aikaa uusien ominaisuuksien kehittämiselle. Jatkuvalla integraatiollaon monia hyötyjä: ei ole pitkiä ja raskaita versionhallintaan viemisiä, koodin saatavuusparanee, virheiden etsiminen vie vähemmän aikaa ja ohjelmistoa voidaan tuottaa tiheäm-pään tahtiin. [12]

Jatkuva integraatio ratkaisee ongelman, jossa ohjelmistokehittäjät toimivat usein eristyk-sissä toisistaan, mutta heidän täytyy viedä tekemänsä koodimuutokset versionhallintaan.Pitkän aikavälin integraatiot johtavat moniin konflikteihin, vaikeasti löydettäviin ohjel-mointivirheisiin, koodausstrategioiden hajaantumiseen sekä turhaan vaivannäköön. [21]

Jatkuvassa integraatiossa ohjelmakoodia haetaan versionhallinasta, jolloin koodia voidaanmuokata ja päivittää. Muokkausten päätteeksi koodi viedään takaisin versionhallintaan,jolloin sille voidaan suorittaa automaattisesti testejä ja laadunvarmennusta. Jatkuvalla in-tegraatiolla voidaan minimoida raskaiden versionhallintaan viemisten ja ohjelmistopäivi-tysten tarvetta. Menetelmä vaatii useita kehittäjiä ollakseen hyödyllinen, mutta sillä saa-daan varmistettua, että tärkeät muutokset saadaan integroitua sovelluksiin nopeasti. [6]

Monen kehittäjän aikaansaannosten yhdistämisessä on haasteensa. Ohjelmistot voivat ollamonimutkaisia, jolloin pienilläkin muutoksilla voi olla suuria ja arvaamattomia seurauk-sia. Sen takia kehittäjät työskentelevät usein eri kehityshaaroissa (branch), jolloin pää-kehityshaara pysyy vakaana. Haaroilla on kuitenkin taipumus erkaantua toisistaan ajanmyötä. Vaikka yhden haaran yhdistäminen päähaaraan ei ole vaivalloista, monen pitkääneristyksessä olleen haaran yhdistäminen päähaaraan vaatii usein monien ristiriitojen rat-kaisemisia. Haarojen yhdistäminen vaatii usein sen, ettei tiettyä osaa koodista saa muuttaaennen julkaisua. Suurempien tiimien kohdalla haarojen integraatio vaatii useita regressio-testejä ja ohjelmointivirheiden korjauksia, jotta päästään varmuuteen järjestelmän toimi-vuudesta yhdistämisen jälkeen [13]. Regressiotestauksella varmistetaan, etteivät ohjelma-koodimuutokset riko ohjelmiston toimivuutta [51].

Kehitettävät ominaisuudet hajautetaan erillisiksi työtehtäviksi, jotka pyritään suunnittele-maan mahdollisiman pieniksi. Tehtävät jaetaan kehittäjien kesken, ja tehtävän valmistues-sa kehittäjä vie muutoksen kehityshaaraan. Täten muutokset saadaan nopeasti arvioitavik-si, testattaviksi ja julkaistaviksi. Pienissä osissa työskentely mahdollistaa myös säännöl-lisen palautteen saamisen kehittäjiltä, testaajilta sekä asiakkailta, jolloin ongelmien huo-maaminen ja korjaaminen on helpompaa. Täten jatkuva integraatio johtaa suurempaansuoritustehoon, vakaisiin järjestelmiin sekä laadukkaampaan ohjelmistoon. [13]

Jokaisen versionhallintaan viemisen yhteydessä ajetaan sarja kattavia, nopeasti suoritet-tavia yksikkötestejä. Niiden pitäisi olla tarpeeksi kattavia antamaan luotettava kuva ohjel-miston toimivuudesta. Jos yksikkötestien suoritus kestää kauan, kehittäjät eivät halua ajaaniitä säännöllisesti, jolloin niitä on vaikeampi ylläpitää. Jos testit epäonnistuvat, ongelmatkorjataan välittömästi. Täten varmistetaan, että ohjelmisto on aina toimintakunnossa, jaettei kehittäjien haarat eroa liikaa pääkehityshaarasta. Testivetoisella kehityksellä voidaan

8

luoda ylläpidettäviä yksikkötestejä, sillä testit luodaan ennen varsinaisen koodin kirjoit-tamista. Siten koodista tulee modulaarisempaa ja testattavampaa. [13]

2.2.2 Jatkuva käyttöönotto

Jatkuva käyttöönotto on vaihtoehtoinen menetelmä jatkuvalle toimitukselle. Jatkuvassakäyttöönotossa minimoidaan se aikaväli, jolla ohjelmakoodia kirjoitetaan ja jolla se pää-tyy tuotantoon loppukäyttäjille. Siinä hyödynnetään eri välivaiheiden automatisointia si-ten, että lopulta tuotannossa oleva sovellus saadaan päivitettyä. Jatkuvalla käyttöönotollavoidaan nopeuttaa sijoitetun pääoman tuottoa, koska ominaisuuksia saadaan vietyä no-peammin tuotantoon. Lisäksi asiakkailta saadaan nopeammin palautetta uusista ominai-suuksista. [11]

Jatkuvan käyttöönoton työkaluilla tiimi voi tuottaa ohjelmiston välittömästi muutostenyhteydessä sen sijaan, että joutuisi odottamaan tuottamista useiden päivitysten suoritta-misten jälkeen. Täten jatkuvalla käyttöönotolla saadaan luotua täysin saumattomia ja jat-kuvasti päivittyviä ohjelmistoja [6]. Kääntöpuolena kehitystiimiin vastuulle jää se, kuin-ka tarkasti hyväksymistestausta sovelletaan. Voidaan esimerkiksi vaatia, että kaikkien hy-väksymistestien on onnistuttava, ennen kuin muutokset julkaistaan tuotantoon. Silloin eiole varmaa, pääsevätkö muutokset todellakin automaattisesti tuotantoon asti, sillä yksikinepäonnistunut testi estää sen. Toisaalta liian löyhillä vaatimuksilla testaustulosten suhteentuotantoon voi päätyä ohjelmisto, jossa on enemmän virheitä ja puutteita.

Jatkuvassa käyttöönotossa ohjelmistoja pystytään päivittämään uusien ominaisuuksienvalmistuttua. Palveluita voidaan skaalata reaaliaikaisesti kuormituksen mukaan, jolloinsekä laite- että ohjelmistovirheistä voidaan toipua mahdollisimman nopeasti. Työketjukehittämisestä liikevoittoon asti pyritään vakiinnuttamaan ja tehostamaan ketterän ohjel-mistokehityksen mukaisesti. Täten jatkuvassa käyttöönotossa ominaisuudet julkaistaansuoraan tuotantoon ilman manuaalisia toimenpiteitä, jolloin voidaan välttyä niistä aiheu-tuvilta virheiltä ja viivästyksiltä. [22]

2.3 DevOps

Ohjelmistokehityksen alkuaikoina ei ole ollut selkeää jaottelua kehityksen, laadunvarmis-tuksen ja toimenpiteiden välillä. Sama henkilö saattoi kehittää koodia, testata sitä ja jul-kaista sen tuotantoon. Järjestelmien ja kehitystiimien kokojen kasvaessa kehittäjät ovatalkaneet erikoistumaan tiettyihin osa-alueisiin, koska se on tehokkaampaa tuottavuudenkannalta. Haittapuolena osapuolten välinen kommunikaatio ja yhteistyö heikkenee, eten-kin jos osapuolet työskentelevät eri sijanneissa. Sellainen organisaatiorakenne ei ole hy-väksi jatkuvassa toimituksessa, joka perustuu osa-alueiden tiiviiseen yhteensovittamiseen.Täten jatkuva toimitus vaatii ympärilleen sopivan kulttuurin toimiakseen täysin. [32]

DevOps-kulttuuri (Development and Operations, suom. kehitys ja toimenpiteet) on yhdis-telmä sekä ohjelmistokehittämistä että teknologiapainotteisia toimenpiteitä, jossa työnte-

9

Kuva 2.4. Osa-alueiden välinen suhde DevOps-kulttuurissa [32].

kijät ovat kokonaisvaltaisessa vastuussa kehittämisestä, laadunvarmistuksesta sekä erilli-sistä toimenpiteistä. Kuva 2.4 havainnolistaa DevOps-kulttuurin sijoittumista osa-alueidenvälille. Ketterissä menetelmissä hyödynnettävän automaation ansiosta on mahdollista nou-dattaa raskaalta tuntuvaa DevOps-mallia siten, ettei tuottavuus kärsi. Useimmat laadun-varmistus- ja toimenpidetehtävät hoituvat liukuhihnalla, jota kehitystiimin jäsenet voivatohjata. [32]

DevOps-malliin siirtyminen edellyttää muutosta työkulttuurissa ja asenteissa. Tavoittee-na on poistaa kehityksen, laadunvarmistuksen ja muiden toimenpiteiden välisiä rajoja.Osapuolten täytyy tehdä yhteistyötä optimoidakseen kehityksen tuottavuutta ja toimenpi-teiden luotettavuutta. Työntekjän rooli tiimissä ei saa asettaa rajoitteita tuotteesta vastaa-miselle kokonaisuudessaan [50]. Kulttuurista toiseen siirtyminen projektin sisällä on sitähaastavampaa, mitä kauemmin projektia on kehitetty ja mitä suurempi se on. Siitä huo-limatta jatkuvan toimituksen hyödyllisyys on suoraan verrannollinen DevOps-kulttuurinkäyttöasteelle.

2.4 Liukuhihna

Jatkuvan toimituksen keskipisteenä on toimituksen liukuhihna, josta ilmenee, kuinka ke-hitystiimi toimittaa muutoksia tuotantoon. Liukuhihnan ansiosta tuotteista voidaan kehit-tää laadukkaampia [7]. Kuvassa 2.5 on esitetty esimerkki tavanomaisesta jatkuvan toimi-tuksen liukuhihnan suorituksesta. Liukuhihna tarjoaa kehitystiimille reaaliaikaista tietoavaiheiden suorittamisesta sekä niiden tuloksista. Liukuhihnalla edetään automaattisestiseuraaviin vaiheisiin tehtävien onnistuessa, mutta epäonnistumisien yhteydessä liukuhih-nan suoritus keskeytyy.

Jokainen perinteisen toimitusprosessin vaihe on tärkeä ohjelmiston toimittamisen kannal-ta. Siirryttäessä perinteisestä toimituksesta jatkuvaan toimitukseen kyseisten vaiheidenon myös siirryttävä, mutta niitä pitää pystyä suorittamaan liukuhihnalla automatisoidusti.Automatisoidun tuotannon liukuhihna koostuu jatkuvasta integraatiosta, automatisoiduis-ta hyväksymistestauksesta sekä konfiguraatiohallinnasta. Liukuhihna on sarja skriptejä,

10

Kuva 2.5. Jatkuvan toimituksen liukuhihnan suoritus [14].

jotka suoritetaan jokaisen versionhallintaan viedyn muutoksen yhteydessä. [32]

Toisistaan riippumattomien tehtävien ajamisessa kannattaa hyödyntää rinnakkaisuutta,jolloin aikaa kuluu vähemmän ja pullonkaulojen määrä vähenee [7]. Kuva 2.6 havain-nollistaa, kuinka paljon tehtävien rinnakkaisuus säästää aikaa. Siinä kuviot edustavat liu-kuhihnassa suoritettavia tehtäviä, ja punainen tausta tarkoittaa epäonnistunutta tehtävää.Kuvassa jokainen tehtävä epäonnistuu ensimmäisellä kerralla johonkin virheeseen, jonkajälkeen se korjataan ja tehtävä onnistuu jatkossa. Sekventiaalinen liukuhihna joudutaansuorittamaan jokaisen epäonnistuneet tehtävän yhteydessä, mutta rinnakkaisessa liuku-hihnassa kaikki tehtävät ajetaan, vaikka osa niistä epäonnistuisikin. Lisäksi rinnakkaises-sa liukuhihnassa pullonkaulan muodostaa pisin tehtävä, kun taas sekventiaalisessa liuku-hihnassa pullonkaula muodostuu tehtäviin kuluvien aikojen summasta.

Tehtävistä tulevan palautteen tulee olla selkeää. Tehtävä voi koostua monista toimenpi-teistä, jolloin voi olla vaikeaa huomata, mihin toimenpiteeseen tehtävä kaatui. Virheidenetsintä helpottuu, kun käytetään pieniä välivaiheita ja selkeitä virheviestejä. Liukuhihnallapitäisi myös pystyä toimittamaan jokin vanhempi versio sovelluksesta. Yksi suurimmistaongelmista palatessa vanhaan versioon on tietojen eheyden varmistaminen. [7]

2.5 Ympäristöt

Ideaalinen työnkulku sisältää ympäristöt kehittämiselle, testaamiselle sekä tuotannolle.Kehittäjät työskentelevät paikallisessa kehitysympäristössä, mikä toimii niin sanottunahiekkalaatikkona. Siellä voidaan kehittää ohjelmakoodia siihen asti, kunnes kehitettävä

11

Kuva 2.6. Sekventiaalisen ja rinnakkaisen liukuhihnan ajankäytön vertailu, jossa kuviotedustavat tehtäviä [7].

ominaisuus vastaa tarpeisiin. Versionhallintajärjestelmän käyttö kehitysympäristössä ontärkeää, sillä se mahdollistaa muun muassa kehittämisen yhteistyössä muiden kanssa se-kä versioiden tallentamisen. Kun ominaisuus on saatu kehitettyä, ohjelmakoodi viedäändemoympäristöön (staging environment). [29]

Demoympäristö on osa työnkulkua useimmissa kehitys- ja tuotantoprosesseissa. Siellävoidaan tarkastella etukäteen kehittäjien työstämää ohjelmistoa. Sen tehtävänä on matkiatuotantoympäristöä lähes täydellisesti. Yleisesti demoympäristössä suoritetaan laadunvar-mistusta testaamalla ohjelmakoodia, käännöksiä ja päivityksiä. Demoympäristöt vaativatusein täsmälliset kopiot laitteiston, palvelimien, tietokantojen ja välimuistien konfiguraa-tioista toimiakseen oikein. Demoympäristössä testataan lähes tuotantotasoista sovellusta,jolloin saadaan parempi käsitys siitä, miten sovellus ilmenisi tuotannossa. Ympäristössäsuoritetaan testejä, joilla ehkäistään ennalta sekä ongelmia tuotannossa että matalaa suo-rituskykyä loppukäyttäjillä. Täten voidaan minimoida tuotantoon asti pääsevien virheidenmäärä. [39]

Demoympäristö on turvallinen paikka testata muutoksia, joita aiotaan toteuttaa tietoturva-kriittisessä ympäristössä. Täten voidaan vähentää odottamattomien virheiden määrää tuo-tantoympäristössä. Demoympäristö toimii siltana kehittämisen ja tuotannon välillä, jossasuoritetaan sekä laadunvarmistusta että testausta mahdollisimman kattavasti. Demoympä-ristö voidaan pitää ainoastaan yrityksen sisäisessä käytössä tai se voidaan antaa myös ul-kopuolisten saataville. Täten ohjelmistoa voidaan tarkastella ja testata turvallisesti rikko-matta tuotantoympäristöä. Kun demoympäristössä ollaan tyytyväisiä tuotteen ulkoasuun,suoritukseen, luotettavuuteen sekä toiminnallisuuteen, tuote voidaan viedä tuotantoympä-

12

Kuva 2.7. Jatkuvassa toimituksessa usein käytettävät ympäristöt kehittämiselle,testaamiselle ja tuotannolle.

ristöön julkisesti saataville. [29]

Kuvan 2.7 mukaisesti kehittäjät vievät kehittämäänsä koodia versionhallintaan, ja esimer-kiksi jokaisen viemisen yhteydessä voidaan tuottaa uusi demo muutosten pohjalta. De-moympäristössä suoritetaan automatisoitua testaamista, mutta myös manuaalista testaustavoidaan suorittaa tarvittaessa. Lopuksi joku ylläpitäjistä joko hyväksyy tai hylkää tehdytmuutokset hyödyntäen päätöksenteossaan testituloksia. Mikäli muutokset hyväksytään,ne julkaistaan yhdelle tai useammalle tuotantopalvelimelle loppukäyttäjien saataville.

2.6 Virtualisointi ja kontitus

Jatkuvassa toimituksessa on usein tarvetta eriyttää ympäristöt ja mahdollisesti niiden si-sältämät toimeenpiteet toisistaan riippumattomiksi kokonaisuuksiksi. Eriyttämisen an-siosta sovelluksia voidaan ajaa omissa kokonaisuuksissaan, jolloin ne käyttävät ainoas-taan niille annettuja resursseja. Täten käytettäviä resursseja ja koko ympäristöä voidaanhallita paremmin [34]. Eriyttäminen on mahdollista sekä perinteisellä virtualisoinnilla et-tä suosiotaan kasvattaneella kontituksella (containerization). Kuvassa 2.8 on havainnol-listettu ero kontituksen ja virtualisoinnin välillä.

Virtualisointi perustuu virtuaalikoneiden hyödyntämiselle eri käyttöjärjestelmien ollessaeriytetty toisistaan. Virtuaalikone emuloi tietokonearkkitehtuuria ja tarjoaa fyysisen ko-neen toiminnallisuuksia. Sovellusten eriyttäminen voidaan saavuttaa ajamalla sovelluksiaeri virtuaalikonekuvina (virtual machine image). Jokainen sovellus käynnistetään erillise-nä kuvana riippuvuuksineen ja käyttöjärjestelmineen, joita virtuaalikone suorittaa. Monettyökalut tukevat virtualisoinnin avulla tapahtuvaa tuotantoa, ja virtualisoinnilla voidaankätevästi eriyttää kehitys- ja testausympäristöt toisistaan. Virtualisoinnilla on kuitenkinkolme huomattavaa heikkoutta. Virtuaalikone emuloi kokonaista tietokonearkkitehtuuriapyörittääkseen vieraskäyttöjärjestelmää, joka voi johtaa heikkoon suorituskykyyn sekäturhaan kuormitukseen jokaisen toimenpiteen yhteydessä. Emulaatio vaatii paljon resurs-seja ja jokainen sovellus täytyy erikseen emuloida, minkä takia tavanomaisilla työpöy-

13

Kuva 2.8. Konttien ja virtuaalikoneiden välinen ero [18].

täkoneilla suoritetaan vain vähän sovelluksia samanaikaisesti. Jokainen sovellus toimite-taan kokonaisen käyttöjärjestelmän kanssa, jolloin virtuaalikonekuvien koot ovat suuriaja tuottamisen yhteydessä täytyy lähettää ja tallentaa suuri määrä tietoa. [32]

Kontitus tarjoaa erilaisen ratkaisun sovellusten eriyttämiselle. Jokainen sovellus toimite-taan riippuvuuksineen, mutta ilman käyttöjärjestelmää. Sovellukset ovat vuorovaikutuk-sessa suoraan isäntäkäyttöjärjestelmän kanssa, jolloin ei tarvita erillisiä vieraskäyttöjär-jestelmiä. Kontitus tarjoaa paremman suorituskyvyn ilman resurssien tuhlaamista [32].Kontitukseen on tarjolla ilmainen työkalu nimeltään Docker, jota useimmat jatkuvan toi-mituksen työkalut pystyvät hyödyntämään. Se tarjoaa kehittäjälle vapauden kääntää, hal-lita ja turvata sovelluksia siten, etteivät teknologia ja infrastruktuuri aiheuta rajoitteita.Dockerin ansiosta sekä perinteisiä että pilvessä toimivia sovelluksia voidaan viedä au-tomatisoituun ja turvalliseen toimitusketjuun. Docker kasvattaa tuottavuutta ja lyhentääaikaa, joka kuluu sovellusten viemiseen kaupalliseen käyttöön. [16]

Dockerissa kontitus tapahtuu konttien (container) avulla. Kontti on ajonaikainen ilmenty-mä Docker-kuvasta (image), joka puolestaan on suoritettava paketti, joka sisältää kaikentarvittavan sovelluksen ajamiseen, kuten ohjelmakoodin, kirjastoja, ympäristömuuttujiasekä konfiguraatiotiedostoja. Konttien käyttämisellä on monia hyötyjä. Niiden joustavuu-den ansiosta monimutkaisetkin sovellukset pystytään viemään kontteihin. Kontit ovat ke-vyitä, sillä ne käyttävät isäntäkäyttöjärjestelmän ydintä jaetusti. Päivityksiä voidaan tuot-taa lennosta, ja kontissa oleva sovellus voidaan kääntää paikallisesti, tuottaa pilveen jakäyttää missä tahansa. Lisäksi identtisiä kontteja voidaan luoda ja jakaa automaattisesti.Kontti ajetaan erillisenä prosessina, kun taas virtuaalikoneen täytyy aina sisältää erilli-nen käyttöjärjestelmä. Siten virtuaalikone tarjoaa ympäristön, joka sisältää sovelluksenkannalta tarpeettomia resursseja, mikä tekee siitä raskaamman. [18]

Kontit tukevat sekä jatkuvaa integraatiota että toimitusta sallimalla kehittäjien kääntääkoodia yhteistyössä jakamalla keskenään Docker-kuvia. Täten ohjelmiston tuottaminen

14

eri infrastruktuureihin yksinkertaistuu. Dockerilla pystytään luomaan käytäntö, joka in-tegroituu käytettäviin jatkuvan toimituksen työkaluihin, eri käyttöjärjestelmien ympäris-töihin sekä paikallisiin että pilvi-infrastruktuureihin [17]. Docker-kuvat ovat huomatta-vasti pienempiä kuin virtuaalikonekuvat. Kontituksessa eriytys tapahtuu samalla tasollakuin missä isäntäkäyttöjärjestelmän prosessit pyörivät, mutta kontit eivät kuitenkaan jaariippuvuuksiaan keskenään. Konttien kirjastoilla voi olla tietyt versiot, ja yhden kontinkirjaston päivittäminen ei vaikuta muiden konttien kirjastoihin. Kontituksen aikaansaami-seksi Docker luo sarjan Linux-pohjaisia nimiavaruuksia (namespace) ja hallintajoukkojakontille. Täten Dockerin turvallisuus perustuu Linuxin käyttöjärjestelmäytimen (kernel)tarjoamaan prosessien eriytykseen. [32]

2.7 Testaus

Laadukkaan ohjelmiston rakentaminen perustuu siihen, että testatuista koodimuutoksis-ta saadaan vastaanotettua palautettua nopeasti. Perinteisesti koodimuutoksia on tutkittuja testattu manuaalisesti laajassa mittakaavassa. Testaajien on täytynyt seurata dokumen-taatiota siitä, kuinka järjestelmän eri toimintoja testataan varmistaakseen järjestelmän oi-keellisuuden, ja testaaminen on aloitettu vasta pitkäjaksoisen kehittämisen jälkeen. [14]

Manuaalinen regressiotestaus vie paljon aikaa ja on suhteellisen kallista, joten se luo pul-lonkaulan ohjelmiston tiheätahtiselle tuottamiselle. Siten myös palautteen saaminen kes-tää kauemmin. Manuaalinen testaus ja tarkasteleminen ei ole luotettavaa, koska ihmisetsoveltuvat tietokonetta heikommin toisteisten tehtävien kuten regressiotestien suorittami-seen. Lisäksi pelkästään koodia tarkastelemalla on erittäin vaikeaa ennustaa muutostensuuruutta monimutkaisissa ohjelmistoissa. Järjestelmillä on myös taipumusta kehittyä,joten testausdokumentaation pitäminen ajan tasalla vaatii runsasta vaivannäköä. Laaduk-kaan ohjelmiston tuottamiseen on käytettävä erilaista lähestymistapaa. Tavoitteena on ajaauseita erityyppisiä testejä jatkuvan toimituksen läpi, niin automaattisia kuin manuaalisia-kin testejä. [14]

Automatisoidun hyväksymistestauksen vaihe sisältää joukon asiakkaan ja laadunvarmis-tustiimin laatimia testejä. Vaiheen aikana suoritettujen testien perusteella päätetään, onkotuote valmis julkaistavaksi. Jos yksikin hyväksymistesti epäonnistuu, liukuhihnan suori-tus pysäytetään ja tuote ei etene julkaistavaksi. Vaiheen tavoitteena on tehdä tuotteestalaadukas sen sijaan, että sen toimivuutta pitäisi varmentaa jälkeenpäin. Kun kehittäjä saatoteutuksen valmiiksi, ohjelmisto toimitetaan hyväksymistestattuna, jolloin ohjelmistonvarmistetaan olevan asiakkaan toiveiden mukainen. Hyväksymistestaus vaatii usein tii-vistä yhteistyötä asiakkaan kanssa, ja testejä kannattaa luoda jo toimituksen alussa. Auto-maattisten hyväksymistestien hyödyntäminen vanhoissa järjestelmissä voi olla haastavaa.[32]

Kuvassa 2.9 testaustavat on jaettu neljään kategoriaan: hyväksymistestaus, tutkiva testaus,yksikkötestaus sekä ei-toiminnallinen testaus. Kuva havainnollistaa, kuinka eri testausta-

15

Kuva 2.9. Testaustapoja, joita voidaan hyödyntää jatkuvassa toimituksessa [32].

vat painottuvat liiketoiminnan ja teknologian välillä, ja kuinka ne helpottavat sekä kehit-tämistä että tuotteen arviointia. Automatisoidut hyväksymistestit edustavat toiminnallisiavaatimuksia liiketoiminnan näkökulmasta. Asiakkaat määrittelevät niitä usein kertomus-ten ja esimerkkien avulla, joita kehittäjät hyödyntävät ohjelmiston suunnittelussa. Yksik-kötestit ovat automatisoituja testejä, joiden avulla testataan useita pieniä kokonaisuuksiaohjelmakoodissa. Tutkivassa testauksessa järjestelmä yritetään rikkoa tai sitä yritetäänkehittää manuaalisesti. Ei-toiminnallisilla testeillä mitataan järjestelmän ominaisuuksia,kuten suorituskykyä, skaalautuvuutta, turvallisuutta ja niin edelleen. Järjestelmän käytet-tävyyttä voidaan testata manuaalisesti. Laadunvarmistuksella ei ole erityistä paikkaa toi-mitusprosessissa, vaan se on pikemminkin rooli kehitystiimissä. Manuaalisessa laadun-varmistuksessa ei ole enää tarvetta suorittaa toisteisia tehtäviä, vaan ne käsitellään auto-matisoidusti. Kategorisointi ei sisältänyt integraatiotestejä, koska niiden määritelmä onkontekstiriippuvainen. Mikropalveluarkkitehtuureissa ne vastaavat usein hyväksymistes-tausta, koska palvelut ovat pieniä ja tarvitsevat ainoastaan yksikkö- ja hyväksymistestejä.Modulaarisessa sovelluksessa integraatiotestit ovat rajapintatestejä, jotka sitovat moduu-leita ja testaavat niitä yhdessä. [32]

Testausstrategiaa laatiessa on tärkeää priorisoida eri testausmenetelmät omilla painoar-voillaan. Kuvan 2.10 pyramidissa on esitetty yleisesti sopivina pidetyt painoarvot testaus-menetelmille, jossa yksikkötestausta pidetään huomattavasti tärkeimpänä menetelmänä.Yksikkötestit pystyvät kattamaan laajasti ohjelmakoodin eri suorituspolkuja ja niitä pys-tytään suorittamaan nopeasti. Integraatiotestit ovat hitaampia suorittaa ja niitä on vai-keampi ylläpitää. Lisäksi virheet voivat oman koodin sijaan olla peräisin integroitavas-

16

Kuva 2.10. Testausmenetelmien painoarvot pyramidissa esitettynä [15].

ta kohteesta, jolloin virheiden löytäminen on vaikeaa. Hyväksymistestien kirjoittaminen,suorittaminen ja ylläpito syö paljon resursseja, joten niiden määrä kannattaa minimoi-da. Vaikka ne antavat hyvän kuvan järjestelmän toimivuudesta, niillä on raskasta testa-ta kattavasti järjestelmän toimivuutta eri tilanteissa. Yleisesti ne soveltuvat parhaiten erikäytännön tilanneiden testaamiseen. Esimerkiksi käyttäjän sisäänkirjautuminen verkko-kauppaan, tuotteen lisääminen sekä poistaminen ostoskorista ja uloskirjautuminen voisiolla yksi käyttötapaus, jota voitaisiin hyväksymistestata. [15]

17

3. JATKUVAN TOIMITUKSEN TYÖKALUT

Jatkuva toimitus vaatii sopivat työkalut prosessin suorittamiseksi. Täten ennen työkalunhankkimista kannattaa miettiä, millaisia ominaisuuksia työkalusta pitäisi löytyä. Työka-luilla varmistetaan asianmukainen kommunikaatio ohjelmistotiimin kehittäjien, testaa-jien, laadunvarmistajien ja ylläpitäjien kesken [42]. Jatkuvan toimituksen työkaluilla onyhteistä se, että toimenpiteet perustuvat pelkästään koodin ympärille. Siten kaikki proses-sin vaiheet voidaan automatisoida.

Jatkuvan toimituksen työkalua hyödyntämällä tuotetta voidaan jatkuvasti päivittää tes-tausvaiheen jälkeen. Tuotteen ominaisuuden päivittämisen jälkeen on tärkeää seurata ky-seistä ominaisuutta ja varmistaa, että se toimii oikein. Seurantatyökaluilla voidaan havaitavirheelllisiä muokkauksia ja päivityksiä, ennen kuin ne vaikuttavat asiakkaan toimintaan.Siten voidaan parantaa asiakastyytyväisyyttä ja pienentää ongelmien ilmenemisen toden-näköisyyttä. Jatkuvan toimituksen ohjelmistoilla on kyky muuttaa tuotetta äärimmäisenpaljon. Sen takia on tärkeää, että valittava ohjelmisto on turvallinen ja että vahingossatehdyt muutokset eivät pääse tuotantoon. Ohjelmistolla tulisi olla pääsynhallintamekanis-mi, jolla valitut henkilöstön jäsenet pääsisivät tekemään tiettyjä muutoksia tuotteeseen.Vahva turvallisuusjärjestelmä on elintärkeä toimituksen hallinnan kannalta. [6]

Jatkuvan toimituksen sijaan on mahdollista käyttää jatkuvaa käyttöönottoa. Prosessiensuurimpana erona on se, että jatkuvassa toimituksessa ennen tuotantoon julkaisua oh-jelmisto on testattava ja hyväksyttävä manuaalisesti, kun taas jatkuvassa käyttöönotos-sa tietokone suorittaa hyväksymisen automaattisesti. Manuaalinen testaaminen vie aikaaja vaivannäköä, joten testaamisessa kannattaa hyödyntää työkalua, joka suorittaa testitautomaattisesti. Jotkin työkalut tarjoavat erikoistuneita testausominaisuuksia, kuten esi-merkiksi asiakaspalauteominaisuuksia, joilla saadaan kartoitettua asiakkaiden näkemyk-siä tuotteesta. [6]

Yksi suurimmista kysymyksistä on, haluaako työkalun ohjelmistopalveluna eli SaaS-pal-veluna (Software as a Service), vai tehdäänkö työkalu itse paikallisesti. SaaS-työkaluthuolehtivat itse palvelimiensa ylläpidosta ja antavat käyttäjille enemmän aikaa keskittyäkehittämisen muihin osa-alueihin [6]. Lisäksi pilvessä toimivat SaaS-työkalut päivittyvätajan myötä tarjoten uusia ominaisuuksia ja tukea ongelmatilanteissa.

Paikallinen, itse tehty työkalu on erittäin joustava laajennettavuuden ja muokattavuudensuhteen. Lisäksi tietoa voidaan käsitellä turvallisesti, koska se pysyy yrityksen sisällä.Kääntöpuolena paikallinen työkalu vaatii enemmän aikaa sen ylläpitoon ja hallintaan. Li-säksi paikallinen työkalu voi olla välttämätön vaihtoehto, jos yrityksen käytäntöjen mu-kaan käsiteltävien tietojen pitäisi jäädä vain yksityksen sisälle, mahdollisesti vielä palo-

18

muurin taakse. Yrityksillä ei ole välttämättä suurta budjettia jatkuvan toimituksen toteut-tamiseen. Palvelu voi erikseen laskuttaa sen ominaisuuksien käyttämisestä, jolloin kan-nattaa tarkasti suunnitella rahan sijoittaminen eri ominaisuuksien kesken. Hintaan voi vai-kuttaa esimerkiksi käännösten määrä päivässä tai muulla aikavälillä, rinnakkaisten kään-nösten tukeminen, käyttäjien määrä ja tiedon säilytysaika. Paikallisella työkalulla ei olevastaavia kustannuksia, mutta sen ylläpitäminen syö henkilöstöresursseja. [43]

Jatkuvan toimituksen palvelua valittaessa on tärkeää kiinnittää huomioita siihen, mitä eripalveluita siihen on mahdollista integroida. Useat jatkuvan toimituksen palvelut tarjoavatyhteensopivuuden moniin muihin ohjelmistopalveluihin, kuten sovellusten levitykseensekä tuotannon että tietokoneiden hallintaan. Kolmannen osapuolen työkalujen hyödyntä-minen jatkuvassa toimituksessa mahdollistaa toimituksen virtaviivaistamisen, ja työkalujapystytään hallitsemaan keskitetysti ainoastaan yhden sovelluksen kautta. [6]

Jatkuvan toimituksen toteuttamiselle on tarjolla valtava määrä kaupallisia työkaluja. Neovat keskenään hyvin samankaltaisia, koska niiden tarkoituksena on mahdollistaa jatkuvatoimitus ohjelmistoprojekteille. Niistä monet ovat helposti saatavilla, ja useimmat ovatainakin peruskäytöltään ilmaisia [43]. Työkaluista kuitenkin löytyy eroavaisuuksia muunmuassa teknologioiden ja yhteensopivuuksien kanssa, joten niistä kannattaa valita sopivinvaihtoehto ohjelmistoprojektin kannalta. Tässä luvussa tarkastellaan vain huomattavimpiaja käytetyimpiä työkaluja.

3.1 Jenkins

Vuonna 2004 Java-kehittäjä Kohsuke Kawaguchi työskenteli Sun-yrityksellä. Kawaguchikyllästyi rikkinäisiin käännöksiin ja halusi kehittää tavan, jolla voitaisiin tutkia, toimiikoohjelmakoodi ennen sen viemistä versionhallintaan. Täten hän rakensi Java-pohjaisen au-tomaatiopalvelimen nimeltään Hudson. Siitä tuli suosittu Sunilla, ja se alkoi leviämäänmyös muihin yrityksiin avoimena lähdekoodina. Vuonna 2011 Hudsonista haarautui au-tomaatiopalvelu nimeltään Jenkins, josta tuli huomattavasti aktiivisempi ja käytetympipalvelu. [23]

Jenkins on suosituin avoimeen lähdekoodiin perustuva ilmainen automaatiopalvelu. Setarjoaa satoja liitännäisiä (plugin), joita voidaan hyödyntää ohjelmistojen kääntämisessä,tuottamisessa ja automatisoinnissa. Jenkins soveltuu sekä jatkuvaan integraatioon että jat-kuvaan toimitukseen missä tahansa ohjelmistoprojektissa. Se on itsenäinen Java-ohjelma,jota voidaan ajaa suoraan sellaisenaan eri käyttöjärjestelmillä. [25]

Jenkins tarjoaa web-käyttöliittymän, jonka kautta se voidaan alustaa ja konfiguroida. Ku-vassa 3.1 on esitetty esimerkki Jenkinsin käyttöliittymästä, josta ilmenee muun muas-sa määriteltyjä tehtäviä sekä niiden suoritustilastoja. Jenkins on helposti laajennettavissasen liitännäiskeskeisen arkkitehtuurin ansiosta, joten se tarjoaa rajattomasti käyttömah-dollisuuksia. Sillä voidaan jakaa suoritettavaa työkuormaa useiden eri koneiden kesken,ja tietyt koneet voidaan asettaa suorittamaan vain tiettyjä toimenpiteitä. [25]

19

Kuva 3.1. Esimerkkikuva Jenkinsin käyttöliittymästä.

Jenkinsissä on työn kirjoitushetkellä käytettävissä yli 1500 liitännäistä, jotka tukevat ke-hittämisen automatisointia [28]. Alun perin automaatiota tarjottiin pelkästään Java-koodinjatkuvaan integraatioon sekä toimitukseen, mutta nykyään liitännäisillä voidaan automati-soida muitakin prosesseja. Liitännäiset voidaan jakaa viiteen osa-alueeseen niiden käyttö-tarkoitusten mukaan, jotka ovat alustat, käyttöliittymä, ylläpito, lähdekoodin hallinta sekäkääntämisen hallinta. [23]

3.1.1 Pääpalvelin ja agentit

Jenkinsillä tehtävien hallinta tapahtuu pääpalvelimella (master). Se on altis kuormituk-selle, koska ohjelmistotiimillä tai yrityksellä voi olla tarvetta suorittaa monta tehtävääsamanaikaisesti. Sen takia tehtäviä ei pitäisi suorittaa pääpalvelimella, vaan sen kannattaaohjata tehtävät erillisille agenteille (agent, slave) [32]. Agentti on tyypillisesti tietokonetai kontti, joka ottaa yhteyden pääpalvelimeen ja suorittaa sen antamia tehtäviä [26].

Kuva 3.2 havainnollistaa pääpalvelimen ja agenttien välistä vuorovaikutusta sekä pää-palvelimen vastuualueita. Pääpalvelin vastaanottaa käännösten (build) käynnistyspyyntö-jä, jotka voivat syntyä manuaalisesti, ajastetusti tai siinä yhteydessä, kun koodia viedäänversionhallintaan. Palvelin tuottaa ilmoituksia käännösten lopputuloksista, jotka voidaanohjata eri palveluihin, kuten esimerkiksi sähköpostiviesteihin. Palvelin käsittelee ylläpi-täjän lähettämiä HTTP-pyyntöjä (Hypertext Transfel Protol, tiedonsiirtoprotokolla), jottaylläpitäjä voi manipuloida palvelimen toimintaa. Lisäksi palvelin hallitsee käännösym-päristöä jakamalla käännöksen aikana tapahtuvien tehtävien suoritusta agenttien kesken.[32]

Agentit ovat konfiguroitavissa monin tavoin. Niille pystyy asettamaan esimerkiksi rin-

20

Kuva 3.2. Pääpalvelimen ja agenttien välinen vuorovaikutus [32].

nakkaisten käännösten maksimimäärän sekä käynnistymistavan. Rinnakkaisten käännös-ten maksimimäärä määräytyy agentilla sijaitsevien suorittajien (executor) määrän mu-kaan. Suorittajien avulla agentti voi suorittaa monia tehtäviä rinnakkain [26]. Agenttivoidaan käynnistää muun muassa Java Web Start -ohjelmalla. Tällöin agentissa täytyyavata web-käyttöliittymän kautta ladattu tiedosto, joka muodostaa TCP-yhteyden (Trans-mission Control Protocol, tietoliikenneprotokolla) pääpalvelimeen. Siten agentin ei täy-dy olla tavoitettavissa pääpalvelimen kautta, vaan ainoastaan agentti pystyy tavoittamaanpääpalvelimen. Pääpalvelimeen pystyy konfiguroimaan portin, minkä kautta se kuunteleeagenttien yhdistämispyyntöjä. Windows-käyttöjärjestelmällä Java Web Start käynnistääWindows-palvelun (Windows service), joka vastaa agentin suorittamisesta. Täten agenttivoidaan käynnistää automaattisesti tietokoneen uudelleenkäynnistysten yhteydessä.

Agentti voidaan käynnistää myös komentorivin kautta, jolloin agentti ei tarvitse erillistäWindows-palvelua toimiakseen. Siten agentin graafisesta käyttöliittymästä pystyy näke-mään tehtävät, joita pääpalvelimen kautta ollaan määrätty tekemään. Tapahtumien näke-minen voi olla hyödyllistä tai jopa välttämätöntä esimerkiksi käyttöliittymätestejä suori-tettaessa.

21

3.1.2 Tehtävät

Jenkinsissä voidaan konfiguroida tehtäviä (job), jotka soveltuvat yksinkertaisten ja lyhyi-den toimenpiteiden suorittamiseen. Tehtävä voidaan määritellä lisäämällä uusi vapaamuo-toinen projekti (freestyle project) Jenkinsin käyttöliittymän kautta.

Tehtävillä ja liukuhihnoilla on paljon yhteisiä asetusvaihtoehtoja. Molemmille voidaanesimerkiksi määritellä parametreja, ajastetun käynnistyksen sekä rinnakkaisten ajojen sal-limisen. Suurimpana erona tehtäville määritellään käännöskomentoja, jotka suoritetaantehtävää ajettaessa. Jenkinsissä on oletuksena tuki monille erilaisille komentotyypeille,kuten Windows batch-komennoille, shell-komennoille ja Gradle-skripteille. Komentotyy-pit ovat laajennettavissa liitännäisten ansiosta. Alla on esimerkki tehtävälle määritellystäbatch-komennosta, joka tulostaa tervehdyksen.

echo "Hello %name%!"

Tehtävälle on määritelty parametri name, joka voidaan liukuhihnojen tapaan syöttää en-nen ajoa joko Jenkinsin käyttöliittymän kautta tai liukuhihnassa ’build job’-komennonyhteydessä.

3.1.3 Liukuhihnat

Jenkinsiin voidaan viedä Jenkinsfile-nimisiä liukuhihnaskriptejä joko versionhallinnastatai kirjoittamalla niitä käyttöliittymän kautta. Monet versionhallintajärjestelmät ovat tuet-tuja liitännäisten ansiosta. Jenkinsin liukuhihnat ovat joko deklaratiivisia tai skriptattuja.Deklaratiivinen liukuhihna on helposti omaksuttava, ja se käyttää Groovy-yhteensopivaasyntaksia. Groovy on Apachen kehittämä ohjelmointikieli Java-alustalle, jonka tavoittee-na on parantaa kehittäjien tuottavuutta sen ytimekkään ja helposti lähestyttävän syntaksinansiosta [20]. Liukuhihnalle määritellään erilaisia rakenteisia lohkoja loogisessa järjes-tyksessä. Ohjelmassa 3.1 on esitetty yksinkertainen deklaratiivinen liukuhihna, joka ottaaparametrina nimen ja tulostaa tervehdyksen.

Deklaratiivisessa liukuhihnassa kaikki lohkot menevät uloimman pipeline-lohkon sisäl-le. Liukuhihna, tai tietty vaihe (stage), suoritetaan agent-lohkon määrittelemällä agentil-la. Arvolla any voidaan käyttää mitä tahansa vapaana olevaa agenttia. Tehtävä voidaanmäärätä suoritettavaksi tietyllä agentilla labelin perusteella. Lisäksi agentin pystyy myösasettamaan pyörimään Docker-kontin sisällä. [27]

Liukuhihnassa voi käyttää vapaaehtoista options-direktiiviä, jonka sisällä voidaan muo-kata liukuhihnan asetuksia. Esimerkiksi asetuksella skipDefaultCheckout voidaan estääagentin pääsy versionhallintaan [27]. Pipeline-liitännäinen tarjoaa monta asetusta oletuk-sena, mutta asetuksia saa hankittua lisää muiden liitännäisten kautta.

22

pipeline {agent anyparameters {

string(description: ’Your name.’, name: ’name’)}stages {

stage(’Greet’) {steps {

echo "Hello ${params.name}!"}

}}

}

Ohjelma 3.1. Deklaratiivinen liukuhihna, joka tervehtii käyttäjää.

Direktiivin parameters sisältävälle liukuhihnalle voidaan syöttää parametreja liukuhihnanlaukaisun yhteydessä. Jokainen parametri edustaa tietotyyppiä, kuten esimerkiksi stringtarkoittaa merkkijonoa ja booleanParam totuusarvoa [27]. Parametreilla voidaan vaikut-taa liukuhihnan toimintaan, jolloin liukuhihnaa voidaan suorittaa eri tavoin.

Lohkon stages sisällä suoritetaan liukuhihnan toimenpiteet. Lohkon sisälle on tultava vä-hintään yksi stage-direktiivi. On suositeltavaa, että jokaista jatkuvan toimituksen erillistäosaa kohden luodaan oma vaihe. Esimerkiksi kääntäminen, testaaminen ja tuottaminenpitäisi tapahtua erillisillä vaiheillaan [27]. Vaiheiden avulla monet liitännäiset pystyvätesittämään visuaalisesti liukuhihnan tilaa ja edistymistä [26].

Liukuhihnassa voidaan määritellä parallel-lohko, jonka sisällä olevat vaiheet suoritetaanrinnakkain. Yleisesti vaihe voi sisältää vain yhden steps-, stages- tai parallel-lohkon. Rin-nakkain suoritettavat vaiheet eivät voi itsessään sisältää rinnakkaisia vaiheita, mutta muu-toin ne toimivat kuten muutkin vaiheet. Lisäksi lisäämällä komento failFast true lohkonparallel sisältämään vaiheeseen on mahdollista keskeyttää muiden rinnakkaisten vaihei-den suoritus välittömästi, mikäli yksikin niistä epäonnistuu. [27]

Steps-lohko sisältää vähintään yhden askeleen (step), jotka suoritetaan järjestyksessä [27].Askeleet ovat käytännössä joko suoria komentoja tai funktiokutsuja. Esimerkiksi muitaliukuhihnoja voidaan suorittaa komennolla build job: ’liukuhihnanNimi’ ja niille voi tar-vittaessa syöttää parametreja.

3.2 Travis CI

Travis CI on pääasiassa jatkuvaan integraatioon tarkoitettu ilmainen ohjelmisto, muttase soveltuu myös jatkuvaan toimitukseen. Sitä mainostetaan etenkin GitHub-projektientestaamiseen soveltuvana ohjelmistona. Travis CI tarjoaa monia tietokantoja ja palvelui-ta esiasennettuina, joita voi ottaa käyttöön kääntämiskonfiguraatiossa. Jokainen koodi-integrointipyyntö (pull request) pystytään testaamaan ennen varsinaista integrointia. Tuot-

23

taminen voidaan suorittaa aina automaattisesti, kun laaditut testit on suoritettu onnistu-neesti. [45]

Ajettaessa käännöstä Travis CI kloonaa GitHub-repositorion uuteen virtuaaliympäristöön,ja suorittaa sarjan tehtäviä kääntääkseen ja testatakseen koodia. Jos yksikin tehtävä epä-onnistuu, käännös on rikkinäinen. Muussa tapauksessa käännös on onnistunut, ja TravisCI voi tuottaa koodin web-palvelimelle tai sovelluksen verkkolevylle. Käännökset voi-vat myös automatisoida toimituksen muita osia, joten työtehtävät voivat olla riippuvaisiatoisistaan. [44]

3.3 CircleCI

CircleCI on sekä jatkuvaan integraatioon että toimitukseen perustuva ohjelmisto, jokaon peruskäytöltään ilmainen. Sen avainsanoja ovat tehokkuus, joustavuus ja hallittavuus,ja sen luvataan nopeuttavan ohjelmistokehitystä ja tarjoavan paljon muokattavuutta. Seautomatisoi ohjelmistokehityksen liukuhihnan toimintaa koodin versionhallintaan viemi-sistä ohjelmiston julkaisuun asti. CircleCI on integroitavissa lähdekoodialustojen, kutenGitHubin, GitHub Enterprisen ja Bitbucketin, kanssa. Jokaisen versionhallintaan viemi-sen yhteydessä CircleCI luo käännöksen, jota testataan joko kontissa tai virtuaalikoneella.Käännöksen epäonnistuessa siitä luodaan ilmoitus, jotta ongelmat ovat nopeasti kehittä-jien nähtävillä ja korjattavissa. Käännökset, jotka läpäisevät testit, ovat tuotettavissa mo-niin eri ympäristöihin, jolloin tuote saadaan kaupalliseen käyttöön nopeasti. [8]

CircleCI sisältää ominaisuuksia testauksen automatisoinnille sekä virtuaalikoneilla ettäkonteissa. Käännösten epäonnistumisista ilmoitetaan välittömästi, jolloin virheet voidaankorjata aikaisessa vaiheessa. CircleCI:ssä on liukuhihnoja vastaavia työvoita (workflow),joilla voidaan määrittää käännösten, testauksen ja tuottamisen kulku. Docker-tuen ansios-ta käyttäjät voivat konfiguroida ympäristönsä juuri haluamakseen. Mikä tahansa Docker-kuva on ajettavissa Dockerin rekistereistä, ja ajamista voidaan muokata tehtäväkohtaises-ti. [9]

Käyttäjät voivat konfiguroida resussinsa perustuen tiiminsä käännösten tarpeille. CircleCItukee myös kaikkia ohjelmointikieliä, joita voidaan kääntää Linuxilla tai macOS:lla, ku-ten C++, Javascript, PHP, Python ja Ruby. Kehittäjät voivat hyödyntää haluamiaan työ-kaluja ja viitekehyksiä, ja käännöksiä voidaan nopeuttaa CircleCI:n välimuistiasetustenavulla. Välimuistin käyttö on konfiguroitavissa Docker-kuville, lähdekoodille ja riippu-vuuksille. CircleCI:n tietoturvateknologioihin sisältyy muun muassa kokonaisvaltainenvirtuaalikoneiden eriytys, Dockerin tietoturvakyvyt sekä Linuxin käyttöjärjestelmäyti-men tietoturvamoduulit. Kehittäjät voivat tarkastella käännöksiä CircleCI:n interaktiivi-sella käyttöliittymällä. Käyttöliittymä on muokattavissa siten, että siitä saa näkyviin esi-merkiksi useimmiten epäonnistuneet tai hitaimmat testit. [9]

24

3.4 Codeship

Codeship on peruskäytöltään ilmainen CI/CD-ohjelmisto, jota tarjotaan pilvipalveluna jajoka nopeuttaa ohjelmistokehitystä. Se tarjoaa muokattavissa olevaa automaatiota, jon-ka avulla ohjelmakoodimuutoksia saadaan vietyä tuotantoon nopeammin. Kääntämis- jatestausautomaatiota hyödyntämällä voidaan löytää virheitä koodissa ennen tuotantoon jul-kaisemista, jolloin sovelluksen toimivuus tuotantoympäristössä saadaan varmistettua. Co-deship tarjoaa rinnakkaisten liukuhihnojen hyödyntämisen, samanaikaisen kääntämisen javälimuistin hyödyntämisen, mikä tekee siitä tehokkaan työkalun. [10]

Codeshipin vahvuuksia ovat nopeus, luotettavuus ja yksinkertaisuus. Sen voi konfiguroidakääntämään ja tuottamaan GitHubissa olevan sovelluksen demo- tai tuotantoympäristöön.Se tarjoaa monia asetuksia ympäristön alustamiseen. CodeShip on integroitu suosituihinlähdekoodialustoihin GitHubiin ja Bitbuckettiin, ja se tukee monia ohjelmointikieliä jatuotantoalustoja. Kun koodia viedään GitHubiin tai Bitbuckettiin, CodeShip kääntää so-velluksen turvallisilla palvelimillaan ja ajaa laaditut automatisoidut testit. Jos testit epäon-nistuvat, se huomauttaa kehitystiimiä sähköpostitse tai jonkin integroidun palvelun kautta,kuten Slackissa tai HipChatissa. Jos testit onnistuvat, CodeShip vie käännöksen demo- taituotantopalvelimille määritellyn liukuhihnan mukaisesti. [35]

25

4. JATKUVA TOIMITUS ERASSA

Työn kohdejärjestelmäksi valittiin Atostek Oy:n kehittämä web-palvelu eRA, jonka avul-la sosiaali- ja terveydenhuollon tietojärjestelmiä voidaan liittää Kelan tarjoamiin Kansal-lisen terveysarkiston palveluihin eli Kanta-palveluihin [3]. Sen avulla terveydenhuollontoimijat voivat ottaa Kanta-palveluita helposti ja nopeasti käyttöön. Palvelu tarjoaa val-miit käyttöliittymät eri palveluiden käyttöön, kuten sähköiseeen lääkemääräykseen, poti-lastiedon arkistoon sekä lomakepalveluun [4]. Kuvassa 4.1 on havainnollistettu tietojär-jestelmän liittäminen Kanta-palveluihin.

Palvelun eRA avulla sovelluksia ja tietojärjestelmiä voidaan integroida Kanta-palveluihinvain yhden rajapinnan kautta ilman raskasta yhteistestausta ja sertifiointia. Tietojärjestel-miä voidaan integroida käyttämään Kelan sähköistä lääkemääräystä web-käyttöliittymänkautta. Potilastietojärjestelmiä voidaan liittää Kelan potilastiedon arkistoon web-käyttö-liittymässä tai ohjelmointirajapintojen kautta. Lomakepalvelun avulla Kannasta voidaanhakea ja tallentaa sekä lääkärintodistuksia että lausuntoja. Lisäksi vanhojen tietojen kat-selimella voidaan tarkastella vanhoja potilastietoja, joita on siirretty Kantaan aiemmastapotilastietojärjestelmästä. [5]

4.1 eRAn kehittäminen

Palvelun eRA kehittämisessä käytetään pääasiassa Visual Studiota, joka on integroitu oh-jelmointiympäristö (IDE, Integrated Development Environment). Sen ominaisuuksien an-siosta koodin kirjoittaminen, virheiden etsiminen ja korjaaminen sekä testaaminen onnis-tuvat kätevästi. Se on myös laajasti muokattavissa ja yhdistettävissä versionhallintajärjes-telmiin [47]. Palvelun eRA ja siihen liityvien simulaattoreiden ohjelmoimisessa käytetäänC#-ohjelmointikieltä, joka on Microsoftin kehittämä oliopohjainen ohjelmointikieli. Olio-ohjelmoinnissa pyritään tiedon modulaarisuuteen hyödyntämällä olioita, joihin sidotaanvain niiden itsensä tarvitsemaa tietoa ja toiminnallisuutta.

Kuva 4.1. Tietojärjestelmän liittäminen Kanta-palveluihin eRAn välityksellä [5].

26

Kehityksessä hyödynnetään ASP.NET:iä, joka on avoimeen lähdekoodiin perustuva viite-kehys nykyaikaisten web-sovellusten ja -palveluiden rakentamiselle. Sen avulla voidaanluoda yksinkertaisia, nopeita ja skaalautuvia web-sivustoja [2]. Tarkemmin ottaen kehi-tys tapahtuu ASP.NET MVC-laajennoksella, joka perustuu MVC-mallin (model-view-controller, suom. malli–näkymä–käsittelijä) hyödyntämiselle. MVC-mallissa käyttäjä tar-kastelee tietoa näkymässä, ja käsittelijä on vuorovaikuksessa käyttäjän toimenpiteidenkanssa. Näkymä ja käsittelijä muodostavat keskenään sovelluksen käyttöliittymän. Tieto-malli on sovelluksen osa, joka sisältää sekä näkymän että logiikan tarvitsemaa tietoa, jamuokkaa kyseisiä tietoja käyttäjän vuorovaikutuksen seurauksena. [31]

Seuraavia simulaattoriprojekteja kehitetään tiiviisti eRAn yhteydessä:

• SimArkisto

• SimReseptikeskus

• SimValvira.

SimArkisto, SimReseptikeskus ja SimValvira ovat yrityksellä kehitettyjä simulaattoreita,joita kehitys- ja demoympäristössä sijaitseva eRA hyödyntää eri tilanteissa lähettämälläniille pyyntöjä ja vastaanottamalla vastauksia HTTPS-rajapinnan yli (Hypertext Trans-fer Protocol Secure). HTTPS on HTTP:n laajennos, jossa kommunikaatio salataan sa-lausprotokollaa hyödyntämällä. Palvelussa eRA käytetään varmenteita (certificate), joi-den avulla tunnistetaan HTTPS-rajapintaa käyttävät osapuolet. SimArkisto simuloi KelanKanta-arkistoa, ja sitä käytetään enimmäkseen sekä palvelutapahtumien että diagnoosienkäsittelyyn. SimReseptikeskuksen kautta voidaan käsitellä erilaisia lääkemääräyksiin jauusimispyyntöihin liittyviä asioita. SimValvira simuloi sosiaali- ja terveysalan lupa- javalvontavirasto Valviran palveluita. SimValviran välityksellä voidaan hallinnoida ammat-tioikeuspalveluita sekä asettaa käyttöoikeuksia eri rooleille, kuten lääkäreille ja sairaan-hoitajille.

Palvelun eRA kehittämisessä on sovellettu perinteistä toimitusprosessia jo useammanvuoden ajan, eli palvelun julkaisemisessa tuotantoon asti ei ole sovellettu automatiik-kaa. Käytännössä julkaistaakseen palvelun tuotannossa työntekijän on täytynyt päivittäätarvittavien projektien koodit versionhallinnasta, kääntää projektit ja testata järjestelmäähyödyntäen sekä manuaalista regressiotestausta että tutkivaa testausta. Kun ohjelmistoaon saatu testattua riittävän hyvin, se on julkaistu tuotantoon. Ohjelmiston kasvaessa ajanmyötä julkaisuihin on kulunut yhä enemmän aikaa. Täten projektissa nousi esiin tarveketterämmälle toimitusprosessille, jossa mahdollisimman moni vaihe kehittämisen ja jul-kaisun välillä saataisiin automatisoitua. Prosessiksi valittiin jatkuva toimitus, koska silläsaadaan automatisoitua kaikki julkaisua edeltävät toimenpiteet.

4.2 Työkaluratkaisu

Jatkuvan toimituksen työkaluksi valittiin Jenkins. Lähtökohtaisesti Jenkinsin valinnalle eiollut muita perusteita kuin sen suosio ja hyvä maine automaatiopalveluna. Vertailtaessa

27

Jenkinsiä muiden CI/CD-palvelujen kesken ilmeni, että Jenkinsille löytyy huomattavas-ti eniten dokumentaatiota verkosta. Lisäksi Jenkinsin lukuisista liitännäisistä löytyy tukiversionhallintajärjestelmä SVN:lle (Subversion), jota käytetään eRAssa ja siihen liitty-vissä projekteissa. Monet muut CI/CD-ohjelmistot soveltuvat käytettäviksi enimmäkseenGit-versionhallintajärjestelmän kanssa. Jenkinsin suosion seurauksena sen elinkaari tuleetodennäköisesti olemaan pisin muihin työkaluihin verrattuna, jolloin Jenkinsiä voidaanhyödyntää pitkään eRAssa. Lisäksi liitännäispohjaisen arkkitehtuurin ansiosta tarvittavialiitännäisiä voidaan asentaa tulevaisuuden tarpeiden mukaan.

Aluksi pohdittiin myös oman työkalun tekemistä, mutta valmiisiin työkaluihin nähdensellaisen tekeminen ja ylläpitäminen olisi vienyt liikaa resursseja. Lisäksi paikallisuudel-la ei olisi ollut mitään etua, etenkään kun valmiissa työkaluissa tietoturva on lähes ainariittävän hyvä.

4.3 Ympäristö

Ympäristö suunniteltiin kuvan 4.2 mukaiseksi. Ympäristöksi valittiin palvelimina toimi-via virtuaalikoneita hyödyntävä kokonaisuus, jonka keskeisessä osassa on ohjelmisto ni-meltään VMWare Workstation Pro. Se on virtuaalikonemonitori, jonka sisällä voi luodauseita eri virtuaalikoneita, joissa voi käyttää mitä käyttöjärjestelmiä tahansa [52]. Virtuaa-likoneet ovat eristyksissä olevia ympäristöjä erilaisilla yksityisyysasetuksilla, työkaluillaja verkon konfiguraatioilla. Kaikki ympäristön käyttöjärjestelmät ovat Windows-pohjaisiaeRAn vaatimusten ja yhdenmukaisuuden takia.

Yritys tarjosi suorituskykyisen palvelimen jatkuvaa toimitusta varten, jonka päälle raken-nettiin virtuaalikoneympäristö. Toinen vaihtoehto olisi ollut hyödyntää kontitusta, jolloinvirtuaalikoneympäristöä ei olisi tarvittu ja ainut tarvittava käyttöjärjestelmä olisi jäänytpalvelimelle. Kontitukseen tarkoitetun Dockerin käytöstä ei projektin sisällä ollut juuri-kaan kokemusta, joten sen hyödyntämistä tutkittiin parin viikon ajan. Dockerin konfigu-rointi koitui haastavaksi Windows-ympäristössä, eikä MSBuild- tai MSDeploy-työkalujasaatu toimimaan konteissa. Täten Dockerin hyödyntämisestä päätettiin luopua ja keski-tyttiin alkuperäiseen suunnitelmaan virtuaalikoneympäristöstä. Vaikka virtualisointi tuh-laakin resursseja, palvelin on tarpeeksi tehokas pyörittääkseen virtuaalikoneympäristöävaivattomasti. Lisäksi tuotantoympäristössä käytetään samaa käyttöjärjestelmää ja samo-ja ohjelmistoja kuin demoympäristö eRAServerillä, joten virtualisoinnin avulla tuotan-toympäristöä voidaan matkia erittäin tarkasti, kun taas kontituksella matkiminen ei olisiyhtä selkeää.

Ympäristö koostuu neljästä palvelimesta, jotka ovat pääpalvelimena toimiva eRAPublishsekä virtuaalikoneet eRABuild, eRAServer ja eRATest. eRAPublish ja virtuaalikoneet si-jaitsevat omassa sisäverkossaan, jonka sisällä ne kommunikoivat keskenään tarvittaessa.Esimerkiksi eRATest-koneella suoritettavat testit hyödyntävät eRAServer-konetta, jokapuolestaan pyörittää eRAn ja simulaattoreiden web-sivustoja. eRAPublish toimii myös

28

Kuva 4.2. Jatkuvan toimituksen ympäristö eRAssa.

ulkoverkossa, jotta siihen voidaan ottaa etätyöpöytäyhteys. Lisäksi eRAServer pääsee ul-koverkkoon, koska osassa siellä suoritettavista käyttöliittymätesteistä täytyy ladata kol-mansien osapuolien varmenteita ulkoverkosta. Taulukossa 4.1 on esitetty ympäristön ko-neiden IPv4-osoitteet (Internet Protocol) sisä- ja ulkoverkossa.

Taulukko 4.1. Palvelinten IP-osoitteet.Tietokone Sisäverkon IPv4 osoite Ulkoverkon IPv4-osoiteeRAPublish 192.168.2.1 10.80.50.102eRABuild 192.168.2.11 Ei oleeRAServer 192.168.2.12 10.80.50.109eRATest 192.168.2.10 Ei ole

Palvelimille on asennettu ohjelmia, joita tarvitaan tehtävien suorittamisen aikana. Asen-netut ohjelmat on koottu taulukkoon 4.2. Asennettujen ohjelmien määrä on pyritty mini-moimaan tehokkuuden ja yksinkertaisuuden vuoksi. Virtuaalikone eRAServeriä lukuun-ottamatta jokaisella koneella on käyttöjärjestelmänä Windows 10. Tuotantoympäristössäkäytetään käyttöjärjestelmänä Windows Server 2016:ta, joten sen peilaamisen vuoksi de-moympäristönä toimiva eRAServer käyttää samaa käyttöjärjestelmää. Jokaiselle koneelleon asennettu selaimeksi Google Chrome, jolla voi vähintäänkin ohjata Jenkinsin käyttö-liittymää, vaikkei kone olisikaan yhdistettynä ulkoverkkoon.

29

Taulukko 4.2. Palvelimille asennetut ohjelmat.

Palvelin Ohjelman nimiKaikki Google ChromeeRAPublish Jenkins

VMWare Workstation ProSVN

eRABuild MSBuild 15.0eRAServer IIS

SQL Server Management Studio 2016Microsoft Web Deploy 3.6

eRATest eRASmartCardRobot Framework 3.0.2InterfaceTesterTool

4.3.1 eRAPublish

eRAPublish on palvelimena toimiva fyysinen tietokone. Sillä on kolme päätehtävää:

• Jenkinsin pyörittäminen

• virtuaalikoneiden pyörittäminen

• eRAan liittyvien projektien tiedostojen päivittäminen ja jakaminen sisäverkossa.

eRAPublishin tärkein tehtävä on Jenkinsin pyörittäminen. Jenkinsin asennusohjelma la-dataan sen web-sivujen kautta, jonka avulla Jenkins saadaan asennettua tietokoneelle.Jenkins pyörii eRAPublishilla localhostina eli se käyttää samaa IP-osoitetta kuin eRA-Publish, mutta Jenkinsille on varattu oma porttinumero. Täten Jenkinsiin pääsee käsiksikaikilta yrityksen verkossa olevilta koneilta. Vahinkojen ja väärinkäyttöjen estämiseksiainoastaan sisäänkirjautuneet käyttäjät voivat suorittaa tehtäviä manuaalisesti ja muokatakonfiguraatiota.

Virtuaalikoneet pyörivät eRAPublishin sisältämällä virtuaalikonemonitori VMWarella,jossa ne suorittavat vain niille ominaisia tehtäviä. Niille on annettu tarpeen mukaan re-sursseja, kuten suoritettavien tehtävien edellyttämiä ohjelmistoja. Jokainen virtuaalikoneon asetettu pysymään päällä koko ajan, joten ne ovat aina käytettävissä.

Projekteihin liittyy tiedostoja, joiden jakaminen on tarpeellista eRAPublishin ja virtuaali-koneiden kesken. VMWaren avulla on luotu jaettu hakemisto eRAPublish-koneelle, johonvirtuaalikoneet pääsevät käsiksi. Jaettu hakemisto sisältää hakemistot jokaiselle projek-tille, demoympäristön alustuksessa tarvittaville tiedostoille, käyttöliittymätestien projek-tille, rajapintatestaustyökalulle sekä käyttöliittymätestien että rajapintatestien tuloksille.Tiedostot ovat peräisin SVN:n eri säilytyspaikoista (repository), joista tiedostot päivite-tään jaettuun hakemistoon liukuhihnan suorituksen alussa.

eRAPublishiin voidaan ottaa yhteys RDP:llä (Remote Desktop Protocol, suom. etätyö-pöytäyhteys). RDP tarjoaa etäisen näytön ja ohjauksen Windows-käyttöjärjestelmien kes-ken, jotka sijaitsevat samassa verkossa. RDP on suunniteltu tukemaan erilaisia verkko-topologioita ja lähiverkon protokollia [36]. Vain ylläpitäjien täytyy pystyä yhdistämään

30

eRAPublishiin RDP:llä, joten yhdistäminen edellyttää autentikointia. Koska eRAPublish-illa pyörivää Jenkinsiä pystyy käyttämään HTTP-rajapinnan kautta, RDP:n käyttäminenon tarpeellista vain silloin, kun itse eRAPublishilla tai sen virtuaalikoneilla täytyy tehdämuutoksia.

4.3.2 eRABuild

eRABuild on virtuaalikone, jonka tehtävä on toimia kääntämisympäristönä eri projekteil-le. Se toimii vain sisäverkossa, koska sillä ei ole koskaan tarvetta päästä ulkoverkkoon.

eRABuildille on asennettu kääntämistyökalu MSBuild 15.0. Kehitysvaiheessa eRAn pro-jekteissa käytetään integroitua ohjelmointiympäristöä nimeltään Visual Studio, joka it-sessään hyödyntää MSBuildia projektia käännettäessä. Ympäristössä ei ole kuitenkaantarvetta Visual Studiolle asentamiselle, koska se veisi turhaan muistia ja kääntäminen on-nistuu suoraan MSBuildilla, joka ei ole riippuvainen Visual Studiosta. Siten MSBuildillavoidaan kääntää sekä project- että solution-tyyppisiä tiedostoja ympäristössä, jossa VisualStudio ei ole asennettuna [33]. Projektitiedostot ovat XML-pohjaisia (Extensible MarkupLanguage, rakenteellinen kuvauskieli) tiedostoja, joiden avulla voidaan määrittää eri ase-tuksia kääntämiselle. MSBuildiä pystyy ajamaan suoraan komentoriviltä, jolloin esimer-kiksi käännöksen tiedot päivittyvät Jenkinsin lokeihin kätevästi. Lisäksi komentoriviltäajettaessa MSBuildille pystyy syöttämään kääntämiseen vaikuttavia parametreja.

4.3.3 eRAServer

eRAServer on virtuaalikone, joka toimii demoympäristönä. Sen tarkoituksena on matkiatuotantoympäristöä mahdollisimman tarkasti, jotta voitaisiin varmistaa palvelun toimi-vuus ja arvioida, miten palvelu ilmenee loppukäyttäjillä. Täten eRAServerille on asen-nettu sama käyttöjärjestelmä ja samoja ohjelmistoja kuin mitä tuotantoympäristössä käy-tetään. eRAServerillä on yhteys ulkoverkkoon, koska osa eRATest-koneelta ajettavistatesteistä vaatii HTTP-pyyntöjen lähettämistä ulkoverkkoon ja viestien vastaanottamistaulkoverkosta.

eRAServerille on asennettu Microsoft Web Deploy 3.6, jolla voidaan tuottaa web-sovel-luksia ja -sivustoja IIS-palvelimille [48]. Visual Studio käyttää Web Deployta, mutta WebDeployta pystyy käyttämään myös suoraan komentorivin kautta. Kuten MSBuildin ta-pauksessa, Visual Studiota ei ole tarpeellista asentaa virtuaalikoneelle vastaavista syistä.

eRAServerille on asennettu IIS (Internet Information Services), joka on Windows Ser-ver -käyttöjärjestelmille tarkoitettu joustava, turvallinen ja helposti käsiteltävä palvelin-ohjelmisto, jolla voidaan tarjota palveluita verkossa. Se pystyy skaalautuvan ja avoimenarkkitehtuurinsa ansiosta käsittelemään monia tehtäviä, kuten median suoratoistoa sekäweb-sovellusten ylläpitoa [24]. IIS:ään pystyy lisäämään sivustoja, jolloin niille asetetaannimet, fyysinen polku (physical path), IP-osoite sekä porttinumero. Fyysinen polku tar-koittaa hakemistoa, jonne tuottamisvaiheessa luodaan tarvittavat tiedostot. eRAlle ja sen

31

simulaattoreille luotiin sivut omilla porttinumeroillaan ja fyysisilla poluillaan. Sivujen IP-osoitteiksi asetettiin localhost, eli ne pyörivät paikallisesti eRAServer-koneella.

Lisäksi eRAServerille on asennettu tietokantaohjelmisto SQL Server Management Studio2016. Se on integroitu ympäristö, jossa voidaan käsitellä, konfiguroida, hallita ja kehit-tää eri SQL-infrastruktuureja (Structured Query Language). Se tarjoaa kattavan työkalun,jossa on lukuisia graafisia työkaluja skriptieditoreineen. Siten SQL Server soveltuu kai-kentaitoisille kehittäjille sekä tietokantojen hallinnoijille [38]. Demoympäristön alustuk-sen yhteydessä jokaiselle projektille luodaan tietokannat, jonne alustetaan tarvittavat tie-tokantataulut. Projektin eRA tietokanta sisältää kymmeniä tauluja, joihin muun muassasisältyvät taulu palvelutapahtumille, rekisteröidyille käyttäjille ja koodistoille. Projektitovat yhteydessä niille ominaisiin tietokantoihin, ja eri toimenpiteiden yhteydessä tieto-kantoihin lisätään tietoa. Esimerkiksi eRAssa uuden istunnon aloittamisen seurauksenaSystemSessions-tauluun lisätään rivi, joka sisältää tietoa kyseisestä istunnosta. Projekteis-sa hyödynnetään tietokannassa olevaa tietoa kooditasolla. Muun muassa eRAan kirjau-tuessa tutkitaan, onko kirjautuneelle käyttäjälle olemassa keskeneräistä istuntoa.

4.3.4 eRATest

eRATest on virtuaalikone, jolla suoritetaan sekä käyttöliittymä- että rajapintatestausta.Muista virtuaalikoneista poiketen Jenkins-agentti käynnistetään komentorivin kautta eRA-Test-koneella. Se on välttämätöntä, koska käyttöliittymätestit vaativat selaimen ja eRA-SmartCard-ohjelmiston ikkunoiden olevan manipuloitavissa eRATestin käyttöliittymänkautta. Agentin käynnistäminen onnistuu suorittamalla alla oleva batch-komento.

java -jar C:\Jenkins\slave.jar -jnlpUrl http://eRAPublish:8080/computer

/eRATest/slave-agent.jnlp

eRATest-koneelle on asennettu yrityksellä kehitetty eRASmartCard-toimikortinlukijaoh-jelmisto, jota käytetään eRA-palvelussa sekä sisäänkirjautumiseen että sähköiseen al-lekirjoitukseen. Testejä varten luotu testikortti on yhdistettynä toimikortinlukijaan, jo-ka puolestaan on yhdistettynä fyysiseen eRAPublish-palvelimeen. Virtuaalikonemonitoripuolestaan tarjoaa ajurin kortinlukijalle, jonka avulla lukija on käytettävissä eRATest-koneella. Toimikorttia on välttämätöntä käyttää, sillä käyttöliittymätestit sisältävät lukui-sia kohtia, joissa eRA vaatii joko sisäänkirjautumista tai sähköistä allekirjoitusta.

Kohdejärjestelmälle suoritetaan sekä käyttöliittymä- että rajapintatestausta liukuhihnanviimeisissä vaiheissa. Molemmat testaukset suoritetaan demoympäristössä sen jälkeen,kun ohjelmisto on tuotettu kyseiseen ympäristöön, tietokannat on nollattu ja ympäristöon alustettu toimintakuntoon. Testausten lopputuloksina syntyvät raportit, joiden pohjaltatehdään päätös, julkaistaanko ohjelmisto tuotantoon loppukäyttäjille.

32

4.4 Liukuhihnan suoritus

Jatkuva toimitus eRAssa perustuu Jenkinsillä luodun Master-nimisen liukuhihnan sään-nölliseen suorittamiseen pääpalvelimella. Liukuhihna ei itsessään suorita jokaista vaihet-ta, vaan se kutsuu lisäksi muita tarvittavia tehtäviä ja liukuhihnoja. Master-liukuhihnasuoritetaan jokaisen päivän vaihtuessa, ja sitä tai sen sisältämiä liukuhihnoja voidaan suo-rittaa tarpeen mukaan manuaalisesti. Liukuhihna tuottaa tuloksia sen vaiheista pitkin suo-ritusta, ja sen päättyessä saadaan lopputulos liukuhihnan kokonaisvaltaisesta onnistumi-sesta. Liukuhihna sisältää niin sekventiaalista kuin rinnakkaista tehtävien suoritusta. Tau-lukossa 4.3 on esitetty liukuhihnat ja tehtävät, joita suoritetaan jatkuvan toimituksen ai-kana.

Taulukko 4.3. Liukuhihnat ja tehtävät, joita suoritetaan eRAn toimittamisen aikana.

Nimi Lyhyt kuvaus KategoriaMaster Suorittaa jatkuvalta toimitukselta edellytetyt toimenpiteet LiukuhihnaeRA Päivittää, kääntää ja tuottaa eRAnSimArkisto Päivittää, kääntää ja tuottaa SimArkistonSimReseptikeskus Päivittää, kääntää ja tuottaa SimReseptikeskuksenSimValvira Päivittää, kääntää ja tuottaa SimValviranInitializeInterfaceTester Päivittää ja kääntää rajapintatestaussovelluksenDropDatabases Tyhjentää ympäristön tietokannatBuild Kääntää projektin TehtäväDeploy Tuottaa projektin demoympäristöönDropDatabase Tyhjentää tietokannanGUITest Suorittaa käyttöliittymätestitInitializeDatabase Alustaa tietokannat ja demompäristönInterfaceTest Suorittaa rajapintatestitResetIIS Käynnistää IIS:n uudelleenUpdate Päivittää projektin tiedostot

Kuvassa 4.3 on esitetty liukuhihnojen suoritus jatkuvassa toimituksessa. Siinä suorakai-teet edustavat liukuhihnoja ja ellipsit liukuhihnojen sisältämiä vaiheita. Vaiheiden sisältä-mistä askeleista aloitetaan muiden liukuhihnojen ja tehtävien suoritus. Liukuhihnalla suo-ritetaan ensin projektikohtaiset liukuhihnat rinnakkain. Projektikohtaisilla liukuhihnoil-la suoritetaan kunkin projektin päivitys, kääntäminen ja demoympäristöön tuottaminen.Rajapintatestaussovelluksen alustamisessa riittää pelkästään projektin päivitys ja kääntä-minen, koska se ei ole tuotettava web-palvelu. Käyttöliittymätestien ja demoympäristönalustuksessa tarvittavat tiedostot päivitetään, mutta niiden yhteydessä ei ole mitään kään-nettävää eikä tuotettavaa ohjelmaa. Jos jokainen rinnakkaisista vaiheista saadaan suoritet-tua onnistuneesti, liukuhihnalla edetään tietokantojen tyhjentämiseen ja sen jälkeen de-moympäristö alustetaan toimintakuntoon. Viimeiseksi suoritetaan rajapinta- ja käyttöliit-tymätestausta.

Liukuhihnojen arkkitehtuuri koki muutoksia toteuttamisen aikana. Aluksi luotiin vain yk-si pitkä liukuhihna, jonka tarkoitus oli suorittaa kaikki jatkuvassa toimituksessa vaadi-tut toimenpiteet. Koodin määrän kasvaessa sekä ylläpidettävyyden hankaloituessa huo-mattiin, että koodia on järkevä hajauttaa projektikohtaisesti, joten jokaiselle projektille

33

Kuva 4.3. Liukuhihnojen suoritus eRAn toimituksessa.

luotiin oma liukuhihna. Silloin kuitenkin havaittiin, että monissa liukuhihnoissa suoritet-tiin samankaltaisia toimenpiteitä, kuten tiedostojen päivittämistä ja ohjelman kääntämistä.Täten kyseiset toimenpiteet vietiin erillisiksi tehtäviksi, joita kutsutaan projektien liuku-hihnoilla projektikohtaisia parametreja käyttäen. Liitteissä A ja B on esitetty sekä Master-että eRA-liukuhihnojen toteutukset. Muiden liukuhihnojen toteutuksia ei esitetä, koska neovat hyvin samankaltaisia ja turhan yksityiskohtaista tietoa työn kannalta.

Batch-komennoissa esiintyvät muuttujat ja niiden merkitykset on esitetty taulukossa 4.4.Muuttujat edustavat tarvittavien tiedostojen polkuja ja hakemistoja, joita käsitellään batch-komennoissa. Muuttujille asetetaan arvot batch-komennoissa ennen varsinaisen tehtävänsuorittamista. Luonnollisesti on mahdollista kirjoittaa muuttujien arvot suoraan komen-toihin, mutta muuttujien avulla komentoja on helpompi lukea. Itse muuttujien arvoja eiole esitetty, koska ne olisivat turhan yksityiskohtaista tietoa työn kannalta.

34

Taulukko 4.4. Muuttujat batch-komennoissa.

Komento Muuttuja MerkitysUpdate SVN Svn-ohjelman polkuBuild MSBUILD MSBuild-ohjelman polkuDeploy DEPLOY_PATH Microsoft Web Deploy -ohjelman polkuInterfaceTest TOOL_PATH Komentorivityökalun polku

TESTCHAIN_PATH Testiketjujen polkuCONFIG_PATH Konfiguraatiotiedoston polkuERROR_DATABASE_PATH Paikallisen virhetietokannan polkuOUTPUT_PATH Testaustulosten polku

4.4.1 Päivittäminen, kääntäminen ja tuottaminen demoympäris-töön

Update on eRAPublish-koneella suoritettava tehtävä, joka päivittää tietyssä hakemistossasijaitsevat tiedostot. Se ottaa parametrina päivitettävän polun (updatePath) ja päivittää sensisältämät tiedostot alla esitetyn komennon mukaisesti.

"%SVN%" update "%updatePath%" --non-interactive --no-auth-cache --

username erabuilder --password ********

Koska projektien tiedostot sijaitsevat versionhallintajärjestelmä SVN:ssä, kohdehakemis-tolle suoritetaan komento svn update. Päivittäminen vaatii autentikointia, joten komennonparametreina syötetään yleiseen tarkoitukseen suunnitellut käyttäjätunnus ja salasana. Ko-mentoa voidaan kutsua mille tahansa polulle, mutta työn kontekstissa jokainen päivitet-tävä polku sijaitsee virtuaalikonemonitorin kautta jaetussa kansiossa. Jos päivitys epäon-nistuu esimerkiksi koodikonfliktien takia, komento palauttaa virhekoodin ja liukuhihnansuoritus keskeytyy. Päivittämisen onnistuessa voidaan jatkaa kääntämiseen.

Build on eRABuild-virtuaalikoneella suoritettava tehtävä, joka kääntää projektin hyödyn-tämällä MSBuild-käännöstyökalua ja julkaisuprofiilia (publish profile). Tehtävä ottaa pa-rametreinaan projektitiedoston hakemiston (projectFilePath), projektitiedoston nimen il-man tiedostopäätettä (projectFileName) sekä julkaisuprofiilin nimen ilman tiedostopää-tettä (profile) alla esitetyn komennon mukaisesti.

"%MSBUILD%" "%projectFilePath%\%projectFileName%.csproj" /P:

DeployOnBuild=true /P:PublishProfile="%projectFilePath%\Properties\

PublishProfiles\%profile%.pubxml"

Julkaisuprofiilitiedosto on XML-pohjainen tiedosto, jolla voidaan määrittää monia eriasetuksia käännökselle. Projektin profiilitiedostoissa määritellään muun muassa polku

35

käännöksen tuottamille tiedostoille, IIS-sivuston nimi, tietokanta-asetukset sekä web-kon-figuraatiot. Käännös tuottaa muun muassa zip-paketin ja parametritiedoston. Paketti si-sältää sivuston tuottamiseen tarvittavat tiedostot, kuten käännöksiä, tietokantaskriptejä jaresursseja. Parametritiedostossa voidaan asettaa arvoja eri asetuksille, jotka vaikuttavatweb-sovelluksen tuottamiseen Microsoft Web Deployta käytettäessä [30]. Projektien pa-rametritiedostoissa on annettu yhteysmerkkijonoja (connection string), joiden avulla si-vustot saavat yhteyden tarvitsemiinsa tietokantoihin.

Deploy on eRAServer-virtuaalikoneella suoritettava tehtävä, jolla projekti saadaan tuotet-tua demoympäristöön. Tuottaminen onnistuu käyttämällä Microsoft Web Deploy -työkaluakomentorivin kautta. Parametrina profile annetaan käännöksen tuottamien tiedostojen pol-ku, jossa sijaitsevat sekä zip-paketti että parametritiedosto. Parametrina project puoles-taan annetaan kyseisten tiedostojen nimi ilman tiedostopäätteitä. Tiedostojen nimi vastaatuotettavan projektin nimeä, joten se on sama kummassakin tiedostossa. Alla on esitettykomento, joka suoritetaan tehtävän aikana.

"%DEPLOY_PATH%" -verb:sync -source:package="%profile%\%project%.zip" -

dest:auto,includeAcls="False" -setParamFile:"%profile%\%project%.

SetParameters.xml"

Komennossa tietolähteeksi määritellään profiilin zip-paketti, joka luotiin kääntämisen yh-teydessä. Komentoon syötetään parametritiedoston polku, jossa sijaitsevasta parametritie-dostosta luetaan tuottamiseen vaikuttavia asetuksia. Onnistuneen tuottamisen seuraukse-na IIS:n fyysisen polun tiedostot päivittyvät ajan tasalle, jolloin muutokset ovat suoraannähtävissä IIS:n pyörittämillä sivustoilla.

4.4.2 Tietokantojen tyhjentäminen

DropDatabase on eRAServer-virtuaalikoneella suoritettava tehtävä, jolla voidaan tyhjen-tää tietty tietokanta. Se ottaa parametrina database tyhjennettävän tietokannan nimen allaesitetyn komennon mukaisesti.

sqlcmd -U sa -P ******** -S .\ERADATABASE -Q "alter database [%database

%] set single_user with rollback immediate; drop database [%

database%]"

Tehtävässä hyödynnetään tietokantatyökalua nimeltään sqlcmd, jolle voidaan syöttää Trans-act-SQL-lauseita, proseduureja ja skriptejä eri muodoissa [41]. Komentoon syötetään se-kä tietokannan käyttäjätunnus että käyttäjäkohtainen salasana. Komennossa yhdistetään

36

SQL Serverin instanssiin nimeltä .\ERADATABASE. Lisäksi komennossa voidaan määri-tellä yksi tai useampi suoritettava tietokantaproseduuri. Proseduurilla alter database voi-daan muokata tietokannan tiettyjä konfiguraatioasetuksia. Tietokanta asetetaan tilaan, jos-sa vain yksi käyttäjä kerrallaan voi käyttää tietokantaa. Jos komentoa ei voida suorittaaheti, muut samanaikaiset tietokantamuutokset perutaan rollback immediaten ansiosta.

DropDatabases on eRAServer-virtuaalikoneella suoritettava liukuhihna. Se suorittaaDropDatabase-tehtävän jokaiselle kohdejärjestelmän tietokannalle, eli tyhjentää tietokan-nat eRADatabase, SimArkisto, SimReseptikeskus, SimValvira, SupportDatabase ja Vali-dationDatabase. Lopuksi kutsutaan tehtävää ResetIIS, joka suorittaa komennon iisreseteRAServerillä, eli käynnistää IIS:n uudelleen.

4.4.3 Demoympäristön alustus

Demoympäristön alustuksessa ja käyttöliittymätestauksessa käytetään testiautomaatioke-hystä nimeltä Robot Framework, joka soveltuu sekä hyväksymistestaukseen että hyväk-symistestivetoiseen kehitykseen (Acceptance Test-Driven Development, ATDD). Se hyö-dyntää helppokäyttöistä tabulaattoripohjaista syntaksia, ja siinä voidaan suorittaa testita-pauksia, jotka puolestaan voivat hyödyntää geneerisiä avainsanoja (keyword). Kehys onlaajennettavissa Python- ja Java-pohjaisilla testikirjastoilla. Esimerkiksi kohdejärjestel-män testeissä käytetään kirjastoa nimeltään Selenium2Library, joka soveltuu web-sovel-lusten testaamiseen. Testitapauksia luodessa on mahdollista luoda korkean tason avainsa-noja, jotka rakentuvat jo olemassa olevien avainsanojen päälle. [37]

InitializeDatabase on eRATest-virtuaalikoneella suoritettava tehtävä, jolla tietokannat alus-tetaan testausta varten. Se perustuu Robot Frameworkin robot-testitiedoston suorittami-seen. Alustuksessa suoritetaan kaikki testauksen kannalta tarpeelliset tehtävät, kuten käyt-täjien ja koodistojen lisäämiset sekä ylläpitotehtävät. Vaikka Robot Framework on tarkoi-tettu hyväksymistestaukseen, se soveltuu myös web-käyttöliittymän manipulointiin muil-lakin tarkoituksilla, kuten tässä tapauksessa asetusten hallintaan käyttöliittymän kautta.

4.4.4 Käyttöliittymätestaus

Käyttöliittymätestauksessa suoritetaan eRAa varten luotuja käyttöliittymätestejä. Testiton suunniteltu siten, että niissä testataan yksityiskohtaisesti testin mukaisessa näkymäs-sä esiintyviä elementtejä. Testit sisältävät usein myös HTTPS-rajapinnan yli kommuni-kointia muun muassa simulaattoreiden kanssa, joten käyttöliittymätestit soveltuvat osit-tain myös rajapintatestaukseen.

Ohjelmassa 4.1 on esimerkki robot-testitiedostosta, jossa on kaksi testitapausta sisäänkir-jautumiselle. Testitiedoston alussa on asetukset, jossa muun muassa määritellään käytet-tävät kirjastot sekä resursseja ja muuttujia sisältävät tiedostot. Lisäksi asetuksissa mää-ritellään testitapausta edeltävät ja sen jälkeiset toimenpiteet. Tiedostossa voidaan myös

37

*** Settings ***Library Selenium2Library run_on_failure=NothingLibrary ../Resources/keywordsLogin.pyResource ../Resources/keywordsLogin.robotVariables ../Resources/doctorRelatedVariables.pyVariables ../resources/commonVariables.pyTest Setup Open Browser ${site_url} ${browser}Test Teardown Run Keyword If Test Failed Close SessionSuite Teardown Close BrowserForce Tags Login

*** Variables ***${occupation_description} 001 laillistettu lääkäri${degree_code} 76111-222 lääketieteen lisensiaatti

*** Test Cases ***Cancelled Login

Default Login TaskPress When Displayed buttonCancelLoginWait Element buttonLoginClose Browser

Login Independent User[Tags] IAHDefault Login TaskPress When Displayed buttonLoginAsIndependentUserValidate User Informations ${occupation_description} ${degree_code}Log User Out

Ohjelma 4.1. Esimerkki Robot Frameworkin testitiedostosta, jolla tutkitaansisäänkirjautumista.

määritellä paikallisia muuttujia. Testitapauksille voidaan merkitä tunnisteita (tag), jolloinvoidaan ajaa joukko testitapauksia tietyllä tunnisteella. Kuvan 4.1 esimerkkiohjelmassaei ole erikseen luotu avainsanoja, mutta siinä käytetään keywordsLogin.robot-tiedostossamääriteltyjä avainsanoja, kuten esimerkiksi avainsanaa Default Login Task.

GUITest on eRATest-virtuaalikoneella suoritettava tehtävä, joka suorittaa käyttöliittymä-testit järjestelmälle testauskategorioittain. Windowsilla testit ajetaan batch-komennollacall robot, jota tehtävässä kutsutaan jokaiselle testauskategorialle. Jokaisesta kategoriastasyntyy XML-pohjainen testausraportti, jotka testien ajamisen jälkeen yhdistetään yhdeksiXML-tiedostoksi käyttämällä Robot Frameworkin tarjoamaa työkalua nimeltä rebot. Lo-puksi kutsutaan Pythonilla toteutettua raportointityökalua reporter.py, joka luo yhdistetynXML-tiedoston perusteella kompaktin testausraportin PDF-muotoisena.

4.4.5 Rajapintatestaus

Rajapintatestauksessa käytetään yrityksellä kehitettyä rajapintatestaustyökalua nimeltäänInterfaceTesterTool. Se on komentorivisovellus, joka suorittaa sille syötettyjä XML-poh-jaisia testitiedostoja. Työkalu on haarautettu jo pidempään kehitetystä käyttöliittymäso-velluksesta nimeltään InterfaceTester, mutta kummatkin sovellukset käyttävät samoja tie-

38

<test><description>Ping</description><arrangements>

<users><user type="doctor" />

</users><organizations>

<organization type="public_healthcare" /></organizations><system_clients>

<system_client type="organization" /></system_clients>

</arrangements><statement_list>

<function_call><name>Ping</name><expected_result_list>

<expected_result><status>200</status>

</expected_result></expected_result_list>

</function_call></statement_list>

</test>

Ohjelma 4.2. Esimerkki rajapintatestitiedostosta, jolla testataan työkalun ja eRAnvälistä yhteyttä.

tomalleja. Haarautus oli käytännössä välttämätöntä, koska Jenkinsin kautta on huomatta-vasti kätevämpää suorittaa muutama batch-komento kuin manipuloida erillistä käyttöliit-tymäsovellusta testien ajamiseksi.

Ohjelmassa 4.2 on esitetty esimerkki yksinkertaisesta testitiedostosta, jonka avulla testa-taan työkalun ja eRAn välistä HTTPS-yhteyttä. Lohkossa arrangements asetetaan lähtö-tiedot tiedoston testeille, kuten käyttäjän, organisaation sekä asiakasjärjestelmän tyypit.Lohkon statement_list sisällä määritellään järjestyksessä suoritettavat konfiguraatiomuu-tokset ja funktiokutsut. Funktiokutsujen lohkoihin määritellään kutsuttavan funktion nimija listataan odotetut paluuarvot. Työkalu lähettää eRAlle HTTP POST -pyynnön funk-tion nimen perusteella, jolloin eRA käsittelee pyynnön ja palauttaa vastauksen työkalulle.Vastauksen paluuarvoa verrataan testitiedossa määriteltyihin odotettuihin paluuarvoihin,josta määräytyy funktiokutsun onnistuminen. Monien funktiokutsujen yhteydessä eRAlähettää HTTP-pyyntöjä simulaattoreille ja odottaa tiettyjä paluuarvoja. Täten yhden tes-tiketjun suorituksen aikana voidaan testata montaa eri rajapintaa.

39

InterfaceTest on eRATest-virtuaalikoneella suoritettava tehtävä, joka suorittaa rajapinta-testit järjestelmälle. Alla on esitetty tehtävässä ajettava batch-komento.

"%TOOL_PATH%" --testChainPath "%TESTCHAIN_PATH%" --configurationPath "%

CONFIG_PATH%" --errorCodeDatabasePath "%ERROR_DATABASE_PATH%" --

serverAddress https://192.168.2.12:44300/ --databaseERA "

eRADatabase" --connectionStringERA "Data Source=192.168.2.12,1433;

Initial Catalog={0};Integrated Security=SSPI;" --outputPath "%

OUTPUT_PATH%"

Testaustyökalulle voidaan asettaa monia eri asetuksia, mutta Jenkinsin kautta ajettava teh-tävä ei ole määritelty ottamaan parametreja vastaan. Työkalu etsii suoritettavia testitie-dostoja syötetystä hakemistosta ja sen alihakemistoista. Hakemistossa voi esiintyä myösmuitakin tiedostoja, jotka työkalu erottaa itse testien joukosta. Hakemistossa voi myösesiintyä testejä, joita ei kuulu ajaa jatkuvan toimituksen yhteydessä. Sellaisia testejä ovatesimerkiksi käyttäjän vuorovaikutusta vaativat testit sekä tulevia rajapintaversioita var-ten laaditut testit. Ohitettavat testitiedostot sisältävät kentät, joissa mainitaan syy testinohittamiselle.

Konfiguraatiotiedostossa voidaan asettaa yleisiä asetuksia, joita kaikki suoritettavat testitkäyttävät. Sellaisia ovat esimerkiksi testeissä hyödynnettävien palvelimien IP-osoitteet,testikäyttäjät sekä organisaatiot. Virhetietokanta on tiedosto, joka sisältää tietoa virhekoo-deista, joita eRA voi palauttaa HTTP-vastauksissa. Lisäksi tiedosto sisältää ohjeita sille,kuinka työkalun pitää toimia kyseisten virheiden tapauksissa, koska eRAlta vastaanotettuvirhe ei saa aina johtaa testin epäonnistumiseen. Komennolle voidaan antaa parametrei-na myös oletusosoite, käytettävän tietokannan nimi sekä yhteysmerkkijono, jonka avullatyökalu pystyy yhdistämään eRAn tietokantaan. Työkalu luo testaustulokset komennossamääriteltyyn polkuun. Testaustuloksina syntyy kattava lokitekstitiedosto sekä kompaktitestausraportti PDF-muodossa.

40

5. ARVIOINTI JA JATKOKEHITYS

Toteutettua jatkuvan toimituksen liukuhihnaa on suoritettu säännöllisesti sen valmistumi-sesta lähtien. Liukuhihna on tuottanut melko yhteneväisiä tuloksia suorituskertojen kes-ken niin ajankäytön kuin testaustulosten osalta.

Liukuhihnan suorittamien vaiheiden kestot on saatu kerättyä Jenkinsin käyttöliittymäs-tä. Testaustulokset on koostettu käyttöliittymätesteissä käytetyn Robot Frameworkin jarajapintatestaustyökalun tuottamista testausraporteista.

5.1 Tulokset

Taulukossa 5.1 on esitetty jatkuvan toimituksen suorittavan Master-liukuhihnan vaihei-siin kuluneet ajat. Koska osa vaiheista ajettiin rinnakkain, kokonaisaika on pienempi kuinvaiheiden kestojen summa. Kestoista havaitaan, että liukuhihnan alkupään vaiheet vievätvähän aikaa, mutta demoympäristön alustaminen ja testaus vievät suurimman osan ajas-ta. Käyttöliittymätestaus vie vajaan 90 prosenttia koko liukuhihnan suorituksen kestosta,ja rajapintatestaus vajaan 10 prosenttia. Käyttöliittymätestaus vie noin yhdeksänkertaisenajan rajapintatestaukseen nähden, vaikka käyttöliittymätestejä on vain noin kaksi kertaaenemmän kuin rajapintatestejä. Se selittyy sillä, että jokaisen käyttöliittymätestin aikanasuoritetaan enemmän toimintoja, ja käyttöliittymän manipuloinnissa esiintyy viivettä au-tomatiikan hyödyntämisestä huolimatta. Lisäksi virhetilanteista toipuminen vie käyttöliit-tymätesteissä enemmän aikaa, koska virheen havaitsemisessa on viivettä ja testin lopetusvaatii erillisten toimenpiteiden suorittamista.

Taulukko 5.1. Master-liukuhihnan vaiheisiin kuluneet ajat.

Vaihe KestoeRA 2min 52sSimArkisto 1min 40sSimReseptikeskus 1min 30sSimValvira 1min 24sUpdateDataFiles 9sInitializeGUITester 10sInitializeInterfaceTester 1min 32sDropDatabases 1min 28sInitializeDatabase 24min 30sInterfaceTests 57min 42sGUITest 8h 50minMaster-liukuhihnan kesto 10h

Taulukossa 5.2 on esitetty käyttöliittymätestien tulokset. Testillä voi olla monta tunnistet-ta, eli testien yhteiskesto on lyhyempi kuin tunnisteittain tarkasteltavien testien kestojen

41

summa. Suurin osa epäonnistumisista johtuu ongelmasta, jossa SimArkisto väittää suori-tetun allekirjoituksen olevan virheellinen. Virhe toistuu satunnaisesti eri testeissä demo-ympäristössä ajettaessa, mutta ongelma ei ilmene suoritettaessa testejä paikallisesti omal-la koneella. Ongelmaa on tutkittu, mutta sitä ei ole toistaiseksi saatu ratkaistua. Suuriosa hammaspuolen testeistä epäonnistui käyttöliittymätestauksen aikana. Hammaspuolenkäyttöliittymät ovat olleet viimeaikaisen kehityksen kohteena, jonka seurauksena kyseisettestit eivät ole pysyneet ajan tasalla. Kaiken kaikkiaan epäonnistuneiden testien määrä onkohtalaisen pieni, ja monet sekä niistä että eRAn ongelmista pitäisi olla melko nopeastikorjattavissa.

Taulukko 5.2. Käyttöliittymätestien tulokset tunnisteittain.

Tunniste Yhteensä Onnistuneet Epäonnistuneet Kesto (hh:mm:ss)Kaikki 193 163 30 08:45:35Archive 76 71 5 03:03:33Certificate 21 21 0 00:54:20Combination 7 7 0 00:33:50Dental 36 18 18 02:23:26Doctor 63 55 8 03:19:28IAH 16 15 1 00:25:25Login 12 12 0 00:02:52MediNurse 30 30 0 01:20:49Nurse 18 17 1 00:45:15Osva 4 0 4 00:06:29Patient 11 9 2 00:31:55PracticalNurse 2 2 0 00:01:36Prescription 9 9 0 00:49:59Private 82 69 13 03:55:45Private Doctor 17 11 6 00:22:13Prohibition 9 9 0 00:10:28Public 64 63 1 02:55:01Renewal 4 4 0 00:01:12RenewalTest 7 6 1 00:07:51Student 30 25 5 01:23:13Tab Visibility 1 1 0 00:00:52Vaccination 1 1 0 00:03:05

Taulukoissa 5.3 ja 5.4 on esitetty rajapintatestien tulokset. Rajapintatesteistä epäonnistuinoin puolet, mikä on kohtuuttoman paljon. Projektin rajapintatestaustyökalua aloitettiinkehittämään noin 2,5 vuotta sitten, mutta kehitys ei ole ollut kokoaikaista. Lisäksi työ-kalua on hyödynnetty neljän eri eRA-rajapintaversion kanssa, ja testit ovat osittain riip-puvaisia rajapintaversiosta. Rajapintatestejä ei ole ajettu automatisoidusti ennen jatkuvantoimituksen liukuhihnaa, joten osa testeistä on huomaamatta muuttunut toimimattomiksiprojektien edetessä. Testien epäonnistuminen ei ole itsessään liukuhihnan vika, vaan onpikemminkin arvokasta, että liukuhihna tuottaa täsmälliset testaustulokset säännöllisesti.Lisäksi projektien rajapinnoissa on lukuisia puutteita, eli monet rajapintatestit tuottavatvirheitä ja varoituksia aiheellisesti.

Liukuhihnalla suoritetut tehtävät kestävät käytännössä yhtä kauan kuin paikallisessa ke-hitysympäristössäkin. Liukuhihnalla ei kuitenkaan esiinny merkittävää viivettä tehtävienvaihtumisen ohella, joten liukuhihnan suorittaminen kokonaisuudessaan on nopeampaa

42

Taulukko 5.3. Rajapintatestien tulokset.

Testit yhteensä Onnistuneettestit

Epäonnistuneettestit

Testit va-roituksilla

Ohitetuttestit

Virheet Varoitukset

103 46 38 39 19 2259 13763

Taulukko 5.4. Rajapintatestien tulokset kategorioittain.

Kategoria Onnistuneettestit

Epäonnistuneettestit

Ohitetuttestit

Virheet Varoitukset

Archive 12 21 10 1072 8443Authorization 0 2 0 502 0Common and prescription 13 3 1 37 789Dental 18 7 0 628 4525eRAImageServer 0 0 4 0 0Prescription 0 3 0 11 4Security 1 0 2 0 0Signed request 0 1 0 4 0Test chains 1 0 2 0 2Test command 1 1 0 5 0

kuin tehtävien suorittaminen putkeen manuaalisesti. Lisäksi liukuhihna voidaan käynnis-tää ajastetusti, jolloin se voidaan suorittaa säännöllisesti ilman turhaa vaivannäköä. Liu-kuhihna voidaan suorittaa työajan ulkopuolella, jolloin se ei vie resursseja keskellä työ-päivää. Käytännössä työajan ulkopuolella suorittamisesta ei ole toistaiseksi merkittäväähyötyä, koska Jenkinsiä ei muutenkaan käytetä muihin tarkoituksiin työpäivän aikana.Jatkossa kuorman tasaaminen voi tulla tarpeeseen, mikäli ympäristössä aiotaan suorittaamuitakin toimenpiteitä.

Liukuhihnan mahdollistaman automaation myötä kattavaa käyttöliittymä- ja rajapintates-tausta suoritetaan nykyään päivittäin, jolloin palvelun laadukkuutta pystytään arvioimaansäännöllisesti. Testien tulokset voivat poiketa toisistaan demoympäristön ja paikallistenkehitysympäristöjen välillä, jolloin testeistä voidaan löytää puutteita. Automaatiota hyö-dyntämällä koko testisarjaa ei tarvitse ajaa yhtä usein paikallisesti eri kehitysympäristöis-sä, mikä johtaa ajan ja resussien säästämiseen. Automaation ansiosta ohjelmointivirheetovat löydettävissä nopeammin, jolloin ne voidaan myös korjata nopeammin.

5.2 Jatkokehitys

Tuloksien perusteella suurimpina heikkouksina havaittiin testauksen yksipuolisuus se-kä epäonnistuneiden testien määrä. Kohdejärjestelmälle sovelletaan vain hyväksymistes-tauksen piiriin kuuluvia käyttöliittymä- ja rajapintatestausta. Järjestelmälle ei ole laadittulainkaan yksikkötestejä, mikä on vakava puute. Vasta-argumenttina yksikkötestien puut-tumiselle kohdejärjestelmä on erittäin rajapintariippuvainen, koska se toimii terveyden-huollon tietojärjestelmien ja Kelan Kanta-palveluiden integraatiorajapintana. Siitä huoli-matta suuri osa järjestelmän ohjelmakoodista ei ole suoraan tekemisissä eri rajapintojenkanssa, joten ainakin kyseisiä osia pystyisi yksikkötestaamaan tälläkin hetkellä.

Jäljittelyn (mocking) avulla myös ulkoisia riippuvuuksia sisältävää koodia voitaisiin yk-

43

sikkötestata. Jäljittelyssä keskitytään testattavaan koodiin siten, että ulkoiset riippuvuu-det korvataan olioilla, jotka matkivat ulkoisten riippuvuuksien käyttäytymistä [46]. Tätenesimerkiksi yksikkötestauksessa kommunikaatio HTTPS-rajapinnan yli voitaisiin korva-ta logiikalla, jossa pyynnöt käsitellään omalla toteutustavalla. Lisäksi myös tietokantojenkäyttöä voitaisiin jäljitellä aitojen käyttämisen sijaan. Yksikkötestaus voitaisiin suorittaaliukuhihnalla heti projektien koodien kääntämisen jälkeen. Siten koodin toimivuus saatai-siin varmistettua ennen raskaita toimenpiteitä, ja koodin kattavuudesta saataisiin arvokas-ta tietoa.

Rajapintatestit ja eRAn integraatiorajapinnat ovat huomattavan kehittämisen tarpeessa,jotta epäonnistuneet testit saataisiin ratkaistua. Onnistuneen hyväksymistestauksen edel-lytys on, että epäonnistuneiden hyväksymistestien määrä saadaan pidettyä niin pienissälukemissa, että epäonnistumiset kyetään tarkastelemaan lyhyessä ajassa ja perustamaanjulkaisupäätös niiden varaan.

Jatkuvaa integraatiota ja toimitusta voitaisiin hyödyntää muissakin projekteissa. Esimer-kiksi toimikortinlukijaohjelmisto eRASmartCardille on ehdotettu liukuhihnan toteutusta,jossa se voitaisiin kääntää eri alustoille koodin päivittymisen yhteydessä. Se olisi käte-västi toteutettavissa samalle Jenkinsin pääpalvelimelle, jolle jatkuvan toimituksen liuku-hihna toteutettiin, ja se voisi muun muassa hyödyntää entuudestaan määriteltyjä tehtäviä.Skaalautuvuuden varmistamiseksi jatkossa joitakin tehtäviä täytyy muuttaa entistä genee-risimmiksi. Pääpalvelimen arkkitehtuuria ei kannata tosin hajauttaa liikaa ylläpidettävyy-den vuoksi. Pääpalvelin jääkin todennäköisesti vain eRAan liittyvien projektien käyttöön,ja muille projekteille pystytetään omat ympäristöt.

Projektissa on periaatteessa mahdollista siirtyä soveltamaan jatkuvaa käyttöönottoa, jossatuote julkaistaisiin automaattisesti tuotantoon. Käytännössä siirtyminen on kuitenkin epä-todennäköistä, koska projekti vaatii tietoturvakriittisen luonteensa takia erittäin tarkkaahyväksymistestausta, ja julkaisuihin liittyy paljon lainsäädännöllistä byrokratiaa.

44

6. YHTEENVETO

Työssä tutkittiin eri työkaluja ja menetelmiä jatkuvan toimituksen käyttöönotolle ohjel-mistoprojektissa, jossa oltiin aiemmin noudatettu perinteistä toimitusprosessia. Perehty-misen jälkeen valittiin projektille parhaiten soveltuva työkalu, ja ympäristöä alettiin suun-nittelemaan ja pystyttämään jatkuvalle toimitukselle. Lopputuloksena saatiin toteutettualiukuhihna, mikä suorittaa jatkuvan toimituksen vaiheet odotetulla tavalla. Taulukkoon6.1 on koottu työn kannalta tärkeimmät tiedot.

Taulukko 6.1. Yhteenvetotaulukko.Aihe Jatkuva toimitus ohjelmistoprojektissaKohdejärjestelmä eRA (Atostekin web-palvelu)Työkalu JenkinsEriyttämismenetelmä VirtualisointiLiukuhihnan keskimääräinen suoritusaika 10hYmpäristön pystytyksen aika-arvio 500hKäyttöliittymätestit 163 onnistunutta, 30 epäonnistunuttaRajapintatestit 46 onnistunutta, 38 epäonnistunuttaVahvuudet Testausautomaatio, käännösten toistettavuus,

säännölliset julkaisutHeikkoudet Ympäristöriippuvaisuus, testien yksipuolisuus ja

epäonnistumismäärä, toistaiseksi vähäinen käyttö

Liukuhihnan ansiosta kääntämistä ja testausta saadaan suoritettua automatisoidusti toteu-tetussa ympäristössä. Testaajien ei enää tarvitse ajaa pitkiä testisarjoja paikallisesti omillakoneillaan, vaan he voivat hyödyntää liukuhihnan tarjoamia tuloksia. Kehittäjien työstä-mille muutoksille saadaan suoritettua laadunvarmistusta tiheään tahtiin, jolloin mahdol-liset ongelmat ovat nopeasti havaittavissa. Automaation ansiosta projektissa säästetäänhenkilötyötunteja ja sen myötä kustannuksia.

Projektissa kehitettävää palvelua ei ole vielä julkaistu tuotantoon hyödyntämällä toteutet-tua liukuhihnaa. Palvelulla on jo lukuisia asiakkaita, ja palvelu on rajapintapainoitteisenluonteensa takia hyvin tietoturvakriittinen. Täten on ymmärrettävää, että tuote julkais-taan harvemmin, tällä hetkellä vain reilun kuukauden välein. Kuitenkin kyseiset julkaisutpitäisi perustaa liukuhihnan tuottamien testaustulosten ympärille, koska hyväksymistes-tien tarkoituksena on toimia kynnyksenä julkaisun hyväksymiselle. Etenkin liukuhihnallaepäonnistuneiden testien määrän perusteella julkaisujen hyväksymiset ovat kyseenalaisiatällä hetkellä.

Projektin sisällä pitäisi siirtyä noudattamaan DevOps-kulttuuria, jotta jatkuvaa toimitus-ta pystyttäisiin hyödyntämään sen täydellä potentiaalilla. Kulttuurimuutos on haastavaa,koska kohdejärjestelmää on vuosien ajan kehitetty siten, että kehitys ja projektikohtaiset

45

toimenpiteet on pidetty erillään toisistaan tiimin keskuudessa. Lisäksi ohjelmallista tes-tausta ollaan alettu hyödyntämään vasta pari vuotta sitten, ja testien laatiminen on ollutvain muutamien työntekijöiden varassa.

Työssä näytettiin, että jatkuvan toimituksen toteuttamiselle on tarjolla lähes rajattomastieri työkaluja ja menetelmiä, joiden valinta riippuu usein kohdejärjestelmän ja -ympäristönasettamista vaatimuksista. Työssä toteutettu liukuhihna soveltuu käytettäväksi vain koh-dejärjestelmän yhteydessä, mutta siinä on kuitenkin noudatettu jatkuvan toimituksen pe-riaatteita. Suunnitteluvaiheessa on tärkeintä tiedostaa eri vaihtoehdot toimituksen toteut-tamiselle, joita työssä esiteltiin paneutumatta liikaa yksityiskohtiin.

Työssä havaittiin, että jatkuvalla toimituksella on suuri merkitys laadukkaiden ohjelmis-tojen säännöllisessä tuottamisessa. Jatkuva toimitus vaatii kuitenkin ympärilleen työkult-tuurin, jossa projektitiimin jäsenet vastaavat tuotteesta tasapuolisesti. Jatkuvan toimituk-sen käyttöönotto voi olla haastavaa ohjelmistoprojektista riippuen, mutta pitkällä tähtäi-mellä se maksaa itsensä moninkertaisesti takaisin. Oikein sovellettuna jatkuva toimitustukee projektitiimin työskentelyä ja johtaa sekä parempaan asiakastyytyväisyyteen ettäliiketoiminnan kasvuun.

46

LÄHTEET

[1] Anastasov, M. What’s the Difference Between Continuous Integration, ContinuousDeployment and Continuous Delivery? Saatavissa (viitattu 23.8.2018):https://semaphoreci.com/blog/2017/07/27/what-is-the-

difference-between-continuous-integration-continuous-

deployment-and-continuous-delivery.html

[2] ASP.NET. Get building. Saatavissa (viitattu 10.10.2018):https://www.asp.net/

[3] Atostek Oy. Atostek eRA. Saatavissa (viitattu 23.8.2018):http://era.atostek.com

[4] Atostek Oy. Kelan Kanta-palvelut nopeasti käyttöön. Saatavissa (viitattu 4.9.2018):https://www.atostek.com/era/era-ammattilaisille/

[5] Atostek Oy. Nopea integraatio Kelan Kanta-palveluihin. Saatavissa (viitattu10.10.2018):https://www.atostek.com/era/era-jarjestelmatoimittajille/

[6] Best Continuous Delivery Software. Saatavissa (viitattu 30.8.2018):https://www.g2crowd.com/categories/continuous-delivery

[7] Brizeno, M. 5 Traits of a Good Delivery Pipeline. Saatavissa (viitattu 23.8.2018):https://www.thoughtworks.com/insights/blog/5-traits-

good-delivery-pipeline

[8] CircleCI, The shortest distance from idea to execution. Saatavissa (viitattu23.8.2018):https://circleci.com/product

[9] CircleCI REVIEW. Saatavissa (viitattu 23.8.2018):https://reviews.financesonline.com/p/circleci/

[10] Codeship, Ship your Apps with Confidence. Saatavissa (viitattu 23.8.2018):https://codeship.com

[11] Continuous Deployment. Saatavissa (viitattu 30.8.2018):https://www.agilealliance.org/glossary/continuous-deployment

[12] Continuous Integration. Saatavissa (viitattu 30.8.2018):https://www.thoughtworks.com/continuous-integration

47

[13] Continuous Integration. Saatavissa (viitattu 31.8.2018):https://continuousdelivery.com/foundations/continuous-

integration/

[14] Continuous Testing. Saatavissa (viitattu 23.8.2018):https://continuousdelivery.com/foundations/test-automation/

[15] Crisp, J. Automated Testing and the Test Pyramid. Saatavissa (viitattu15.10.2018):https://jamescrisp.org/2011/05/30/automated-

testing-and-the-test-pyramid/

[16] Docker. Docker Containerization Unlocks the Potential for Dev and Ops. Saata-vissa (viitattu 23.8.2018):https://www.docker.com/why-docker

[17] Docker. Drive secure automation and deployment at massive scale. Saatavissa(viitattu 23.8.2018):https://www.docker.com/solutions/cicd

[18] Docker. Get Started, Part 1: Orientation and setup. Saatavilla (viitattu 10.9.2018):https://docs.docker.com/get-started

[19] Earnshaw, A. Top Benefits of Continuous Delivery: An Overview. Saatavissa(viitattu 30.8.2018):https://puppet.com/blog/top-benefits-of-

continuous-delivery-an-overview

[20] Groovy. A multi-faceted language for the Java platform. Saatavissa (viitattu4.9.2018):http://groovy-lang.org/index.html

[21] Guckenheimer, S. What is Continuous Integration? Saatavissa (viitattu23.8.2018):https://docs.microsoft.com/en-us/azure/devops/what-

is-continuous-integration

[22] Hallivuori, K. Jatkuva käyttöönotto auttaa oppimaan ja hyötymään ohjelmisto-muutoksista tehokkaasti. Saatavissa (viitattu 4.9.2018):https://solinor.fi/2014/02/19/jatkuva-kayttoonotto-auttaa-

oppimaan-ja-hyotymaan-ohjelmistomuutoksista-tehokkaasti/

[23] Heller, M. What is Jenkins? The CI server explained. Saatavissa (viitattu23.8.2018):https://www.infoworld.com/article/3239666/devops/what-

is-jenkins-the-ci-server-explained.html

48

[24] IIS. Saatavissa (viitattu 23.8.2018):https://www.iis.net/

[25] Jenkins, Build great things at any scale. Saatavissa (viitattu 23.8.2018):https://jenkins.io

[26] Jenkins Glossary. Saatavissa (viitattu 23.8.2018):https://jenkins.io/doc/book/glossary/

[27] Jenkins Pipeline Syntax. Saatavissa (viitattu 23.8.2018):https://jenkins.io/doc/book/pipeline/syntax/

[28] Jenkins Plugins. Saatavissa (viitattu 23.8.2018):https://plugins.jenkins.io/

[29] Kelly. Web Development: What is Staging? Design and Development. Saatavissa(viitattu 23.8.2018):https://www.commonplaces.com/blog/web-

development-what-is-staging/

[30] Lee, J. Configuring Parameters for Web Package Deployment. Saatavissa (viitattu17.10.2018):https://docs.microsoft.com/en-us/aspnet/web-

forms/overview/deployment/web-deployment-in-the-

enterprise/configuring-parameters-for-web-package-deployment

[31] Leff, A. Rayfield, J.T. Web-Application Development Using the Model ViewController Design Pattern. p.118. Viitattu 26.10.2018

[32] Leszko, R. (2017). Continuous Delivery with Docker and Jenkins, 1st ed. PacktPublishing, GB. Viitattu 20.9.2018.

[33] MSBuild. Saatavissa (viitattu 23.8.2018):https://docs.microsoft.com/fi-fi/visualstudio/msbuild/msbuild

[34] Novoseltseva, E. Top 10 Benefits of Docker. Saatavissa (viitattu 27.9.2018):https://dzone.com/articles/top-10-benefits-of-using-docker

[35] Reifman, J. Codeship: Continuous Integration and Delivery Made Simple. Saata-vissa (viitattu 24.8.2018):https://code.tutsplus.com/tutorials/codeship-continuous-

integration-and-delivery-made-simple-cms-23517

[36] Remote Desktop Protocol. Saatavissa (viitattu 23.8.2018):https://docs.microsoft.com/en-us/windows/

desktop/termserv/remote-desktop-protocol

49

[37] Robot Framework. Saatavissa (viitattu 27.8.2018):http://robotframework.org/

[38] Rouse, M. Microsoft SQL Server Management Studio (SSMS). Saatavissa (vii-tattu 24.8.2018):https://searchsqlserver.techtarget.com/definition/Microsoft-

SQL-Server-Management-Studio-SSMS

[39] Rouse, M. Staging environment. Saatavissa (viitattu 24.8.2018):https://searchsoftwarequality.techtarget.com/

definition/staging-environment

[40] Shahin, M. Zahedi, M. Babar, M.A. Zhu, L. An empirical study of architectingfor continuous delivery and deployment. Viitattu 30.10.2018.

[41] sqlcmd Utility. Saatavissa (viitattu 23.8.2018):https://docs.microsoft.com/en-us/sql/tools/sqlcmd-

utility?view=sql-server-2017

[42] Srinivasan, B.N. What Tools Do You Need for Continuous Delivery? Saatavissa(viitattu 23.8.2018):https://dzone.com/articles/101-tools-for-continuous-delivery

[43] Sypolt, G. Choosing a CI-CD Tool. Saatavissa (viitattu 23.8.2018):https://saucelabs.com/blog/choosing-a-ci-cd-tool

[44] Travis, Core Concepts for Beginners. Saatavissa (viitattu 23.8.2018):https://docs.travis-ci.com/user/for-beginners

[45] Travis, Test and Deploy with Confidence. Saatavissa (viitattu 23.8.2018):https://travis-ci.org

[46] Unit Testing for Software Craftsmanship. Saatavissa (viitattu 22.10.2018):https://www.telerik.com/products/mocking/unit-testing.aspx

[47] Visual Studio IDE. Saatavissa (viitattu 10.10.2018):https://visualstudio.microsoft.com/vs/

[48] Web Deploy 3.6. Saatavissa (viitattu 23.8.2018):https://www.iis.net/downloads/microsoft/web-deploy

[49] What is Continuous Delivery? Saatavissa (viitattu 23.8.2018):https://continuousdelivery.com

[50] What is DevOps? Saatavissa (viitattu 23.10.2018):https://aws.amazon.com/devops/what-is-devops/

50

[51] What is Regression Testing? Saatavissa (viitattu 17.10.2018):https://smartbear.com/learn/automated-

testing/what-is-regression-testing/

[52] VMWare, Workstation Pro. Saatavissa (viitattu 23.8.2018):https://www.vmware.com/products/workstation-pro.html

[53] Zaiku Group. Continuous Delivery In a Nutshell. Saatavissa (viitattu 7.9.2018):https://medium.com/@Zaiku/continuous-

delivery-in-a-nutshell-29f4213dabda

51

LIITE A: MASTER-LIUKUHIHNA

p i p e l i n e {a g e n t { l a b e l ’ mas te r ’ }s t a g e s {

s t a g e ( ’ P r o j e c t s ’ ) {p a r a l l e l {

s t a g e ( ’ eRA ’ ) {s t e p s {

b u i l d j o b : ’eRA’}

}s t a g e ( ’ S imArkis to ’ ) {

s t e p s {b u i l d j o b : ’ S imArkis to ’

}}s t a g e ( ’ S i m R e s e p t i k e s k u s ’ ) {

s t e p s {b u i l d j o b : ’ S im R e s e p t i ke s k u s ’

}}s t a g e ( ’ S imValv i ra ’ ) {

s t e p s {b u i l d j o b : ’ S imValv i ra ’

}}s t a g e ( ’ Data f i l e s ’ ) {

s t e p s {b u i l d j o b : ’ Update ’ , p a r a m e t e r s : [ [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ u p d a t e P a t h ’ , v a l u e : ’C : \ \

eRAPubl ish \ \ D a t a F i l e s ’ ] ]}

}s t a g e ( ’ eRAGUITest ’ ) {

s t e p s {b u i l d j o b : ’ Update ’ , p a r a m e t e r s : [ [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ u p d a t e P a t h ’ , v a l u e : ’C : \ \

eRAPubl ish \ \ eRAGUITest ’ ] ]}

}s t a g e ( ’ I n t e r f a c e T e s t e r ’ ) {

s t e p s {b u i l d j o b : ’ I n t e r f a c e T e s t e r ’

}}

}}s t a g e ( ’ DropDatabases ’ ) {

s t e p s {b u i l d j o b : ’ DropDatabases ’

}}s t a g e ( ’ I n i t i a l i z e D a t a b a s e ’ ) {

s t e p s {b u i l d j o b : ’ I n i t i a l i z e D a t a b a s e ’

}}s t a g e ( ’ I n t e r f a c e t e s t s ’ ) {

s t e p s {b u i l d ( j o b : ’ I n t e r f a c e T e s t ’ , p r o p a g a t e : f a l s e )

}}s t a g e ( ’ GUI t e s t s ’ ) {

s t e p s {b u i l d j o b : ’ GUITest ’

}}

}}

Ohjelma A.1. Master-liukuhihnan toteutus.

52

LIITE B: ERA-LIUKUHIHNA

p i p e l i n e {a g e n t { l a b e l ’ mas te r ’ }o p t i o n s { s k i p D e f a u l t C h e c k o u t ( ) }e n v i r o n m e n t {

PROJECT_FILE_PATH = " \ \ \ \ vmware−h o s t \ \ Shared F o l d e r s \ \ eRAPubl ish \ \ eRA \ \ b r a n c h e s \ \ 2 . 4 \ \ e R A I n t e r f a c e "}s t a g e s {

s t a g e ( ’ Update ’ ) {s t e p s {

b u i l d j o b : ’ Update ’ , p a r a m e t e r s : [ [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ u p d a t e P a t h ’ , v a l u e : ’C : \ \ eRAPubl ish\ \ eRA ’ ] ]

}}s t a g e ( ’ Bui ld ’ ) {

a g e n t { l a b e l ’ eRABuild ’ }s t e p s {

b u i l d j o b : ’ Bui ld ’ , p a r a m e t e r s : [ [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ p r o j e c t F i l e P a t h ’ , v a l u e :PROJECT_FILE_PATH ] , [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ p r o j e c t F i l e N a m e ’ , v a l u e : ’ e R A I n t e r f a c e ’ ] , [$ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ p r o f i l e ’ , v a l u e : ’ Deployment Package ( ArchiveDemo ) ’ ] ]

}}s t a g e ( ’ Deploy ’ ) {

a g e n t { l a b e l ’ eRAServer ’ }s t e p s {

b u i l d j o b : ’ Deploy ’ , p a r a m e t e r s : [ [ $ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ p r o j e c t ’ , v a l u e : ’ e R A I n t e r f a c e ’ ] , [$ c l a s s : ’ S t r i n g P a r a m e t e r V a l u e ’ , name : ’ p r o f i l e ’ , v a l u e : ’ \ \ \ \ vmware−h o s t \ \ Shared F o l d e r s \ \ eRAPubl ish \ \eRA \ \ b r a n c h e s \ \ 2 . 4 \ \ I n s t a l l a t i o n \ \ e R A I n t e r f a c e \ \ ArchiveDemo ’ ] ]

}}

}}

Ohjelma B.1. eRA-liukuhihnan toteutus.