JATKUVA INTEGROINTI JAVA ENTERPRISE -KEHITYKSEN APUNA

JATKUVA INTEGROINTI JAVA ENTERPRISE -KEHITYKSEN APUNA Joni Mustaniemi Opinnäytetyö Marraskuu 2013 Tietojenkäsittely

TIIVISTELMÄ Tampereen ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Ohjelmistotuotannon suuntautumisvaihtoehto MUSTANIEMI, JONI: Jatkuva integrointi Java Enterprise -kehityksen apuna Opinnäytetyö 30 sivua Marraskuu 2013 Opinnäytetyö käsittelee ketterän ohjelmistokehityksen menetelmiä ja jatkuvan integraation prosesseja. Tämän työn tavoitteena oli luoda toimeksiantajan tiimin käyttöön toimiva jatkuvan integraation järjestelmä tiimin projekteja varten. Jatkuvan integraation järjestelmä on ollut toimeksiantajan testikäytössä. Järjestelmä on kehitetty Javaympäristön työkaluille. Yrityksen projekteissa käytetään apuna Maven- sekä Anttyökaluja, mutta tämän työn tulosten testaamista varten ainoastaan Maven-työkalujen käyttöä on tutkittu. Työn lähtökohtana oli saada automatisoitua tiimin ohjelmistoprosessien testausta ja testausten raportointia. Koska projekteja on useita ja projektien lähtökohtana käytetään samaa ohjelmarunkoa, rungon muutosten vaikuttaminen muihin projekteihin voidaan huomata jatkuvan integraation järjestelmän avulla mahdollisimman aikaisessa vaiheessa kehitysprosessia. Näin saadaan vähennettyä virheiden siirtymistä muihin projekteihin sekä voidaan seurata koko tiimin tasolla ohjelmiston laatua. Opinnäytetyön ensimmäisen vaiheen tavoite oli luoda yritykselle käyttöön jatkuvan integraation prosessi ja etsiä siihen soveltuvat työkalut useiden vaihtoehtojen perusteella. Tutkimusten perusteella valittiin tiimille esiteltäväksi kaksi ohjelmistoa. Valinnan perusteella on asennettu ja konfiguroitu järjestelmä ja järjestelmä annettiin toimeksiantajan testattavaksi. Käytännön osuuden tuloksena syntyneeseen järjestelmään on automatisoitu Java Enterprise -kehitysprojekteja testausten tuloksia varten. Järjestelmän tulosten perusteella arvioidaan järjestelmän hyödyt tiimin prosessien tukemiseksi. Jatkuvan integraation järjestelmän prosessien luominen ei ainoastaan antanut tiimille jatkuvan integraation järjestelmää, vaan se myös vaikutti tiimin testausmenetelmien uudelleen suunnitteluun ja työskentelytapaan. Suunnittelutyöstä on annettu toiselle opiskelijalle aihe opinnäytetyöhön. Asiasanat: jatkuva integraatio, ketterä ohjelmistokehitys, atlassian bamboo, Jenkins

ABSTRACT Tampereen ammattikorkeakoulu Tampere University of Applied Sciences Bachelor of Business Administration (BBA) MUSTANIEMI, JONI: How continuous integration system aid Java Enterprise software development Bachelor's thesis 30 pages November 2013 This thesis describes agile software development methodologies and continuous integration processes. The aim of this work was to create a functioning continuous integration system for the client team s projects. The system was tested by the client. The system was developed for Java development tools and environment. The projects of the team are built with Maven and Ant tools, but only Maven development tools were used and studied here. The main point was to create automated software testing processes and test reporting tools for the team. Because there are a number of projects developed by the team and the same project base is used in multiple projects, changes to the base are tested and checked to see if they affect other projects and errors can be caught at the earliest point possible by a continuous integration system. This will reduce errors in other projects and improve software quality throughout the entire team. In the first phase of this research, the objective was to create a continuous integration process and to find appropriate tools for it. The selected tools were presented to the team. The selected software was installed and configured and the system was tested by the client. The creation of the continuous integration processes not only gave the team a continuous integration system, but it also affected the team's testing method discussion and test methods re-design. A further study on the result of the test re-design work was subsequently started by another student. Key words: continuous integration, atlassian bamboo, Jenkins, agile software development

4 SISÄLLYS 1 JOHDANTO... 5 2 TOIMEKSIANTAJA... 6 3 KETTERÄT MENETELMÄT... 7 3.1 Yleistä... 7 3.2 Ketterän ohjelmistokehityksen menetelmät... 8 3.2.1 Extreme programming... 8 3.2.2 Scrum... 9 3.2.3 Crystal... 9 3.2.4 Feature Driven Development (FDD)... 9 3.2.5 Test Driven Development (TDD)... 10 3.3 Ketterä ohjelmistokehitys ja jatkuva integraatio... 10 4 JATKUVA INTEGRAATIO... 12 4.1 Yleistä... 12 4.2 Käyttöön ehdotetut ohjelmat... 13 4.2.1 Bamboo... 13 4.2.2 Jenkins... 14 4.2.3 Jatkuvan integraation järjestelmän valinta... 15 5 YMPÄRISTÖ... 16 5.1 Testausmenetelmissä käytettävät tekniikat... 16 5.1.1 Yksikkötestaaminen ja JUnit... 16 5.1.2 Käyttöliittymätestaaminen ja Selenium... 16 5.1.3 Suorituskykytestaaminen ja JMeter... 17 5.1.4 Daily-build, Maven ja Weblogic... 17 5.1.5 Muuta huomioitavaa... 18 5.2 Ympäristön asennus... 18 5.2.1 Unix-palvelimen asennus... 19 5.2.2 Oracle Database Express Edition... 19 5.2.3 Oracle Weblogic Server... 20 5.2.4 Jenkins... 20 5.3 Jenkinsin muokkaus yrityksen tarpeisiin... 21 5.3.1 Jenkinsin konfigurointi... 21 5.3.2 Tehtävien luonti Jenkinsissä... 22 6 YHTEENVETO... 27 LÄHTEET... 29

5 1 JOHDANTO Ohjelmistotestauksen tärkeys ohjelmistoprojekteissa on ollut aina korkealla prioriteettilistalla, etenkin tänä päivänä kun puhutaan ketterästä ohjelmistokehityksestä. Iteraatioita kehityksessä on useita päivittäin ja lähdekoodia integroidaan useita kertoja versionhallintaan. Ohjelmistojen manuaalinen testaaminen vie kuitenkin ohjelmistokehittäjiltä paljon aikaa, jonka voisi käyttää itse projektin kehittämiseen. Jatkuvan integroinnin hienous ohjelmistoprojekteissa on, että järjestelmän avulla voidaan automatisoida testausprosesseja tehtäväksi päivittäin tai jokaisen koodin integraation yhteydessä, jolloin saadaan välittömästi tietoa järjestelmän toiminnasta sekä sen rikkoutumisen aiheuttaneesta päivityksestä. Projektiin on ennalta valittu vertailtavaksi kaksi jatkuvan integroinnin työkalua. Ensimmäiseksi ohjelmistoksi on valittu Atlassianin Bamboo -ohjelmisto, joka on maksullinen. Atlassian on hyvin tunnettu muistakin ohjelmistoistaan, kuten esimerkiksi JIRA tai Confluence. Toisena ohjelmistona vertailussa käytetään maksutonta avoimen lähdekoodin ohjelmistoa nimeltään Jenkins. Jenkins on Hudsonista haarautunut ohjelmisto, jolla on hyvin aktiivinen käyttäjäkunta. Hudsonia kehitettiin Sun Microsystemillä, joka on nykyinen Oracle. Pääkehittäjä sekä suurin osa kehitystiimistä lähtivät Oraclelta ja alkoivat kehittää Hudsonia Jenkins nimellä. Myöhemmin Oracle luovutti Hudsonin Eclipse Foundationille. Bamboo ja Jenkins tukevat Java Enterprise -ohjelmointikieltä ja tämän työn toimeksiantajan ohjelmistoprojekteissa käytettäviä menetelmiä, kuten esimerkiksi Maven kääntötyökalulla ohjelmiston kääntämistä. Tämän työn tarkoituksena on luoda toimiva ja helppokäyttöinen testausjärjestelmä toimeksiantajan Java Enterprise -ohjelmistoprojekteja varten sekä käydä läpi miten ketterät menetelmät sekä jatkuva integraatio liittyvät toisiinsa ohjelmistokehityksessä. Työn tekijän tavoitteena on oppia jatkuvan integraation työkalujen käyttöönoton suunnittelemista, toteuttamista sekä käyttämistä..

6 2 TOIMEKSIANTAJA CGI on maailman viidenneksi suurin itsenäinen IT- sekä liiketoimintaprosessien palvelutalo. CGI:n ja Logican yhdistymisen jälkeen syyskuussa 2012, yrityksessä työskentelee 71000 ammattilaista 40 eri maassa. Se takaa paremman tavoitettavuuden, lisää palvelumahdollisuuksia sekä asiantuntemusta CGI:n asiakkaille ympäri Amerikkaa, Eurooppaa sekä Aasiaa. CGI tuottaa korkeatasoista liiketoiminta sekä IT-konsultointia. Palveluina on tuottaa järjestelmäintegrointia sekä liiketoimintatoimintojen ja ITtoimintojen hallintaa. Yritys keskittyy finanssi-, hallitus-, terveydenhuolto-, jälleenmyynti-, jakelu-, valmistus-, tietoliikenne-, julkisten-, öljy- sekä kaasupalveluiden tuottamiseen. (CGI, 2013.)

7 3 KETTERÄT MENETELMÄT 3.1 Yleistä Ketterän menetelmän käytännöt lisäävät projekteissa joustavuutta. Ne tuovat projekteihin parempaa laatua, vähemmän asiakirjojen kirjoittamista ja nopeampaa saavutettavuutta markkinoille. Myös yhteistyö on joustavampaa asiakkaiden kanssa. Perinteinen ohjelmistokehitys nojaa voimakkaasti suunnitteluun ohjelmistoprojektien kehityksen alkuvaiheessa. Projektien vastuuhenkilöiden näkökulma ohjelmistokehityksessä oli aikaisemmin se, että saamalla mahdollisimman aikaisessa vaiheessa projektiin liittyvät tarkemmat tiedot, voitiin tehdä projektin kulun suunnittelu, laskea projektin kulut sekä resurssien käytöt etukäteen tarkasti. Myöhemmin tulleet muutokset ohjelmistoon aiheuttavat takaisiniskuja projektille sekä kasvattivat sen kuluja. Ketterän ohjelmistosuunnittelun tarkoitus on luoda laadukkaampaa ohjelmistoa lyhyemmässä ajassa. (Ahmed, 2010.) Kuvassa 1 on ketterän menetelmän prosessikaavio. Kuva 1. Ketterän menetelmän prosessi (Mountain Goat Software 2013.) Yleisiä menetelmiä ketterässä ohjelmistokehityksessä ovat Extreme Programming, Scrum, Chrystal Clear, Feature Driven Development (FDD) ja Test Driven Development (TDD). Kaikki edellä mainitut menetelmät toimivat eri tavalla verrattuna perinteiseen ohjelmistokehitykseen ja helpottavat organisaatioita vastaamaan digitaalisen talouden haasteisiin. (Ahmed, 2010.)

8 3.2 Ketterän ohjelmistokehityksen menetelmät 3.2.1 Extreme programming Extreme programming -menetelmää käytettiin projektissa ensimmäisen kerran vuonna 1996. Menetelmä on todistettu toimivaksi hyvin usean erikokoisen yrityksen toimesta ympäri maailmaa. Extreme programming on menestynyt menetelmä, koska se korostaa asiakastyytyväisyyttä. Sen sijaan, että toimitettaisiin kaikki mahdolliset muutokset yhtenä päivänä tulevaisuudessa, voidaan menetelmässä toimittaa ohjelmistoa silloin kuin sitä tarvitaan. Menetelmä oikeuttaa sovelluskehittäjät vastaamaan asiakkaan muutosvaatimuksiin huolellisesti, jopa projektin myöhäisissä vaiheissa. (Extreme Programming 2009.) Extreme programming eli lyhennettynä XP on eniten käytetty menetelmä ketterässä ohjelmistokehityksessä. Se sisältää pariohjelmointia, laajamittaista koodin tarkastelua, yksikkötestaamista, selkeää ja yksinkertaista ohjelmistokoodia ja koodin refaktorointia. Menetelmässä projektin hierarkiaa pyritään tasoittamaan. Projektin sykliä on kuvattu kuvassa 2. Menetelmässä pyritään tuottamaan ominaisuus vasta, kun sitä ohjelmistossa tarvitaan. Projektin dokumentaation vaatimuksiin tehdään usein muutoksia ja ohjelmiston asiakasrajapintaan ollaan jatkuvasti yhteydessä. (Ahmed, 2010.) Kuva 2. Extreme programming -menetelmän prosessin kuvaus (Extreme progamming 2009.)

9 3.2.2 Scrum Scrum on iteratiivinen ketterän ohjelmistokehityksen tekniikka. Nimi Scrum on johdettu strategiasta, jota on käytetty rugby-urheilulajissa. Rugbyssä scrum tarkoittaa strategiaa, jossa palloa liikutellaan edestakaisin kentällä joukkuetovereiden kesken tavoitteena saada palloa kuljetettua kentällä eteenpäin. Scrum-kehys parantaa tiimin kommunikointia sekä maksimoi yhteistyötä tiimin henkilöiden kanssa. Tärkeintä Scrumissa on tuottavuuden maksimointi. Parasta Scrumissa on, että se skaalautuu yrityksessä yhdestä projektista koko organisaation käytännöksi. Scrumia voidaan käyttää niin pienissä kuin isoissakin projekteissa. Pienemmissä projekteissa luodaan Scrum-tiimejä, mutta isommissa projekteissa voidaan projektia varten luoda pienempiä osaprojektitiimejä. (Ahmed, 2010.) 3.2.3 Crystal Crystal on yksi kevyimmistä ketterän ohjelmistokehityksen menetelmistä. Siihen kuuluu sellaisia ketterän ohjelmistokehityksen menetelmiä kuin Crystal Clear, Crystal Yellow ja Cryrstal Orange. Crystal menetelmäperhe osoittaa, että jokainen erillinen projekti voi vaatia hieman muokattuja käytäntöjä. Muutamia tärkeimpiä avaintekijöitä menetelmässä on tiimityöskentely, kommunikointi ja yksinkertaisuus. Projekteissa pyritään mukauttamaan työskentelyä usein muuttuvaan ja kohentuvaan projektiin. Crystalin toimintatavan mukaisesti ohjelmistoa tehdään iteratiivisesti. Kehityksessä pyritään kannustamaan aikaiseen ja usein toimitettavaan ohjelmistoon. Toimitettavaan ohjelmistoon toivotaan korkeaa käyttäjäastetta, sopeutumiskykyä ja pyritään poistamaan turhaa byrokratiaa ja häiriötekijöitä. (VersionOne 2013.) 3.2.4 Feature Driven Development (FDD) Feature Driven Development eli ominaisuuslähtöinen kehittäminen sisältää viisi vaihetta. Ensimmäiset kolme vaihetta sisältävät ohjelmiston sekä dokumentaation rungon tekemisen ja valmistelun. Tässä vaiheessa listataan ohjelmiston tarkemmat ominaisuudet. Loput kaksi vaihetta sisältävät tarkempien ominaisuuksien kehittämistä lyhyissä iteraa-

tioissa. Ominaisuuslistalta tehdään ensin prioriteetiltaan tärkeimmät ominaisuudet. Jokainen ominaisuus kehitetään sekä julkaistaan. (Ahmed, 2010.) 10 FDD on mallilähtöinen ja lyhyen iteraation prosessi. Prosessi alkaa luomalla ohjelmistomallin kokonaisuuskuva. Tämän jälkeen jatketaan kahden viikon sykleissä, joissa toteutetaan ominaisuus yksi kerrallaan. Ominaisuudet ovat yleensä pieniä kokonaisuuksia, jotka ovat niin sanotusti hyödyllisiä asiakkaan silmille. Loput prosessit sitoutuvat projektin ominaisuuksien toimittamiseen. Ominaisuuslähtöinen kehittäminen määrittelee, että ohjelmisto käännetään usein. Toisin kuin muut ketterän ohjelmistokehityksen menetelmät, FDD:tä kuvaa tarkemmin todella lyhyet vaiheet työssä, jotka ovat saatu aikaan erikseen jokaista ominaisuutta kohden. (VersionOne 2013.) 3.2.5 Test Driven Development (TDD) Test Driven development on testilähtöistä ohjelmistokehittämistä. Ohjelmistoa lähdetään kehittämään luomalla testit ohjelmistolle ja vasta sen jälkeen aloitetaan ohjelmiston kehittäminen pienissä iteraatioissa testien perusteella. Jokaisen iteraation tulee läpäistä aikaisemmin luotujen testien ajo. Projektin päätteeksi tiimin ohjelmistokehittäjät refaktoroivat koodia muutosten mukaisesti. (Ahmed, 2010.) 3.3 Ketterä ohjelmistokehitys ja jatkuva integraatio Perinteinen ohjelmistokehitys ei kerro kuinka usein ja säännöllisesti projektin koodia tulee iteroida. Ohjelmistokehittäjät voivat työstää itsenäisesti tunteja, päiviä tai jopa viikkoja samaa ohjelmakoodia ilman, että ohjelmoija tajuaa kuinka monta konfliktia tai ohjelmointivirhettä he voivat aiheuttaa ohjelmistoprojektissa. Koska ketterät tiimit luovat vakaata koodia jokaisessa iteraatiossa, huomaavat he kuinka heidän työtään on normaalisti hidastanut pitkät ohjelmistosyklit. Pitkien ohjelmistosyklien päätteeksi huomataan, kuinka muutokset ovat hidastaneet ohjelmistoa ja kehittäjät joutuvat käyttämään aikaa virheellisen toiminnan aiheuttajan etsimiseen. Mitä enemmän ohjelmistokehittäjiä on jakamassa koodia, sitä vaikeampaa virheellisen toiminnan etsiminen on. Tähän tarkoitukseen ketterät ohjelmistotiimit ottavat jatkuvan integraation järjestelmät käyttöönsä. (VersionOne, 2013.) Kuvassa 3 nähdään, kuinka menetelmät nivoutuvat toisiinsa.

11 Kuva 3. Ketterät menetelmät ja jatkuva integraatio (Developer works, 2012.) Jatkuva integraatio auttaa onnistuneeseen järjestelmän kääntämiseen useita kertoja päivässä työkaluilla kuten Jenkins, Bamboo tai CruiseControl. Järjestelmät käyttävät esimerkiksi Ant-, Maven- tai muita lähdekoodityökaluja ohjelman kääntämiseen. Ketterät kehitystiimit normaalisti konfiguroivat jatkuvan integraation palvelun sisältämään automaattista lähdekoodin kääntämistä, yksikkötestaamista ja lähdekoodin kontrollointia integraatioissa. Oikeastaan jatkuva integraation tarkoittaa, että ohjelmiston kääntäminen melkein aina onnistuu puhtaasti. (VersionOne 2013.) Yksi tärkeimmistä jatkuvan integraation säännöistä on, että ohjelmistokehittäjät eivät koskaan jätä mitään päivän päätteeksi integroimatta versionhallintaan. Jatkuvan integraation järjestelmän käännös ei tulisi koskaan olla yötä rikkinäisessä tilassa. Tämä pakottaa joidenkin tehtävien järjestelmälliseen suunnitteluun ohjelmointitiimeissä. Tiimeissä henkilö, joka rikkoo käännöksen versionhallintaan tallentaessa, joutuu myös korjaamaan tekemänsä virheen. Tämä on luonnollinen kannustin lähdekoodin järjestelmälliseen tarkastamiseen ja testaamiseen päivän edetessä. (VersionOne 2013.)

12 4 JATKUVA INTEGRAATIO 4.1 Yleistä Ohjelmistokehittäjinä olemme kiinnostuneita luomaan parhaan mahdollisen sovelluksen asiakkaillemme pienimmällä mahdollisella työmäärällä. Sovellusten tullessa monimutkaisemmiksi ja koska niissä on enemmän liikkuvia osia, on sovellusten kehittämisestä tullut vaikeampaa kehittyneistä kehitystyökaluista huolimatta. (Kawalerowicz, 2011.) Kuvassa 4 on kuvattu jatkuvan integraation prosessin toimintaa. Kuva 4. Jatkuva integraatio (MSDN, 2013) Jatkuva integrointi (Continuous Integration) on ohjelmistokehityksen toimintatapa, jossa tiimien henkilöt voivat integroida heidän töitään useasti. Normaalisti jokainen henkilö integroi omaa työtään päivittäin, mistä seuraa useat integraatiot joka päivä. Jokainen integraatio varmistetaan kääntämällä ohjelma automaattisesti. Integraatioon kuuluu myös testien automaattinen ajo, joka huomaa virheet mahdollisimman nopeasti. Näin saadaan ohjelmistokehitykseen sellainen toimintatapa, joka johtaa huomattavaan integraation ongelmien vähentymiseen sekä mahdollistaa tiimien keskittymisen tuottamaan yhtenäisempää ohjelmakoodia nopeammin. (Fowler, 2006.)

13 Kysymys kuuluukin, tarvitseeko jokainen muutos ohjelmistokoodissa kääntää ja testata? Vastaus on kyllä. Kuten toimintatavan nimestäkin voi päätellä (jatkuva/continuous), paras mahdollinen tyyli on kääntää ohjelmistokoodi jokaisen muutoksen yhteydessä. Tämä on jatkuvan integraation perimmäinen ajatus. Tästä ei tule välttämättä aloittaa ohjelmiston kehitysprojekteissa. Yksi tapa tehdä, on aloittaa hankkimalla viimeisimmät muutokset ja kääntää. Tämän jälkeen luodaan testit, jotka ajetaan kerran päivässä. Tätä voidaan kutsua niin sanotusti daily build nimellä. Tämän jälkeen kun saadaan daily build ajettua päivittäin, voidaan lisätä muutama kääntö ja testaus joka päivälle. Tämä ei vie aikaa, käännöksistä tulee jatkuvaa ja eri käännöksiin voidaan laittaa erilaisia tehtäviä ajettavaksi. Tärkein tavoite kuitenkin on saada jokainen muutos testattua. Näin saadaan vähennettyä ohjelmistokehityksen riskejä, joita voivat olla esimerkiksi aikataulussa pysyminen tai ohjelmakoodin virheet. (Kawalerowicz, 2011.) 4.2 Käyttöön ehdotetut ohjelmat 4.2.1 Bamboo Perustiedot Bamboo on Atlassianin tarjoama jatkuvan integroinnin työkalu. Atlassian on tullut tutuksi myös JIRA- sekä Confluence-työkaluista. Bamboon käyttäminen yrityskäytössä on maksullista. Hinta määräytyy ajettavien töiden määrän mukaan. Bamboo tukee useita ohjelmointikielen kääntötyökaluja, joita ovat esimerkiksi Ant, Maven ja make. (Bamboo, 2013.) Hyödyt Helppo asennus ja yksinkertainen käyttöliittymä (Kuva 5) tehtävien luonti Asetusten muokkaaminen on helppoa ja järjestelmä skaalautuva Integroituu helposti erilaisiin ohjelmointikäyttöliittymiin kuten Eclipse tai intellij IDEA Tukee Subversionia Jira integraatio Kolmannen osapuolen lisäosia asennettavissa

14 Kuva 5. Bamboo (Bamboo, 2013) 4.2.2 Jenkins Perustiedot Jenkins on Javalla kirjoitettu avoimen lähdekoodin työkalu jatkuvaan integrointiin. Projekti on haarautunut Hudsonista, joka on Oraclen ylläpitämä. Työkalulla seurataan erilaisia toistuvia töitä, kuten ohjelmistojen kääntämistä ja testaamista. Lisäksi Jenkinsillä voidaan myös seurata muita ohjelman ulkopuolisia ajoja. (Jenkins, 2013.) Hyödyt Avoin lähdekoodi, joten voidaan kustomoida omaan käyttöön Ei lisenssimaksuja Helppokäyttöinen graafinen käyttöliittymä, jolla konfiguroida. Kuvassa 6 Jenkinsin etusivu. Asennuspaketti yksi.war -tiedosto, jonka voi helposti asentaa Weblogiciin. Yli 400 erilaista liitännäistä, jotka helpottavat testausta ja integrointia. Tukee myös muita ohjelmointikieliä. Aktiivinen yhteisö ja projektia päivitetään aktiivisesti Tukee Subversion-versionhallintajärjestelmä

15 Kuva 6. Jenkins 4.2.3 Jatkuvan integraation järjestelmän valinta Projektin edetessä valitsimme jatkuvan integraation järjestelmäksi Jenkinsin. Projektin alkuvaiheessa vertailimme Bamboota sekä Hudsonia, josta Jenkins on haarautunut omaksi järjestelmäksi. Vaihdoimme Hudsonin Jenkinsiin, koska Jenkinsiä kehitetään aktiivisemmin kuin Hudsonia. Jenkins valittiin projektin järjestelmäksi, koska järjestelmän luominen ei aiheuttanut muita kuluja kuin työtunnit. Kulujen lisäksi valintaan vaikutti se, että Jenkinsissä voidaan myös ajaa.net-sovelluksia. Tulevaisuudessa tilanteen vaatiessa voidaan miettiä, kuinka saadaan Jenkinsiin liitettyä Windows slave. Windows slave on windows ympäristö, jossa voidaan ajaa sitä vaativia ohjelmistoja ja testejä. Toinen vaihtoehto on asentaa koko järjestelmän pohjaksi Windows-käyttöjärjestelmä. Tällä hetkellä tärkeintä on päästä testaamaan Java Enterprise -projekteja.

16 5 YMPÄRISTÖ 5.1 Testausmenetelmissä käytettävät tekniikat Nykyään moni ohjelma on kirjoitettu internet-sovellukseksi, jota voidaan ajaa internetselaimella. Tällaisten ohjelmistojen testauksen tehokkuus vaihtelee erilaisten yritysten ja yhteisöjen välillä. Ketteriä menetelmiä, kuten Scrumia, käytettäessä säännöllisestä testauksesta on tullut paljon tärkeämpää. Automaattisesta testauksesta on paljon hyötyä säännöllisessä testauksessa. Pääasiallisesti tärkein hyöty on testien uudelleen ajettavuus sekä siinä kuinka nopeasti testit voidaan ajaa. (SeleniumHQ 2013.) 5.1.1 Yksikkötestaaminen ja JUnit JUnit on testaukseen tarkoitettu Java-kirjasto, josta on tullut testausstandardi Javaohjelmoinnin yksikkötestaamiseen. Kirjaston avulla voidaan tehdä testejä, joita voidaan ajaa ilman, että koko ohjelma täytyy kääntää. (Junit, 2013.) Yksikkötestaamisen tarkoitus on se, että käyttäjällä on mahdollisuus testata metodeja yksi kerrallaan ja varmistua, että koodin refaktorointi tai lisäpiirteet eivät riko ohjelmiston toimintoja tai muita alitoimintoja. Jos esimerkiksi on muutamia toisistaan riippuvaisia luokkia, täytyy niiden toiminta varmistaa vielä muutosten jälkeen. Yksikkötestaaminen antaa työkalut, joilla varmistaa etteivät muutokset hajota järjestelmää. Usein yksikkötestit suoritetaan projekteissa ennen ohjelman kääntämistä ja kääntämistä ei aloiteta, ellei yksikkötestien suoritus mene läpi onnistuneesti. Tästä syystä JUnit testit eivät ainoastaan tee ohjelmistosta vakaampaa, vaan se myös säästää paljon aikaa. (Instant Eclipse Application Testing How-To, 2013.) 5.1.2 Käyttöliittymätestaaminen ja Selenium Selenium on yksi eniten käytettyjä avoimen lähdekoodin ratkaisuista käyttöliittymätestauksessa. Selenium automatisoi selaimen toimintaa. Tällä testausmenetelmällä voidaan testata käyttöliittymän toimintaa erilaisilla automatisoiduilla testeillä, joita ajetaan se-

17 laimella. Selenium tukee käytetyimpiä internet-selaimia ja osa selainten tekijöistä on ottanut tai ottamassa sitä osaksi selaimen perustoimintoja. Lisäksi Selenium on osana erilaisia automatisoituja selaintyökaluja, ohjelmointirajapintoja ja komponenttikirjastoja (framework). Käyttöliittymän testaus Seleniumilla tuo huomattavia etuja pitkällä tähtäimellä ohjelmistokehityksessä. Etuja ovat jatkuva regressiotestaus, nopea palaute ohjelmistokehittäjille koodin integraatioiden yhteydessä sekä inhimillisten mokien vähenemisen, koska testaus tapahtuu automatisoidusti ohjelmallisesti eikä ohjelmoijien toimesta manuaalisesti. (SeleniumHQ, 2013.) 5.1.3 Suorituskykytestaaminen ja JMeter JMeter on Apachen ylläpitämä Javalla kirjoitettu avoimen lähdekoodin ohjelma, joka on tarkoitettu suorituskyvyn testaamiseen. Ohjelma on alun perin tehty web-sovellusten testausta varten, mutta nykyään sitä voidaan käyttää myös muihin tarkoituksiin. Apachen JMeteriä voidaan käyttää sekä staattisten että dynaamisten resurssien testaamisessa. Staattisia resursseja ovat esimerkiksi tiedostot, servletit, erilaiset scriptit sekä Java-objektit ja dynaamisia tietokannat ja tietokantakyselyt. Ohjelmalla voidaan simuloida sovelluksen rasitustilanteita ja tehdä suorituskykyanalyysejä. JMeterillä voidaan tehdä myös graafisia analyysejä suorituskyvystä sekä testata serverin käyttäytymistä suuren yhtäaikaisen rasituksen alaisena. (Jmeter, 2013.) 5.1.4 Daily-build, Maven ja Weblogic Daily buildilla tarkoitetaan ohjelman viimeisimmän version päivittäistä kääntämistä ja asentamista testiympäristöön. Näin saadaan helposti selville, että kaikki tarvittavat paketit ja muut vaatimukset ovat käytettävissä ohjelman kääntämistä varten. Koska ohjelma päivitetään ja asennetaan päivittäin, on mahdollista testata viimeisintä ohjelmistoa testiympäristössä ja näin saada nopeasti palautetta ohjelman toimivuudesta. Lisäksi päivittäisen ajon seurauksena löydetään nopeasti sellaiset uudet virheet koodissa, jotka ovat seurausta viimeisimmästä koodin järjestelmäintegroinnista.

18 Tässä projektissa daily build käännetään Maven-työkalulla. Sillä alustetaan tietokanta alkuperäiskuntoon sekä asennetaan päivittäin ohjelman ajoon vaaditut insert-lauseet kantaan. Lisäksi Mavenilla käännetään viimeisimmät ohjelmakoodit toimivaksi paketiksi, joka asennetaan Weblogicin testiympäristöön Jenkinsin Weblogic deployer - lisäosalla. Ajon päätteeksi käynnistetään käyttöliittymätestit (Selenium), jotta saadaan regressiotestit ja muut järjestelmäanalyysit suoritettua viimeisimmällä toimivalla kokoonpanolla. 5.1.5 Muuta huomioitavaa Edellä mainittujen testausmenetelmien lisäksi Jenkins-ohjelma on hyödyllinen tuotantopalvelimien toiminnan testauksessa. Ohjelma tekee tuotantopalvelimille kyselyjä tietyin väliajoin, jolloin vastausten perusteella voidaan päätellä, onko palvelu pystyssä vai ei. Jos palvelu ei ole käynnissä, lähettää Jenkins ilmoituksen palvelun poissaolosta tietyille ennalta määrätyille henkilöille, jotka voivat ottaa asian käsittelyynsä. 5.2 Ympäristön asennus Selvitysten jälkeen tähän projektiin valittiin käytettäväksi Jenkins kehittäjäyhteisön aktiivisuuden sekä avoimen lähdekoodin ansiosta. Jenkinsiin on mahdollista asentaa monia hyödyllisiä yhteisön tekemiä lisäosia. Lisäksi lisenssien puolesta ohjelma on ilmaiseksi käytettävissä myös kaupallisessa käytössä. Jenkinsiä varten tarvitsee asentaa palvelin. Projektia varten on otettu käyttöön perus pöytäkonemallinen tietokone. Tätä varten serverikoneeseen asennetaan Fedoran Linuxkäyttöjärjestelmän uusin versio. Opinnäytetyön käytännön osuuden alkaessa uusin versio on 17. Lisäksi ympäristö vaatii Oraclen tietokantapalveluiden asentamisen sekä Weblogicin web-sovellusten ajoon.

19 5.2.1 Unix-palvelimen asennus Projektin käyttöalustaksi valittiin Fedora, joka on Red Hatin sponsoroima, mutta yhteisön ylläpitämä Linuxiin perustuva käyttöjärjestelmä. Valitsimme sen alustaksi, koska Fedora on yhteensopiva Oraclen tuotteiden kanssa. Oraclelta löytyy ohjelmista valmiit asennuspaketit Fedoran paketinhallintajärjestelmän muodossa (rpm), kuten Oracle Database Express Edition -tietokannasta ja Oracle Weblogic Serveristä (web ohjelmien alustasta). Fedorasta asennetaan normaali asennus, johon kuuluu myös graafinen työpöytä, jonka esimerkiksi Selenium vaatii ajaakseen testit internet-selaimella. Käyttöjärjestelmän asennuksen jälkeen järjestelmään asennetaan vaadittu Java JDK. Järjestelmän asennusajankohtana käytössä on Java SE:n 6 versio. Lisäksi perusasennuksen jälkeen tulee poistaa Fedoran SELinux käytöstä, joka on Fedorassa käytettävä tietoturvaohjelma, asettamalla /etc/selinux/config tiedostoon selinux=disabled. SELinuxin poistaminen käytöstä ei haittaa järjestelmän tietoturvaa, koska järjestelmä on yrityksen intranetissä, johon ulkoverkosta ei ole oikeuksia. SELinux poistetaan käytöstä, koska oletusasetuksilla se estää tarvittavien prosessien ajon serverillä. 5.2.2 Oracle Database Express Edition Tietokantaohjelmistona käytetään Oraclen Database Express Editionia. Tietokannan asennustyökalu asentaa molemmat sekä serveri- että asiakasohjelmiston komponentit yhdessä asennuspaketissa. Asennustyökalu löytyy Oraclen sivuilta. Asennuspaketti on ilmainen, mutta vaatii rekisteröitymisen Oraclen sivustolle. Tietokantaohjelmistosta on vain 64-bittinen versio Linux-käyttöjärjestelmälle. Asennuspaketin latauksen valmistuttua paketti puretaan tarvittavalla ohjelmistolla, joka osaa purkaa zip-tiedoston. Purkamisen valmistuttua kohdekansioon on ilmestynyt rpm-tiedosto, joka ajetaan rpm -ivh oracle-xe-xxx.rpm (xxx = versionumero ja arkkitehtuuri) -komennolla. Ruudulla näkyy paketin asennuksen eteneminen. Asennuksen jälkeen ajetaan /etc/init.d/oracle-xe configure, jolla säädetään tarvittavat asetukset kantayhteyksille. Jos Oracle Database Express Editionin asetuksia tarvitsee myöhemmin muuttaa, voidaan näin tehdä ajamalla kyseinen komento uudelleen. Tämän lisäksi käteviä komentoja esimerkiksi mahdollisissa ongelmatilanteissa ovat /etc/init.d/oracle-xe + start/stop komennot, joilla kannan voi sammuttaa ja käynnistää uudelleen.

20 Asetukset HTTP port 8080 Oracle listener 1521 Sys käyttäjän salasana Automaattinen käynnistys haluamasi salasana Kyllä 5.2.3 Oracle Weblogic Server Weblogicin asennus onnistuu vaivattomasti Fedoraan. Asennusta varten Oraclen sivuilta tulee ladata 64-bittinen jar-tiedosto. Paketti asennetaan järjestelmään antamalla Linuxin terminaaliin seuraava komento: java jar wls[versionumero]_generic.jar Asennuksessa valittiin asennustyypiksi Typical, joka asentaa WebLogic Server -komponentin oletusasetuksilla. Asennuksen jälkeen luodaan WebLogiciin domain oletusasetuksilla. Ainoastaan Javan valinnassa vaihdetaan WebLogic käyttämään Oraclen Javaa JRockitin sijaan. 5.2.4 Jenkins Jenkinsin asentaminen on Fedoralle yksinkertaista. Fedorassa voidaan käyttää Jenkinsin RedHat distribuutioille tarkoitettua pakettivarastoa, josta löytyy asentamiseen tarvittavat asennuspaketit. Pakettivarasto lisätään Fedoraan suorittamalla seuraavat komennot Linuxin terminaalissa: sudo wget O /etc/yum.repos.d/jenkins.repo http://pkg.jenkinsci.org/redhat/jenkins.repo sudo rpm import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

Pakettivaraston asentamisen jälkeen Jenkins voidaan asentaa yksinkertaisesti käyttämällä seuraavaa komentoa: 21 sudo yum install jenkins Jenkinsin asentaminen kestää vain muutaman minuutin, jonka jälkeen asennuksen onnistumisen ja Jenkinsin päälläolo voidaan tarkistaa suorittamalla seuraava komento: sudo service jenkins status Jos Jenkins on käynnissä, asennettua jatkuvan integraation järjestelmää voidaan testata halutussa selaimessa. Käynnistämällä selain ja laittamalla osoiterivin osoitteeksi http://localhost:8080/ avautuu Jenkinsin hallintasivu. 5.3 Jenkinsin muokkaus yrityksen tarpeisiin 5.3.1 Jenkinsin konfigurointi Tässä tapauksessa jatkuvan integraation järjestelmä on lokaalissa yritysverkossa ja järjestelmään pääsee kuka tahansa kiinni. Järjestelmästä halutaan estää tärkeät muokkausominaisuudet muilta kuin halutuilta käyttäjiltä. Oletuksena Jenkinsin asennuksessa kaikilla käyttäjillä on oikeus selata ja muokata sen asetuksia sekä luoda uusia tehtäviä. Muilla kuin järjestelmän ylläpitäjillä on oikeudet vain tarkastella tehtäviä Jenkinsissä. Järjestelmä tukee unix-käyttäjätunnusten käyttämistä, joten tässä tapauksessa käytetään unix-palvelimelle luotuja tunnuksia. Asetus löytyy Jenkinsin asetuksista kohdasta: Manage Jenkins -> Configure Global Security. Aukeavasta ikkunasta kohtaan Security Realm valitaan Unix user/group database ja Authorisation kohtaan Logged-in users can do anything. Muita konfiguraatioita ei tarvitse tehdä.

22 5.3.2 Tehtävien luonti Jenkinsissä Jenkinsiä voidaan käyttää erilaisissa ohjelmankäännöstapauksissa. Ohjelmalla voidaan suorittaa jatkuvia, virallisia ja niin sanotusti nightly build käännöksiä projektin koodista, riippuen millainen tarve käännökselle on. Esimerkiksi jokaisen ohjelmistosuunnittelijan tuodessa muutoksia versionhallintaan, järjestelmällä ajetaan jatkuvaa käännöstä jokaisen tuonnin yhteydessä. Toisaalta kerran päivässä ajettava nightly build ajetaan esimerkiksi keskiyöllä koko edellisen päivän kehitystyön tuotoksista, jonka jälkeen testien onnistuessa luodaan projektista uusi käännöspaketti eli war-paketti. Paketti otetaan käyttöön Weblogicin palvelussa. Asennuspaketin asennuksen jälkeen voidaan käydä testaamassa tuotantoa vastaavassa ympäristössä esimerkiksi Seleniumilla tehdyillä testeillä ohjelmiston regressiota. Regressiotestauksella testataan, toimiiko ohjelmisto edelleen samalla tavalla kuin aikaisemmin on määritelty. Projektin loppuvaiheessa tai ennen tuotantoasennuksia voidaan tehdä myös virallisia käännöksiä. Näin varmistetaan, että kaikki toimii halutulla tavalla ennen paketin tuotantoon viemistä. Jos virallinen käännös menee testeineen läpi, voidaan paketti viedä tuotantoon. Tehtävien luonti onnistuu Jenkinsin käyttöliittymän yläosasta painamalla New Job. Seuraavaksi valitaan Build a free-style software project. Tätä toimintoa käyttämällä voidaan ohjelman käännöksen lisäksi hallinnoida versionhallintaa ja muita yhtäaikaisia tehtäviä. Esimerkiksi versionhallinnan avulla voidaan päätellä mikä tai kuka ohjelmiston rikkoi. Tällä sivulla valitaan Jenkinsin tehtävälle nimi. Tähän kannattaa laittaa jokin projektia kuvaava nimi kuten projektin nimi ja mitä tehtävä tekee esimerkiksi Projektinnimi-daily-build. Tehtävien kannalta testausprosessien suorittaminen kannattaa tehdä yhdistämällä useampi tehtävä. Esimerkki mallista voi olla versionhallinta, ohjelman kääntö, testikannan luonti, testien ajo ja testidatan poistaminen. Jokainen edellisen esimerkin kohta on oma tehtävänsä. Tehtävän nimen ja tyypin valinnan jälkeen avautuu tarkemmat tehtävän asetukset sivu. Tehtävän tarpeesta riippuen tälle sivulle asetetaan tehtävältä vaaditut asetukset. Koska tässä ei ole yksiselitteistä tapaa asettaa asetuksia, käydään seuraavaksi kohta kohdalta läpi mitä kukin asetus tekee.

23 Ensimmäiseksi käydään läpi kuvassa 7 olevat kohdat. Kaksi ensimmäistä kohtaa selittävät itsensä. Project name -kohdassa on edellisellä sivulla annettu projektin nimi. Tätä voidaan vielä tässä vaiheessa muuttaa, jos edellisellä sivulla tuli esimerkiksi kirjoitusvirheitä. Description-kenttään voidaan kirjoittaa lyhyt kuvaus tehtävästä ja teksti tulee näkyviin tehtäväsivulle, kun tehtävää valitaan tehtäväluettelosta. Discard Old builds -valinnalla voidaan rajoittaa kuinka monta tehtävän suoritusta tallennetaan järjestelmään. Tässä voidaan määritellä kuinka monta päivää tai tehtävän ajoa tallennetaan. Jos järjestelmässä on rajallisesti tilaa ja useita projekteja testattavana, tehtävien lopullinen koko on useita gigatavuja ja kasvaa kokoajan, koska vanhoja raportteja ei poisteta. Tässä projektissa tehtävien lokeja määriteltiin pidettäväksi maksimissaan 50 kappaletta palvelimen rajallisen tilan takia. Kuva 7. Jenkinsin asetukset - yleiset asetukset Tämän tutkimuksen kannalta seuraavista kolmesta valinnasta Disable Build -valinta on tärkeä. Tällä voidaan keskeyttää tämän prosessin ajo väliaikaisesti kunnes valinta otetaan pois käytöstä. Tämä ominaisuus on kätevä, kun tiedetään entuudestaan jonkin asian rikkovan prosessin. Esimerkkejä tällaisista tapahtumista voi olla versionhallinnan toimimattomuus tai isot päivitykset lähdekoodiin lyhyen ajan sisällä. Tapahtumista voidaan päätellä etukäteen, että prosessi hajoaa tai ilmoittaa virheestä. Kahteen muuhun valintaa ei tässä oteta kantaa. Asetusten oikealla puolella olevasta nuolesta saa lisää tietoa mitä kukin asetus tekee ja mahdollisesti ohjeita mitä kohtaan tulisi asettaa.

24 Seuraavaksi käsitellään kuvassa 8 näkyvät asetukset. Ensimmäisellä valinnalla (Quiet period) voidaan viivästyttää tehtävän aloitusta joitakin sekunteja. Tämä on kätevä asetus tilanteissa, joissa edellisen tehtävän prosessissa on jotain suorituksia, jotka vaikuttavat myös tähän tehtävään. Esimerkkitilanne voisi olla paketin asennus Weblogiciin ja halutaan varmistaa, että asennus ehtii valmistua ennen kuin esimerkiksi Selenium testit ajetaan. Retry count -valinnalla voidaan määrittää, kuinka monta kertaa Jenkins yrittää hakea päivityksiä versionhallinnasta ennen kuin luovuttaa ja ilmoittaa virheestä. Kahdella seuraavalla valinnalla (block build when upstream/downstream project is running) voidaan estää tehtävän ajo kunnes tähän projektiin tarvittavat tehtävät ovat vapautuneet muista suoritettavista tehtävistä. Use custom workspacella voidaan vähentää tehtävien vaatimaa kovalevytilaa. Yhdellä tehtävällä voidaan hakea versionhallinnasta tarvittavat lähdekoodit samaan kansioon ja muissa projektiin liittyvissä tehtävissä voidaan käyttää samaa projektin kansiota. Kansiolle voidaan antaa myös oma nimi. Tämä on tarkoitettu Jenkinsissä näyttämiseen siten, että ei näytetä kansion järjestelmän polkua vaan käyttäjän antamaa nimeä. Kuva 8. Jenkinsin asetukset projektiasetukset Kuvassa 9 määritellään projektin versiohallinnan asetukset. Toimeksiantajan tiimin projektissa käytetään Subversionia, joten määritellyt asetukset ovat Subversionversionhallintaohjelmistolle. Repository URL kohtaan laitetaan polku kokonaisena eli domain ja kohdekansio. Muihin asetuksiin ei tarvitse koskea, koska oletusasetukset ovat oikeat.

25 Kuva 9. Jenkinsin asetukset versionhallinta Kuvassa 10 valitaan asetukset, jotka aiheuttavat projektin käännöksen. Tehtävä voidaan käynnistää, kun toinen tehtävä valmistuu. Tehtävän suoritus voidaan myös käynnistää etähallintana esimerkiksi skripteillä. Lisäksi voidaan kääntää ajoitetusti tai kuvan tapauksessa tehdään kyselyitä versionhallintaan, jos versionhallintaan ei ole tullut muutoksia, niin tulevia tehtäviä ei ajeta. Ajastuksissa käytetään cron tyylisiä ajastuksia muutamilla pienillä muutoksilla. Ajastuksessa käytetään viittä eri arvoa tabulaattorilla tai välilyönnillä eroteltuna. Taulukossa 1 on määritelty jokaisen arvon tieto. Esimerkiksi tieto H/10 * * * * tarkoittaa, että tehtävä suoritetaan 10 minuutin välein. Ajastuksiin voidaan myös käyttää annotaatioita kuten @yearly, @annually, @monthly, @weekly, @daily, @midnight ja @hourly. TAULUKKO 1. Cron asteriksimerkkien selitykset ensimmäisestä alkaen. Minuutti Tunnissa oleva minuutti (0-59) Tunti Päivässä oleva tunti (0-23) Päivä Kuukauden päivä (1-31) Kuukausi Kuukausi (1-12) Viikonpäivä Viikonpäivä (0-7), 0 ja 7 tarkoittaa sunnuntaita

26 Kuva 10. Jenkinsin asetukset - käännöksen laukaisijat Seuraavassa kohdassa määritellään käännösasetukset. Kuvassa 11 on käytetty mallina Maven-työkalua. Komento projektin käännökseen on mvn clean install. Lisäksi Postbuild actions -kohdassa voidaan määritellä mitä tapahtuu tehtävän valmistumisen jälkeen. Tehtävän epäonnistumisesta voidaan asettaa lähetettäväksi sähköposti tietyille käyttäjille. Tämän lisäksi asennuksen jälkeisiin prosesseihin määritellään mitä tehtäviä suoritetaan, jos tehtävä onnistuu. Tässä kohdassa voidaan myös asettaa Javadocdokumentit julkaistavaksi. Vaikka projektit ovat määritelty ja ajastettu suoritettavaksi tietyin väliajoin, voidaan tehtävä myös suorittaa manuaalisesti tehtävälistan lopussa olevasta kellon näköisestä kuvakkeesta. Kuva 11. Jenkinsin asetukset - kääntäminen

27 6 YHTEENVETO Tässä opinnäytetyössä tutkittiin ketterän ohjelmistokehityksen menetelmiä ja jatkuvan integraation menetelmiä sekä toteutettiin toimeksiantajalle toimiva jatkuvan integraation järjestelmä. Tarkoituksena oli vähentää ohjelmistosuunnittelijoiden testaukseen käytettyä aikaa ja automatisoida testien ajoa. Näin huomataan ohjelmiston muuttuessa mahdollisimman nopeasti ohjelmistovirheet. Projektin aikana myös tuli esille keskustelua, kuinka ohjelmistotestausta tulisi kehittää kehitystiimin tarpeisiin. Tämän opinnäytetyön lisäksi on toinen opinnäytetyö, jonka tarkoituksena on selvittää erilaisten testausmenetelmien käyttöä tarkemmin, luoda testitapauksia sekä yhdistää testitapaukset jatkuvan integraation järjestelmiin. Koska testausmenetelmien testitapausten tuottaminen ei ehtinyt toteutua tämän projektin puitteissa, ei konkreettista ja kokonaisvaltaista hyötyä ehditty saamaan projektin aikana. Tarkoituksena on kuitenkin ylläpitää järjestelmää tulevien projektien osalta, jotta saadaan selviä tuloksia järjestelmän hyödyistä sekä kannattavuudesta. Ketterä ohjelmistokehitys ja jatkuvan integraatio ovat luontevasti liitoksissa toisiinsa. Usein muuttuvien määrittelyjen ja asiakkaan vaatimusten perusteella ohjelmistoa tulisi voida testata ketterästi. Tutkittaessa ketterien ohjelmistokehityksen menetelmiä, jokaisen menetelmän perusperiaate oli sama. Ideana on pystyä mukautumaan nopeasti asiakkaan vaatimuksiin ja ohjelmistokehitysprojektin elinkaaren aikana lyhyiden pyrähdysten (sprint) kautta saada valmiita kokonaisuuksia valmiiksi. Projektin vaiheet on pilkottu tarpeeksi pieniin osiin, jotta kehittäjien ei tarvitse tehdä useita päiviä kehitystyötä olematta ollenkaan yhteyksissä muuhun kehitystiimiin. Jatkuvan integraation järjestelmän kokoaminen opinnäytetyötä varten onnistui kohtalaisesti. Ohjelmiston ja käyttöjärjestelmän asentaminen oli suoraviivaista. Internetistä löytyi paljon työtä helpottavaa dokumentointia ja keskustelupalstoilta vastaavien ongelmien kanssa painivia henkilöitä. Projektin kannalta vaadittavien testien puutteet vaikeuttivat tulosten analysointia. Jo olemassa olevien testien (yksikkötestit) osalta saimme kiinni joitakin virheitä heti, kun versionhallintaan saimme uutta päivitystä käyttäjiltä. Kuitenkin yksikkötestit ovat vain pieni osa testaamista, joten selvää johtopäätelmää tästä ei voitu tehdä.

28 Jenkinsin valinta projektiin oli hyvä, koska ohjelmisto on vaatimuksiltaan kevyt. Se on mahdollista myös asentaa pilvipalveluun myöhemmin, jos palvelusta saadaan tulosten valossa hyötyä. Jenkinsiä päivitetään aktiivisesti ja ohjelmistoon löytyy käteviä lisäosia testauksen avuksi, kuten esimerkiksi koodin kattavuutta esittävä lisäosa. Lisäksi Jenkinsin ollessa avointa lähdekoodia, ei ohjelmiston ja järjestelmän käyttöönottoon vaadita suuria panostuksia rahallisesti. Markkinoilta löytyy myös muitakin maksullisia sekä ilmaisia ohjelmistoja. Jokaisen jatkuvan integraation järjestelmää suunnittelevan kannattaa tutkia vaihtoehtojaan ja vaatimuksiaan, joiden perusteella valitsee ohjelmiston.

29 LÄHTEET Ahmed, A. 2010. Agile Software Development: Impact on Productivity and Quality. Viitattu 12.10.2013. http://ieeexplore.ieee.org.elib.tamk.fi/xpl/articledetails.jsp?arnumber=5492703 Bamboo. Luettu 12.04.2013. http://www.atlassian.com/software/bamboo/overview Berg, A. 2012. Jenkins Continuous Integration Cookbook. Birmingham, UK: Packt Publishing Ltd. Developer works: Continuous integration in agile development. 2012. Luettu 24.10.2013. https://www.ibm.com/developerworks/rational/library/continuous-integration-agiledevelopment/ Extreme Programming: A gentle introduction. 2009. Luettu 13.10.2013. http://www.extremeprogramming.org/ Fowler, M. 2006. Continuous Integration. Luettu 12.04.2013. http://www.martinfowler.com/articles/continuousintegration.html Hudson. Luettu 12.04.2013. http://hudson-ci.org/ JMeter. 2013. Luettu 12.04.2013. http://jmeter.apache.org/ JUnit. 2013. Luettu 12.04.2013. http://junit.org/ Kawalerowicz, M. & Berntson, C. 2011. Continuous Integration in.net. Shelter Island, NY, USA: Manning Publications.

30 Mountain Goat Software. Luettu 10.11.2013. http://www.mountaingoatsoftware.com/agile/scrum/images/ MSDN: Continuous integration using TFS on the cloud. 2013. Luettu 24.10.2013. http://blogs.msdn.com/b/africaapps/archive/2013/03/05/continuous-integration-usingtfs-on-the-cloud.aspx Oracle. Luettu 12.04.2013. http://www.oracle.com/ SeleniumHQ. Luettu 12.04.2013. http://www.seleniumhq.org/ Spektor, A. 2013. Instant Eclipse Application Testing How-to. Birmingham, UK: Packt Publishing Ltd. VersionOne. Luettu 12.10.2013. http://www.versionone.com/agile101/continuous_integration.asp