Minimumkrav för ett CI-system

Examensarbete

15 högskolepoäng, grundnivå

Minimumkrav för ett CI-system

On The Minimum Requirements of a CI-system

Petrus Kiendys

Shadi Al-Zara

Examen: Högskoleingenjörsprogram 180 hp

iii

Tack till medverkande

Vi vill tacka följande personer för deras medverkande och stöd under detta examensarbete: Tore Nestenius (extern handledare från Edument AB) för handledning och kontinuerligt stöd under arbetets gång, i synnerhet för den hjälp vi fick under arbetets tidiga fas då vi inte riktigt visste hur vi skulle komma igång. Tore tillhandahöll oss med resurser som vi fick användning av och tillförde en praktisk aspekt av examensarbetet.

Mia Persson (intern handledare) för handledning och stöd vid moment och aspekter av examensarbetet som vi haft begränsad kunskap om. Vi har fått hjälp med bl.a. utformningen av marknadsundersökningen, kategorisering av funktionella och icke-funktionella krav samt vilka vetenskapliga metoder som är mest lämpliga för att angripa vår frågeställning.

Joakim Hellberg (IT-support) för tillhandahållandet av en fysisk server som vi kan ansluta oss till via fjärrstyrning för att utföra praktiska moment av examensarbetet.

Annabella Loconsole (ämnesexpert inom kravhantering) för tips om metoder som kan användas när man utformar krav för ett IT-system samt en inblick i omfattningen av att utföra en formell kravhantering av ett IT-system.

Ulrik Eklund, Kristina Ericson och resten av lärarlaget för konkreta tips under informationssökningen av vetenskapliga artiklar, utformning av referenser enligt IEEE-referensstil och hänvisningar till litteratur för att få en bättre förståelse för den vetenskapliga metoden.

iv

Sammanfattning

När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas. En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.

Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”. Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel.

Nyckelord: continuous integration, CI, CI-system, TeamCity, funktionella krav, icke-funktionella krav

v

Abstract

When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.

This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”.

The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.

Keywords: continuous integration, CI, CI-system, TeamCity, functional requirements, non-functional requirements, quality attributes

vi

Innehållsförteckning

1. Inledning ... 1

1.1 Bakgrund ... 1

1.2 Målgrupp för examensarbete ... 2

1.3 Syfte och frågeställning ... 2

1.3.1 Motivering till ämnesval ... 2

1.4 Uppdragsbeskrivning och avgränsningar ... 3

1.4.1 Internt uppdrag ... 3

1.4.2 Externt uppdrag ... 3

1.5 Översikt över området ... 4

2. Teoretisk beskrivning ... 7

2.1 Systemutvecklingsmetoder ... 7

2.2 Continuous Integration (CI)... 8

2.2.1 Vad är CI? ... 8

2.2.2 Varför CI-system används ... 9

2.3 CI-system verktyg ... 9

2.3.1 CI-system grundläggande verktyg ... 9

2.3.2 CI arbetsflöde ... 10

2.4 För- och nackdelar med CI-system ... 11

2.4.1 Fördelar med CI-system ... 11

2.4.2 Nackdelar med CI-system ... 12

2.5 Continuous Integration bästa praxis ... 13

3. Metod ... 14

3.1 Litteraturundersökning ... 15

3.1.1 Utförande av litteraturundersökning ... 15

3.2 Undersökningsmetod ... 15

3.3 Datainsamling och analys... 16

3.3.1 Utförande av marknadsundersökning ... 17

3.4 Etiska principer... 17

3.4.1 Informationskravet ... 18

3.4.2 Konfidentialitetskravet ... 18

3.4.3 Nyttjandekravet ... 18

3.5 Metod för övriga moment ... 18

3.5.1 Utförande av kursmaterial ... 18

3.5.2 Uppbyggnaden av CI-systemet ... 19

vii

4. Resultat och analys ... 22

4.1 Krav för ett CI-system ... 22

4.1.1 Funktionella krav ... 22

4.1.2 Icke-Funktionella krav ... 23

4.1.3 Hur ställer man upp krav för system? ... 24

4.1.4 Kravtest och utvärdering ... 25

4.2 Resultat från marknadsundersökningen ... 25

4.3 Resultat från litteraturundersökning ... 38

4.4 Användbarhetstestning ... 42

4.4.1 Kategorisering av användbarhet via användbarhetsattribut ... 42

4.4.2 Kategorisering av användbarhet via huvudområden ... 42

4.4.3 Indelning av beståndsdelar för användbarhetsscenario ... 43

4.4.4 Uppställning av användbarhetsscenario ... 45

4.4.5 Uppställning av testformulär och användarenkät ... 46

4.4.6 Resultat från användbarhetstestning ... 47 5. Slutsats ... 57 6. Diskussion ... 60 6.1 Diskussion av kraven ... 60 6.2 Förbättringar ... 61 6.3 Fortsatt forskning ... 66 Referenser ... 67 Bibliografi ... 67 Bilagor ... 71

Sida | 1

1. Inledning

1.1 Bakgrund

Utvecklare är intresserade av att skapa de bästa möjliga applikationer för sina kunder på kortast möjliga tid. Men applikationer kan bestå av många olika delar och moduler, vilket skapar stora och komplexa applikationer. Således blir utvecklingsprocessen av mjukvara svårare även om man använder sig av avancerade verktyg. En lösning till detta är att automatisera vissa delar av utvecklingsprocessen. Continuous integration (CI) är ett av de bästa sätten att göra detta [1]. När många team och utvecklare samarbetar med varandra är continuous integration avgörande för att leda framgång eller misslyckande av projektet [2]. Continuous integration (CI) är en del av Extreme Programming (XP) metoden. XP utvecklades 1997 under Chrysler Comprehensive Compensation System (C3) projektet av Kent Beck och Ron Jeffries [3]. Metoden har blivit populär inom mjukvaruutveckling. Det har visat sig att användning av metoden kan förbättra releasefrekvens av mjukvara och förutsägbarhet, dvs. förmågan för utvecklare att förutsäga när färdig leverans av stabil mjukvara kan ske. Metoden har även visat sig öka utvecklarnas produktivitet och förbättra kommunikationen inom ett utvecklingsteam, bland andra förmåner [4, s. 1].

CI är en process eller en uppsättning rutiner som ett utvecklingsteam kan jobba utefter. CI kräver inga verktyg för att kunna tillämpas, däremot kan processen stödjas på ett mer effektivt sätt mha CI-system. CI-system kan bl.a. automatisera olika processer som är grundläggande för CI och på så sätt förenkla, upprätthålla och förbättra processen [5]. Mer om detta kan läsas i avsnitt 2.5 “CI-system bästa praxis”.

CI-system används alltmer i näringslivet vid mjukvaruutveckling för att effektivisera arbetsprocessen och tillföra ökad produktionsvärde [6].

CI-system ska enligt [7] kunna utföra 3 grundläggande funktioner som utgör cykeln för continuous integration:

● Versionshantering av resurser (version control system) för att utföra insamling av resurser (källkod, byggskript)

● Bygge av system som utför kompilering eller annan behandling av källkod, även utförandet av fördefinierade uppgifter som körning av byggskript och dylikt.

● Deployment management som tar hand om förpackningen och leveransen av stabil mjukvara.

Något som sällan diskuteras är om det finns speciella krav som ett CI-system måste uppfylla för att vara tillfredsställande för ett utvecklingsteam och när systemet är användbart. Detta ska tittas närmare på i denna rapport. Läsaren hänvisas till avsnitt 2.2-2.5 för en teoretisk beskrivning kring vad CI-processen är och hur CI-system stödjer denna process.

I avsnitt 2.2.1 definieras vad som menas med ett CI-system och i avsnitt 2.2.2 presenteras ett antal argument för varför CI-system bör användas. I avsnitt 2.3.1 går vi igenom olika verktyg som används i samband med CI-system och i avsnitt 2.3.2 förklaras arbetsflödet för system. Avsnitt 4.1.1 och 4.1.2 handlar om funktionella och icke-funktionella krav för CI-system. Hur de ställs upp, valideras och testas förklaras i avsnitt 4.1.3 och 4.1.4.

Sida | 2 För att ge läsaren en klar bild över hur och varför CI-system används så anges i avsnitt 2.5 bästa praxis för continuous integration.

1.2 Målgrupp för examensarbete

Målgruppen för denna studie är utvecklare och systemadministratörer inom olika organisationer som tänker introducera continuous integration i sin verksamhet. Examensarbetet genomfördes efter en 3-årig högskoleingenjörsutbildning i Data och Telekom vid Malmö Högskola och kan även vara intressant för studenter som genomför en kandidatexamen i liknande områden. Även tekniskt kunniga individer som är intresserade och vill lära sig mer om CI-system kan ha nytta av denna studie.

Rapporten är skriven på så sätt att nya termer förklaras då dem påträffas, läsaren förväntas därför läsa från början till slut. Dock har vi angett hänvisningar till relevanta avsnitt när detta krävs för att underlätta för läsaren.

1.3 Syfte och frågeställning

Syftet med denna studie är att utforska olika egenskaper hos CI-system och systematiskt kategorisera dessa samt definiera minimumkrav som CI-system måste uppfylla för att vara tillfredsställande för ett utvecklingsteam.

Vår frågeställning är följande: Huvudfrågor:

1. Vilka funktionella och icke-funktionella krav måste CI-system uppfylla för att vara till nytta för användning?

2. Kan man enligt fastställda krav testa, värdera och jämföra CI-system? Delfrågor:

3. Vilken mjukvara för CI-system används mest? 4. Vilka för- och nackdelar finns det för ett CI-system?

5. Hur pass utbredd är användningen av CI-system bland utvecklare inom företag som använder sig av dessa system?

6. Leder CI-system till en mer effektiv utvecklingsprocess för mjukvaruutvecklare?

1.3.1 Motivering till ämnesval

Vi har valt att utforska CI-system eftersom diskussioner med vår externa handledare (Tore Nestenius) har påvisat att det finns ett intresse och behov i industrin att bedriva ytterligare undersökning och forskning kring ämnet. Tore Nestenius jobbar för “Edument AB” som sysslar med systemutveckling och utbildning inom IT. Företaget jobbar just nu med att utforma en rad olika kurser som kan användas för workshops och 3-dagars seminarier. Några månader innan examensarbetet satte igång hade vi tid att undersöka olika förslag till examensarbetet. Vi fick en del förslag både internt på Malmö Högskola och utifrån.

Efter fortsatta diskussioner med Tore stod det mellan 2 förslag: “Practical continuous Integration and deployment (with TeamCity)” och “Application visualization in .NET (with Microsoft Azure)”. Vi kom fram till att det är mer relevant och intressant att undersöka

Sida | 3 “continuous integration” och valde därför detta förslag. Förslaget presenterades sedan för Malmö Högskola och vår examinator. Tillsammans med våra handledare diskuterade vi fram en infallsvinkel och avgränsning för ämnesområdet, mer om detta beskrivs i nästa avsnitt.

1.4 Uppdragsbeskrivning och avgränsningar

Vi hade både ett internt uppdrag som utfördes åt Malmö Högskola och ett externt uppdrag som utfördes åt Edument AB. Uppdragen och avgränsningarna beskrivs utförligt nedan.

1.4.1 Internt uppdrag

I början var det interna uppdraget att utforska CI/CD (continuous integration and deployment) i stort. Därför började vi med att utföra en grundlig förstudie (se bilaga 5) där vi lärde oss mer om CI/CD. Vi tittade även på närliggande koncept så som agila metoder. Efter diskussioner med vår examinator och interna handledare kom vi fram till att uppdraget måste avgränsas och begränsas till något som är genomförbart och verifierbart. Vi valde därför att avgränsa oss från att titta på CI som en process i stort och dess inverkan på utveckling av mjukvara till CI-system som är tekniska system för att stödja denna process och vilka krav dessa system måste uppfylla för att vara tillfredsställande för utvecklingsteam.

Uppdraget delades upp i fyra delar:

1. Vi utförde en analys av vilka minimumkrav som behöver uppfyllas för att ha ett välfungerande CI-system. Kraven togs fram via en litteraturundersökning (se bilaga 3) och en marknadsundersökning. Därefter delade vi in kraven i specifika områden dvs. funktionella och icke-funktionella krav för att systematiskt kunna utföra ett kravtest utefter kraven. Således är slutsatsen för vilka krav ett CI-system måste uppfylla förankrat i både vetenskap och industriella erfarenheter.

2. Efter att vi kom fram till vilka krav som var viktigast för CI-system att uppfylla så byggde vi upp en TeamCity-server. Vi avgränsade oss till endast en implementation för att vara säkra på att kravtest och behandling av data kan utföras i tid.

3. När TeamCity-servern var körbar testades denna enligt de krav som vi ställt upp. Man kan med hjälp av testresultaten redogöra TeamCitys lämplighet för användning på ett mer objektivt och systematiskt sätt till skillnad från att endast uttrycka en subjektiv åsikt.

4. Den sista delen av examensarbetet bestod av att behandla data som vi fick fram från testfasen. Under denna del diskuterar och presenterar vi data samt dra slutsatser för TeamCity och CI-system utifrån dessa data.

1.4.2 Externt uppdrag

En artefakt som producerades under examensarbetet är kursmaterial till vår externa handledare. Kursmaterialet består av en teoretisk genomgång av CI och CI-system, samt en praktiskt “get started with CI” genomgång mha CI-mjukvara TeamCity.

Sida | 4 Vår externa handledare hade specifika krav kring hur kursmaterialet ska vara utformat:

● Kursmaterialet ska vara skrivet på engelska

● Kursmaterialet är tänkt att användas för en 3-dagars kurs som består av ○ 400-500 powerpoint slides eller 10 timmars kursmaterial

■ Moduler består av ca 40-60 slides i timmen ■ 2 huvuddelar som i sin tur består av moduler

● CI/CD teoretisk bakgrund och varför det används

● Praktiskt exempel på hur man kommer igång med TeamCity Vi insåg dock att arbetsbördan för att producera denna mängd material är för stor och att detta realistiskt sett inte kan rymmas inom det här examensarbetet. Därför kom vi överens med vår externa handledare att minska antalet slides men försöka hålla kvaliteten hög för det kursmaterial som vi hinner få ut. Vi fick under examensarbetet fram ca 280 slides sammanlagt för de båda huvuddelarna (se bilaga 1). Processen att utforma kursmaterialet löpte parallellt med tidigare nämnda delproblem.

1.5 Översikt över området

Vår förstudie (bilaga 5) innehåller relevanta böcker, vetenskapliga artiklar och yrkeskunskap som vi tagit del av för att genomföra och förankra studien i vetenskap. Under litteratur- undersökningen (bilaga 3) har vi även tagit del av tidigare studier kring ämnet CI-system och även den innehåller resurser som kommit till nytta.

Nedan följer en sammanfattning av vetenskapliga artiklar, böcker och webbartiklar som kommit till störst nytta för vår studie samt en förklaring till varför vi valt just dessa resurser. Vi har utgått från följande källor för områdena:

● Beskrivning av olika begrepp inom CI:

○ För att få kunskap om CI och beskriva det som en del av mjukvaruutvecklings- verktyg läste vi den vetenskapliga artikeln [2] som beskriver fördelar med att använda automatiserade mjukvaruutvecklingsverktyg vid mjukvaruutveckling av komplexa system. Ki & Song anger flaskhalsar i mjukvaruutveckling för större projekt och presenterar en open-source lösning som förbättrar utvecklingsmiljön.

○ Det finns många artiklar som definierar CI på nätet. Webbartikeln [5] av Martin Fowler är en av de mest tillförlitliga källorna när det gäller CI. Den har hög relevans för vår studie eftersom man får en genomgång av vad CI är, vilka bästa praxis det finns för CI och varför det bör tillämpas. Med hjälp av artikeln kunde vi bl.a. definiera begreppet CI samt tolka och på svenska sammanfatta bästa praxis för CI i denna studie.

○ Ytterligare en intressant webbartikel är [12], där författaren går in på en processbeskrivning för hur ett CI-system bör fungera samt beskriver grunderna (viktiga komponenter) för ett CI-system. Den hjälpte oss att förstå och beskriva CI-processen i vår studie.

○ Den vetenskapliga artikeln [15] som är skriven i form av “case study”, visar hur CI-system och automatiserade tester används för att utveckla robusta

Sida | 5 C4ISR system. Artikeln beskriver koncepten build agents och build configuration som används i TeamCity. Författarna beskriver även testning utförligt. Av artikeln fick vi veta hur ett CI-system kan tillämpas i industrin. ○ En bok som kommer till stor användning är [9]. Den beskriver begreppet CI

och dess praxis från grunden samt går den igenom andra effektiva processer som utförs av CI-system, såsom databasintegration, testning och återkoppling. I vår studie definierade vi begreppet CI och beskrev olika CI-processer med hjälp av denna bok.

○ Slutligen vill vi nämna den vetenskapliga artikeln [4] som genom en litteraturstudie visar att det finns skillnader i hur olika utvecklare brukar och tolkar continuous integration. Denna studie är väldigt lik i karaktär till vår studie, inte minst pga. vi i vår studie också utfört en litteraturundersökning. ● Beskrivning av olika komponenter och verktyg för CI-system:

○ Introduktionsboken [8] var till stor hjälp för att kunna bygga vårt CI- system då den beskriver steg för steg hur man bygger upp en TeamCity-server. ○ En annan bok vi tyckte var intressant att belysa är [1]. Den beskriver hur man

implementerar ett system i .NET samt ger en beskrivning av olika CI-servrar. Boken hjälper utvecklare som vill komma igång med CI men vet inte hur. I vår studie använde vi boken för att beskriva olika komponenter och viktiga verktyg som ingår i ett CI-system.

○ Boken [10] är mycket intressant för vår studie eftersom den innehåller de principer och tekniska metoder som används i CI-system och beskriver olika komponenter och funktioner i systemet.

○ Webbartikeln [14] anger fördelar med att använda sig av CI-system både genom en inledning som beskriver vad ett CI-system är och praktiska exempel på hur man kommer igång med det. I den praktiska beskrivningen förklarar författaren hur man förbereder ett större projekt för automatisering via byggskript. Vi fick stor hjälp av denna artikel då den förklarade hur byggskript kan användas.

○ Den vetenskapliga artikeln [7] beskriver inlärningsprocessen då man inrättar continuous integration för en grupp utvecklare. Författaren tar utförligt och explicit de grundläggande komponenter som ett CI-system består av och han förklarar hur CI-system kan motverka långa integrationsprocesser och göra de mindre och mer hanterbara.

● Beskrivning av olika krav för CI-system:

○ En intressant webbartikel när det gäller CI-krav är [11]. I denna artikel listas några krav som ett CI-system måste uppfylla för att kunna fungera och erbjuda utvecklare kontinuerliga kvalitetskontroller. Fokus för artikeln sammanfaller med vår frågeställning beträffande CI-krav.

Vissa böcker och artiklar som vi använde oss av när vi undersökte krav för CI-system [17, 25-26, 42] nämner inte krav specifikt för CI-system utan det är allmänna beskrivningar om hur krav hanteras i sammanhang där man utvecklar mjukvara.

Sida | 6

2. Teoretisk beskrivning

2.1 Systemutvecklingsmetoder

Inom organisationer som arbetar med mjukvaruutveckling är det viktigt att använda någon typ av utvecklingsmetod för att hantera och förbättra utvecklingsprocessen [17].

De mest kända traditionella metoderna inom mjukvaruutveckling är följande:

● Vattenfallsmetoden är en metod som använts länge och är en av de traditionella sekventiella metoderna i vilket arbetsprocessen övergår från ett stadie till ett annat utan att återgå till föregående stadier [18].

Fig. 1: Vattenfallsprocessen [18]

● Agila metoder kan sägas vara moderna anpassningar av de traditionella metoderna och innefattar en grupp av mjukvaruutvecklingsmetoder. De utvecklades för att producera mjukvara av hög kvalitet under kortare tid och för att effektivisera utvecklingsprocessen. Metoderna är designade på så sätt det blir lättare för utvecklare att identifiera kravförändringar under utvecklingsprocessen. Utvecklargrupper som använder sig av agila metoder brukar ha en bättre kontakt med kunden och övriga intressenter under utvecklingsprocessen. [19-20]

Sida | 7 ● Extreme Programmering (XP) är en del av de agila metoderna och utvecklades 1997

under Chrysler Comprehensive Compensation (C3) projektet av Kent Beck och hans utvecklingsteam. XP syftar till att förbättra kvaliteten på mjukvaran, förkorta leveransplaner och vara en metod som är anpassad till föränderliga kundkrav. [3, 21]

Fig. 3: XP practices [21]

"Continuous Integration originated with the Extreme Programming development process, as one of its original twelve practices" [5].

2.2 Continuous Integration (CI)

2.2.1 Vad är CI?

Martin Fowler påpekar att continuous integration är en metod som ofta används i mjukvaruutveckling där utvecklare i ett team integrerar sitt arbete minst en gång om dagen vilket ofta leder till flera integrationer per dag. Varje integration verifieras, kontrolleras och testas för att så snabbt som möjligt upptäcka fel i integrationen av ny kod [5].

Paul Duvall anger en annan definition där han menar att CI är en taktik som används mest inom mjukvaruutveckling för att det garanterar hälsosamma IT-system och stabila applikationer. Det ökar mjukvaruutvecklares förmågan att göra förändringar i deras kod och garanterar en snabb återkoppling om något fel uppstår i programvaran. Detta möjliggörs genom att köra ett bygge med varje förändring [9].

Sida | 8

2.2.2 Varför CI-system används

K. Marcin och B. Craig anger flera skäl till att använda CI i utvecklingsprocessen som följande [1]:

● Minskade risker: CI skapar bättre mjukvara pga. tidiga tester och integrationer av ny kod under utvecklingsprocessen.

● Paketerbar mjukvara: När installationsprocessen automatiseras kommer programvaran att installeras som den ska.

● Ökad synlighet för projektet: Återkopplingsmekanismen ger en möjlighet för projektmedlemmar att se byggresultaten och visar var problemen uppstår. ● Snabba inkrementella byggen: Att snabbt bygga och testa innebär att utvecklare

snabbare får resultat, vilket bistår utvecklarna att fixa problemen tidigare i utvecklingsprocessen.

CI-system kan både användas i små, medelstora och stora IT-verksamheter. CI-system kan även användas vid andra verksamheter, bl.a. uppbyggnad av kunskapsbaser [22], men vi kommer inte titta närmare på dessa användningsområden.

2.3 CI-system verktyg

En komplett CI-process använder sig av flera verktyg. Man kan köpa dyra CI-system som är funktionsrika och ofta enkelt att installera och underhålla, eller så kan man använda verktyg som inte är lika funktionsrika och ofta kräver en del arbete för att ställa upp, men är antingen gratis eller till låg kostnad [1].

2.3.1 CI-system grundläggande verktyg

Grundläggande CI-system verktyg enligt K. Marcin och B. Craig [1] är: 1. Versionshanteringssystem (eng. source code control)

När utvecklare lägger upp sin kod i en gemensam kodbas gör de en så kallad incheckning (eng. commit) av källkoden. Varje revision av källkoden lagras i en så kallad centralkatalog (eng. repository). Centralkatalogen tillhandahåller utvecklare med den senaste revisionen av källkoden som lagts in och arkiverar samtidigt tidigare revisioner så att man bl.a. ska kunna återställa källkod till ett tidigare tillstånd om det behövs men även för att spåra förändringar som skett över en viss tid. Centralkatalogen används inte bara för att lagra och arkivera källkod utan används även för att lagra andra artefakter så som kundsanteckningar, designskisser, dokumentation och liknande.

2. Continuous Integration server

CI-servern pollar källkodskontroll-systemet med ett jämnt intervall för att upptäcka förändringar (tittar om en ny revision har lagts in). När en förändring upptäckts kan CI-servern hämta hem kodbasen på nytt och t.ex. trigga ett nytt bygge och köra enhetstest. CI-servern samordnar även de övriga stegen i CI-processen.

Sida | 9 3. Bygghanterare (eng. build manager)

Verktyget hanterar själva kompileringen och bygge av källkod och övriga projektfiler. Vissa projekt implementeras kanske för olika plattformar eller olika inställningar för kompilatorn. Build managern sköter detta arbetet och ser till att rätt kompilator används för att kompilera källkoden. Efter kompilering kan binärfilerna användas för olika syften t.ex. paketeras och distribueras eller testas dynamiskt, dvs. systemet testas under körtid till skillnad från statiska test där man läser av källkoden för att hitta fel.

4. Enhetstest (eng. unit testing)

Detta verktyg kör enhetstester som utvecklarteamet skriver för sin applikation. När testerna genomförts genereras resultatdata som brukar sparas i loggar (t.ex. XML-format) eller i textfiler. Loggarna kan sedan avläsas av CI-systemet varefter olika åtgärder kan vidtas beroende på huruvida testerna lyckades eller misslyckades. 5. Återkopplingsmekanism (eng. feedback mechanism)

Utvecklare vill ofta hålla sig uppdaterade om huruvida deras senaste incheckningar av källkoden gick igenom tester och byggdes korrekt. Detta är speciellt viktigt om utvecklarens incheckning resulterade i ett misslyckat bygge, då måste detta misstag åtgärdas så fort som möjligt för att kodbasen ska återgå till ett stabilt läge. Utvecklare blir ofta meddelade om misslyckade byggen genom en feedbackmekanism, där dem får feedback via en rad olika kommunikationskanaler så som t.ex. email, SMS, IM, dashboard.

2.3.2 CI arbetsflöde

Sida | 10 CI-processen börjar med att en build server i CI-systemet hämtar den senaste revisionen från ett versionshanteringssystem när den upptäcker att en ny revision lagts in [22, s. 97]. CI-systemet kommer sedan att köra fördefinierade skript som anger hur den hämtade källkoden ska byggas och övriga konfigurationer kring bygget. När applikationen har byggts enligt skriptet körs relevanta automatiserade tester.

De flesta CI-systemmjukvaror inkluderar ett webbinterface som visar en lista över byggen som kör och möjliggör en insikt för utvecklare i byggprocessen och avläsning. Här kan utvecklare se om deras revision av källkoden är stabil eller om något gick fel på vägen.

Denna process avslutas i produktion och lagring av resulterande artefakterna såsom binärfiler eller installationspaket och distribueras så att testare och kunder enkelt kan hämta den mest uppdaterade och stabila versionen av applikationen.

De allra flesta CI-system kan konfigureras med hjälp av ett webbgränssnitt eller via terminalkommandon samt skript.

2.4 För- och nackdelar med CI-system

Det finns flera fördelar och nackdelar med CI-system. Vi har genom rapporten främst belyst fördelar med CI-system som möjliggör effektivisering av olika arbetsprocesser för systemutvecklare. I följande avsnitt vill vi sammanfatta dessa fördelar men även gå in på några fördelar med CI-system som inte nämns lika ofta. Även om vi i vår studie vill anföra argument för varför CI-system kan vara gynnsamma för vissa situationer måste vi givetvis även vara objektiva och opartiska i vår bedömning, därför kommer vi även redogöra nackdelar med att använda sig av CI-system, främst de organisatoriska svårigheter som kan uppstå då utvecklare överger vissa rutiner och arbetsmetoder för att tillämpa continuous integration med hjälp av CI-system.

2.4.1 Fördelar med CI-system

CI-system har många fördelar [33, 41, 49-50] och vi har nämnt de flesta i olika avsnitt av rapporten. Nedan anger vi och sammanfattar några fördelar som vi tycker är extra viktiga men även fördelar som inte ofta brukar nämnas i sammanhang där man diskuterar CI-system:

● Smidigare integration av ny kod. Utvecklare undviker långa integrationsfaser i utvecklingsprocessen genom att dela upp arbetsuppgiften i små delar som oftare kan integreras in i kodbasen.

● Automatisering av bygg-, testning- och distributions-processer.

● Hjälper till att skapa CRISP (Complete, Repeatable, Informative, Schedulable, Portable) byggen av systemet som är under utveckling via CI-systemet. Med CRISP menar vi:

o Complete - Bygget av systemet ska kunna ske på en “ren maskin” och utan att utvecklaren ska behöva utföra en manuell rutin som kan medföra mänskliga fel, med andra ord ska bygget av systemet ske med ett knapptryck och utföras på ett maskinellt och automatiserat sätt.

o Repeatable - Bygget av systemet ska vara repeterbart, dvs. det resultat som skapas när kompilatorn och övriga behandlingsverktyg bearbetat källkod ska inte ändras över tiden och inte bero på “yttre faktorer” och verktyg,

CI-Sida | 11 systemet ska förses med all inmatning inkl. byggskript i centralkatalogen där hela kodbasen ligger.

o Informative - Om något går fel i bygget av systemet så ska man snabbt kunna fixa dessa fel. Detta kan man endast göra om man har ett CI-system som utförligt loggar olika händelser och statistik. Med hjälp av dessa loggar kan man snabbt se var fel inträffade. Det är viktigt att man har mekanismer som tidigt kan spåra oväntade förändringar eller beteenden för systemet som utvecklas.

o Schedulable -Utvecklare ska kunna schemalägga byggen, det ska inte behövas manuella utlösare för att köra byggen.

o Portable - Systemet ska kunna byggas från vilken arbetsstation som helst, oavsett vilken plattform och operativsystem körs. Detta kan ske via CI-system och man bör därför förlita sig på CI-systemet för att byggen istället för att utföra det på enskilda arbetsstationer.

● Snabbare och enklare att hitta fel och fixa buggar, både semantiska och syntaktiska fel men även kodningskonventioner kan upprätthållas via CI-system.

● Bättre översikt över projektet och fortskridande. Detta ökar förtroende mellan utvecklarna men även mellan kunden och slutanvändare som kan se fortskridandet av projektet mer kontinuerligt.

● Generera distributionspaket när som helst, då kodbasen alltid förväntas vara stabil (fixas inom en kort tidsram om så inte är fallet). Distributionspaketet kan även genereras från vilken arbetsstation som helst då det är CI-systemet som sköter detta och inte enskilda arbetsstationer vars miljöer kan skiljas åt. Detta anknyter till föregående punkt då utvecklare kan förse kunden med distributionspaket i utvärderings- eller demonstrationssyfte mer kontinuerligt under projektets gång. ● Snabb återkoppling och rapportering när fel inträffar. Utvecklaren som har gjort fel

är snabbt underrättad om fel som finns och kan åtgärda dessa fel så att medarbetare som ska fortsätta med arbetet inte använder sig av icke-fungerande kod eller artefakter.

2.4.2 Nackdelar med CI-system

Det är givetvis inte bara intressant att titta på vilka fördelar ett CI-system har men även vilka nackdelar som finns och hur mycket tid och resurser som måste läggas ner för att komma igång och tillämpa CI-system på en industriell nivå. Det är rätt svårt att få fram information kring detta eftersom de allra flesta källor som beskriver CI-system argumenterar för användningen av CI-system snarare än emot. Dock har vi hittat information kring nackdelar med system och vilka svårigheter som kan uppstå när man försöker använda sig av CI-system inom olika verksamheter [33, 49].

● Det tar tid att ställa upp och komma igång med CI-system. Detta fenomen inträffar när man omstrukturerar eller ska tillämpa nya rutiner på arbetsplatsen i alla möjliga sammanhang, inte bara när CI-system ska introduceras. Oavsett vilken rutin som ska ändras så finns det alltid en “förlust av tid” när man introducerar något nytt. Det tar inte bara tid att ställa upp ett CI-system, man måste även ha kompetens och förhoppningsvis tidigare erfarenhet av att ställa upp CI-system för att det ska gå så smidigt som möjligt.

Sida | 12 ● Det krävs välutvecklade tester (t.ex. enhetstester och integrationstester) för att ta

del av fördelarna med automatisering. Liksom föregående punkt kan det ta ett tag innan utvecklare skiftar från att skriva mjukvara som kan kompileras (men som kanske ändå innehåller fel) till ett testdrivet tillvägagångssätt där man först utvecklar en testsvit (eng. test suite) för att sedan påbörja implementationen av systemet. ● Frekventa förändringar i kodbasen kan skapa ett tillstånd av förvirring för utvecklare.

Detta är kanske mer vanligt för utvecklare som tidigare inte arbetat med CI-system. Denna nackdel är dock mer pga. dålig inlärd rutin eller praxis snarare än en direkt nackdel eller motargument för att använda CI-system. Ett sätt att motverka denna nackdel är att utbilda utvecklare (kanske via en snabbkurs i hur man använder CI-system) och inge förtroende samt förklara hur det nya arbetsflödet kommer att se ut då utvecklare som arbetat med vattenfallsmodellen är mer vana att jobba med större moduler över längre tid istället för att dela upp arbetet i mindre arbetspaket. ● Ett bra CI-system betyder höga kostnader gällande mjukvara och hårdvara. Detta kan

vara ett problem för verksamheter som inte har en budget att investera i ytterligare resurser. Kostnaderna omfattar inte endast köp av mjukvara och hårdvara, det finns ytterligare kostnader som tillkommer när man t.ex. måste reparera servrar eller uppdatera mjukvaran. Problem kan även uppstå om man upptäcker att ett visst mjukvarupaket inte uppfyller de krav som man ställer på sina utvecklingsverktyg och man måste då migrera till och anpassa en annan lösning.

Ovan har vi listat en rad olika nackdelar. Att hitta integrationsfel och buggar tidigt i utvecklingsprocessen sparar både tid och pengar över livslängden på ett projekt [49]. Därför vill vi påstå att fördelarna med att använda sig av ett CI-system uppväger nackdelarna som man stöter på när man först börjar använda sig av ett CI-system.

2.5 Continuous Integration bästa praxis

För att ge en mer handfast bild av hur CI-processen kan och bör användas och hur CI-system kan upprätthålla CI-processen samt en rad olika fördelar mjukvaruutvecklare kan dra nytta av om de tillämpar CI, kommer de 10 bästa CI tillämpningarna enligt Martin Fowler att presenteras nedan: [5]

1. Utvecklingsteamet bör använda sig av en gemensam centralkatalog 2. Automatisera bygget

3. Se till att bygget innehåller automatiska tester 4. Utvecklare uppmanas att ofta checka in till kodbasen

5. Varje incheckning bör trigga en build som ligger på utvecklarens ansvar 6. Se till att bygget är optimerat och kan göras på under 10 minuter 7. Utför tester i en kopia av produktionsmiljön

8. Tillgängliggör exekverbara filer (prototyper/demo) för intressenter 9. Se till att hela utvecklingsteamet har koll på läget

Sida | 13

3. Metod

I detta avsnitt går vi igenom hur vi löste olika delproblem under examensarbetet.

För att kunna introducera ett CI-system vetenskapligt krävs det en hel del kunskap om ämnet. Vi började vår studie med att söka och samla in information kring ämnet på nätet. Då hade vi ingen aning om vad CI-system handlar om. Därefter genomförde vi en problemformulering där vi förklarade och avgränsade vår frågeställning. Strukturen på examensarbetet och indelningen av delproblem fick vi fram under förstudien som innehöll bl.a. litteraturstudier och tekniska lösningar till problemet (se bilaga 5). Då fördjupade vi oss i ämnet genom att läsa flera böcker och vetenskapliga artiklar som handlar om problemområdet.

För att underbygga den slutsats som vi slutligen kom fram till och för att få svar på vår frågeställning utförde vi både en litteraturundersökning (avsnitt 3.1) och en marknadsundersökning (avsnitt 3.3). Svarsdatan från dessa undersökningar kunde vi senare jämföra och korrelatera.

Slutligen, för att kunna verifiera en aspekt av vår slutsats och demonstrera en praktisk artefakt i examensarbetet så ställde vi upp ett CI-system (avsnitt 3.5.2) och övrig infrastruktur för att demonstrera hur CI-system kan användas, men även ett användbarhetstest (avsnitt 3.5.3) för att utöka omfattningen av det praktiska momentet. Under tiden som vi utförde samtliga delar arbetade vi även med kursmaterial (avsnitt 3.5.1) på uppdrag av vår externa handledare.

Processen som vi använde följer stegen som Saunders, Lewis & Thornhill beskriver i [24]. Stegen förklaras tydligare enligt bilden nedan.

Fig. 5: Research process

Sida | 14

3.1 Litteraturundersökning

För att kunna beskriva CI och dess minimala krav i produktutvecklingscykeln krävs det erfarenhet och kunskap om den aktuella byggprocessen och olika CI komponenter. Därför valde vi att avgränsa oss och genomföra en litteraturundersökning (se bilaga 3) på system. Syftet med litteraturundersökningen var att samla information och fakta om CI-system, förstå hur CI-system fungerar och undersöka om det är möjligt att definiera minimumkrav som CI-system måste uppfyllas för att vara tillfredsställande för ett utvecklingsteam.

3.1.1 Utförande av litteraturundersökning

Vi beslutade oss för att presentera och formellt ställa upp litteraturundersökningen i en matris där kopplingar mellan referenser och funktionella samt icke-funktionella krav listas. Populära CI-servrar mjukvaror listades även här (se bilaga 3). För att fastställa vilka funktionella och icke-funktionella krav som vi letar efter i litteraturen tillgick vi mötesprotokoll och anteckningar från diskussioner med våra handledare. Vi sökte även efter en sammanfattning av vanliga icke-funktionella krav för olika typer av system [25-28]. Den litteratur som vi sedan gick igenom med hjälp av ovan nämnda funktionella och icke-funktionella krav bestod av yrkeskunskap i form av webbartiklar och bloggar, böcker utgivna av författare som är verksamma inom mjukvaruutveckling med CI-system och vetenskapliga artiklar som har en högre nivå av relevans för vår studie [2, 5, 7, 9-16, 29-35].

3.2 Undersökningsmetod

Som undersökningsmetod valde vi SES metoden enligt John W. Creswell [36]. Sequential Exploratory Strategy (SES) är en två-fas metod med prioritet på den första fasen. Under den inledande fasen samlar man in och analyserar kvalitativ data. Därefter övergår man till nästa fas och kategoriserar de kvantitativa data, man använder sig alltså av kvantitativ data för att förstå sig på de kvalitativa data. Slutligen integrerar man slutsatser som man fått fram från båda faserna i en “tolkningsfas”. Metoden är enkel att tillämpa och använda sig av i olika formuleringar, dess utformning gör den även lämpad för en tydlig beskrivning av hur man behandlat datan. Metoden är väl lämpad för forskning kring ett fenomen, särskilt om man vill utforska de kvalitativa resultaten från den första fasen [36]. Eftersom vi i vår studie kommer att utforska CI-system och dess minimala krav, där vi är särskilt intresserade av kvalitativ data anser vi att SES-metoden är att föredra.

Sida | 15

3.3 Datainsamling och analys

Under denna studie genomfördes en marknadsundersökning mha en webbaserad enkät, för att på ett effektivt sätt samla in data från en stor grupp människor om vårt ämne. Via enkäten som utfördes kunde vi få fram data som vi ville komma fram till om CI-system och dess minimala krav. En enkätundersökning är ett flexibelt medium som kan mäta attityder, kunskaper, preferenser, osv [37]. När man gör en enkätundersökning så är det viktigt att man formulerar enkätfrågorna noggrant så att man verkligen får den svarsdata som är relevant för studien. Frågorna ska vara tydliga och kortfattade samt de ska inte vara ledande i sin karaktär [38]. Enkäten innehåller 19 frågor av olika typer och tar cirka 5 minuter att fylla på. Den är riktad till företag och utvecklare som använder sig av CI-system inom olika organisationer av olika storlekar i ett flertal länder. Enkätundersökningsfrågorna presenteras i bilaga 2.

Enligt Saunders, Lewis och Thornhill [24] finns det olika tekniker för att samla in och analysera data som man fått ifrån en undersökning. De vanligaste datainsamlingstekniker är kvalitativ och kvantitativ tekniker. Man kan skilja mellan de två teknikerna när man behandlar numeriska eller icke-numeriska uppgifter.

● Kvalitativ datainsamling används för det mesta vid frågor eller dataanalytiska förfaranden där man bara intresserad av att kategorisera data som ger eller använder sig ut av icke-numerisk data så som text, bilder och även videoklipp.

I vår enkätundersökning har vi använt den kvalitativa tekniken för att undersöka och samla in data för funktionella och icke-funktionella krav för CI-system på vissa frågor t.ex. fråga 1, 3, 5-8, 11-19. (se bilaga 2)

● Kvantitativ datainsamling används däremot oftast vid frågor eller dataanalytiska förfaranden där man är intresserad av att visualisera data i grafer och statistik som ger eller använder sig utav numerisk data.

I enkätundersökning har vi också använt den kvantitativa tekniken för att undersöka och samla in data för funktionella och icke-funktionella krav för CI-system på vissa frågor t.ex. fråga 2, 4, 9-10. (se bilaga 2)

För att klargöra de kvalitativa resultaten som vi fick från enkätfrågorna omvandlade vi kvalitativa data till numerisk data och statistik i form av grafer. Vi kombinerade både kvalitativa och kvantitativa tekniker för att kunna presentera resultaten på ett bättre sätt. Därför ska vi enligt Creswell [36] kunna använda mixed methods i denna typ av studie. Mixed methods är metoder som enligt Saunders, M., Lewis, P. och Thornhill, A. [24] kombinerar både kvantitativa och kvalitativa datainsamlingstekniker och analysförfaranden. Detta innebär att man kan ta kvantitativa uppgifter och omvandla dem till vanlig text som kan analyseras kvalitativt. Eller så kan man omvandla sina kvalitativa data till numerisk data, så att dem kan analyseras kvantitativt precis som vi gjorde i fråga 3, 5-8, 11-19 när vi tog utdatan från textfrågorna (kvalitativa data) som vi kom fram till via enkäten och presenterade detta via diagram för att tydligare åskådliggöra resultaten.

Sida | 16

3.3.1 Utförande av marknadsundersökning

För att genomföra en marknadsundersökning valde vi att utföra en webbaserad enkät. [37] Enkäten genomfördes med hjälp av Google Docs Forms (se bilaga 2). Anledningen till vårt val av Google Docs Forms var att det är lätt och använda, gratis, och att det inte finns någon övre gräns för hur många frågor man kan ställa upp på enkäten som SurveyMonkey har. Enkäten utformades enligt strikta riktlinjer [36], vi kunde därför försäkra oss om att vi fick ut användbara svar från marknadsundersökningen till vår studie. Enkäten innehåller 19 frågor av olika typer och tar cirka 5 minuter att fylla i. Den är riktad till företag och utvecklare som använder sig av CI-system inom olika organisationer av olika storlekar.

I början tänkte vi ta kontakt med företag som jobbar med CI-system inom Sverige och skickade då enkäten till flera företag som jobbar med CI-system i hela landet, men de flesta företag som tillfrågades avböjde att delta i vår studie. Därefter vände vi oss till sociala media såsom Facebook, LinkedIn, Twitter och vi kontaktade företagare och utvecklare som sysslar med CI-system. Enkäten innefattade frågor av olika typer [38] bl.a. flersvarsfrågor som kan sägas vara kvantitativa och öppna frågor som kan sägas vara kvalitativa. Meningen med detta var att ge utvecklare möjlighet att uttrycka sig själva i sina egna ord och få en bättre förståelse för hur utvecklare identifierar och definierar minimala krav för CI-system.

I slutändan besvarades enkäten av 39 aktörer av de ca 300 aktörer som tillfrågades att delta, vilket innebär att svarsfrekvensen var ca 13%.

För att samla in och analysera data med hjälp av enkätundersökning använde vi oss ut av kvalitativ datainsamlingsteknik för följande frågor: 1, 3, 5-8, 11-19. För återstående frågor använde vi kvantitativ datainsamlingsteknik [24]. Erhållna data ifrån enkätundersökningen behandlades med hjälp av MS Excel och visualiserades i olika typ av diagram (se avsnitt 4.2), för att lättare kunna visa svaren och enklare kunna dra slutsatser av inlämnade svar.

3.4 Etiska principer

Ett av de stegen i undersökningsprocessen är att diskutera etiska principer. Enligt Staffan Stukát [39] är det viktigt att man tänker på etiska principer när man utför en undersökning. Därför ansåg vi att det var viktigt att ta hänsyn till etiska principer när vi utförde denna studie. De forskningsetiska principer beskrivs av Vetenskapsrådet [40] som följande:

Sida | 17

3.4.1 Informationskravet

“Forskaren skall informera de av forskningen berörda om den aktuella forskningsuppgiftens syfte” [40].

Vi informerade deltagare om studiens syfte och vilka villkor som gäller när de deltar i studien. Vi var specifika när vi angav att syftet för vår studie var att undersöka krav för CI-system (se bilaga 2).

3.4.2 Konfidentialitetskravet

“Uppgifter om alla i en undersökning ingående personer skall ges största möjliga konfidentialitet och personuppgifterna skall förvaras på ett sådant sätt att obehöriga inte kan ta del av dem” [40].

Vi har under studien angett att deras svar förblir sekretessbelagda och att insamling av uppgifter för denna studie hanteras varsamt för att obehöriga ej ska få tillgång till denna data (se bilaga 2).

3.4.3 Nyttjandekravet

“Uppgifter insamlade om enskilda personer får endast användas för forskningsändamål” [40].

I vår studie har vi angett att deltagande i undersökningarna genererar data som endast kommer att användas av för att besvara våra frågeställningar för studien (se bilaga 2).

3.5 Metod för övriga moment

Utöver undersökningsprocessen som vi använde oss av har vi även utfört moment i vår studie som inte innefattas av den. Nedan beskriver vi hur vi utfört kursmaterial, uppbyggnad av CI-systemet och genomförandet av tester.

3.5.1 Utförande av kursmaterial

Båda delar av kursmaterialet (teoretisk och praktisk) som vi fick fram presenteras i bilaga 1. Vi började först med den teoretiska delen av kursmaterialet genom att söka lämpliga källor och samla in information som behövs för att beskriva continuous integration. Informationen som erhölls kom dels från böcker och vetenskapliga artiklar som vi gick igenom när vi skrev

Sida | 18 vår studie och dels från olika webbartiklar på nätet. De flesta källor kunde vi komma fram till via Malmö högskolans databaser (bl.a. ACM Digital library, Google Scholar, IEEE Xplore). Information och anteckningar som vi sammanställde under studien utmynnade till bl.a. kursmaterial i form av 2 omfattande powerpoint-dokument, dessa dokument utgör ett utkast till den kurs som kommer att vidareutvecklas och användas i utbildningssyfte av Edument AB där man både är intresserad av att undervisa i continuous integration men även i hur detta praktiskt kan tillämpas med hjälp av CI-server mjukvaran TeamCity.

För att utföra den praktiska delen av kursmaterialet behövde vi därför först och främst komma igång med TeamCity och förstå hur man använder sig av det, innan vi kunde börja beskriva det och presentera i ett powerpoint-dokument. Mer om hur själva uppbyggnaden av CI-systemet TeamCity skedde kan läsas om i nästa avsnitt. Vi kan därför fokusera på själva processen av att få fram den praktiska delen av kursmaterialet i detta avsnitt. Detta var i själva verket en väldigt enkel process, dock tog det ett bra tag att få alla bitar på plats och få fram powerpoint-dokumentet. Vi tog helt enkelt skärmdumpar under olika delar av interaktionen med TeamCity (allt från installation av TeamCity till att köra byggen och tester) och kategoriserade dessa i moduler. Sammanlagt fick vi fram 14 moduler som beskriver hur man kommer igång med att använda TeamCity. Vissa bilder behövde även modifieras (t.ex. förstoras eller att viktiga element i bilden markeras med röda rektanglar eller pilar) så detta skedde i nästa steg. När vi väl hade skärmdumparna på plats så infogades dessa i powerpoint-dokumentet och en bildtext skrevs till för att beskriva vad som sker på skärmdumparna. Även en beskrivande text för varje modul skrevs för att åhöraren ska få en uppfattning om vad som kommer att presenteras.

3.5.2 Uppbyggnaden av CI-systemet

För att uppfylla krav som ställs på ingenjörer och ingenjörsverksamhet byggde vi upp ett CI-system och kravtestade CI-systemet enligt de krav som fåtts fram av tidigare nämnda undersökningar. Vi använde oss under detta moment av CI-mjukvaran “TeamCity” [8] för att uppfylla vår externa handledares krav. Vi avgränsade oss till uppbyggnad och kravtest av endast ett CI-system pga. omfattningen av examensarbetet.

Vi valde TeamCity eftersom just detta CI-system är av intresse för vår externa handledare. Eftersom vi har interna krav på att utföra ett praktiskt moment och ett externt krav att producera kursmaterial som består av en praktisk del där vi går in på hur man kommer igång med en TeamCity-server var detta ett lämpligt val.

IT-supporten på Malmö högskola försåg oss med en dator som vi kunde använda som CI-system server. Serverns CI-systemspecifikationer beskrivs i bilaga 9.

Sida | 19 Till att börja med installerade vi TeamCity (se bilaga 1 för en utförlig beskrivning om hur man kommer igång med TeamCity). TeamCity lagrar loggar och annat i en databas, därför installerade vi även XAMPP för att kunna köra en MySQL databas. Sedan installerade vi IDE:n Eclipse Luna för att skapa ett enkelt Java-projekt som vi kan bygga och testa i TeamCity, detta projekt är alltså skapat i demonstrationssyfte och har ingen annan praktisk tillämpning. Vi installerade även Apache Ant för att skriva ett byggskript som bygger projektet lokalt, detta skript måste sedan skickas med till TeamCity så att CI-systemet vet hur den ska bygga källkoden i projektet. Sedan skrev vi även enhetstester för projektet i JUnit via Eclipse. När Java-projektet var färdigt (se bilaga 8) så satte vi upp ett VCS (version control system) i Google Code och använde oss då av Subversion (se bilaga 1 för en beskrivning i hur detta skedde). Subversion centralkatalogen kan hittas här:

https://code.google.com/p/ci-research-teamcity-test-project/. Vi använde TortoiseSVN som ett grafiskt gränssnitt för att checka in nya revisioner av kodbasen till Subversion centralkatalogen. Vid detta laget hade vi alla bitarna på plats och då var det bara att få TeamCity att hämta den senaste revisionen av kodbasen som vi lagt upp på Google Code Subversion och kompilera koden samt köra enhetstester (även detta beskrivs mer utförligt i bilaga 1).

3.5.3 Utförandet av användbarhetstest och behandling av svarsdata

Av både litteraturundersökningen och marknadsundersökningen framgår det att det icke-funktionella kravet användbarhet är ett av de viktigaste kraven som måste uppfyllas i ett CI-system. Efter diskussioner med vår interna handledare kom vi därför fram till att det vore intressant att ta reda på om TeamCity uppfyller krav gällande användbarhet. Dessutom är detta ett sätt för oss att validera de slutsatser som vi har kommit fram till genom undersökningarna.

Vi började med att diskutera vilken målgrupp vi ska rikta oss mot. Likt marknads- undersökningen var vi mest intresserade att titta på huruvida yrkesverksamma individer som haft erfarenhet av CI-system anser att TeamCity är användbart eller ej. När vi fastställt målgruppen så utformade vi textmallar där vi informerar inbjudna individer och företag om hur de kan anmäla sitt intresse och vi skickade ut dessa inbjudningar främst via LinkedIn där vi bjöd in mer än 400 individer och företag. Eftersom användbarhetstestet ej kan utföras obevakat, till skillnad från t.ex. enkäten för marknadsundersökningen, och eftersom den dessutom tar mellan 30-50 minuter att utföra krävdes en del arbete med bokföring och schemaläggning av intresserade testkandidater. Vi erbjöd även de intresserade att anmäla sitt intresse både via mail och via Doodle.com, vår schemaläggningssida kan hittas här:

http://doodle.com/mupeaxexh6ccug43.

I olika sammanhang kan man använda sig av ett godtyckligt antal testare för att fastställa om krav för ett system är uppfyllt eller ej. För vårt användbarhetstest bestämde vi oss för att

Sida | 20 ha 5 testsessioner med deltagare som har tidigare erfarenhet av CI-system men ej använt TeamCity. Vi ville även ha 1-5 deltagare som tidigare använt TeamCity, dessa deltagare kan då placeras i en kontrollgrupp där vi kan jämföra resultat mellan testgruppen och kontrollgruppen. Dessutom kan kontrollgruppens resultat användas som måttstock när vi fastställer kriterier och gränsvärden för svarsdatan och bestämmer om dessa påvisar att CI-systemet är användbart eller ej.

Efter att ha genomgått testsessioner och inbjudningar under 2 veckors tid hade vi svarsdata från 5 deltagare i testgruppen (som ej använt TeamCity tidigare) och 1 deltagare i kontrollgruppen. Vi hoppades få in lite fler deltagare i kontrollgruppen men just pga. omfattningen och tiden som individer måste lägga ner för att genomföra detta test (30-50 min plus bokning och mail-korrespondens) men även faktumet att vi utförde testerna utan en budget (diskuteras närmare i avsnitt 6.2 “förbättringar”) innebar att vi inom denna tidsram inte fick in fler testsession. Trots detta anser vi att momentet är lyckat då vi i första hand ville få in 5 deltagare i testgruppen, vilket vi lyckades med.

För att ställa upp en miljö där vi kan utföra användbarhetstest fanns det en del saker att tänka på. För det första bestämde vi oss för att utomstående klienter (deltagaren) skulle koppla upp sig mot vår CI-server som körs på Malmö Högskola. När klienten väl var uppkopplad så försågs hon med användarenkäten och interfacet till TeamCity som båda körs via webbläsaren. Inloggning till TeamCity, förberedelse inför testsession och tillgång till användarenkäten sköttes alltså av oss innan klienten/testaren anslöt sig. Vi använde oss av TeamViewer för att förse en uppkopplingslänk mellan CI-system servern och testaren. Det fanns flera skäl till att vi valde just TeamViewer istället för t.ex. VNC eller andra verktyg. För det första så ville vi ha en säker uppkoppling där vi som värd snabbt kan koppla ifrån eller begränsa interaktion och tillgång till CI-system servern om det under testets gång visar sig att testaren interagerar med servern utanför testets ramar. Då kan testaren snabbt kopplas från och nekas en ny uppkoppling. Sedan har TeamViewer stöd för att spela in testsessioner vilket var önskvärt. Detta innebär att vi inte måste belasta servern med ytterligare program som körs under testsessionen. Mer diskussion kring TeamViewer och dess fördelar och nackdelar i avsnitt 6.2 “förbättringar”.

Det sista delmomentet i utförandet av användbarhetstesterna var efterbehandlingen av svarsdatan från testsessionerna. Som tidigare nämnt så fylldes en del svarsdata in i testformuläret via användarenkäten och en del efter kontroll av inspelade test sessioner. Arbetsflödet för behandling och beräkning av “task time” förbättrades under delmomentets gång där vi till en början utförde aritmetiska beräkningar manuellt men sedan tillämpade automatiska och mer precisa beräkningar via spreadsheet-mjukvara så som MS Excel, OpenOffice Spreadsheet och Google Docs Spreadsheet. Vi använde oss av bl.a.

http://www.grun1.com/utils/timeDiff.cfm för att dubbelkolla beräkningar och kunde på så sätt snabbt hitta fel som uppstod pga. manuella beräkningar i det tidiga skedet. Den behandlade svarsdatan redogörs grafiskt i form av diagram i avsnitt 4.4.6.

Sida | 21

4. Resultat och analys

I detta avsnitt redogör vi resultat som vi fått fram genom våra undersökningar samt analyserar resultatdatan. Vi definierar även olika begrepp och förklarar koncept som vi lärt oss om i samband med detta arbete som är specifikt för vårt sätt att betrakta CI-system utifrån krav.

Vi redogör både funktionella och icke-funktionella krav för CI-system i avsnitt 4.1 samt redogör för hur man ställer upp krav för system och hur man sen kan kravtesta och utvärdera system utifrån uppställda krav. I avsnitt 4.2 redovisar vi resultat från marknadsundersökningen som vi utförde och i avsnitt 4.3 redovisar vi resultat från litteraturundersökningen. I avsnitt 4.4 förklarar vi hur man utför användbarhetstestning enligt vedertagna tekniker samt hur vi själva tillämpat den föreslagna tekniken för vårt eget syfte. Slutligen redogör vi resultatet från vår användbarhetstestning.

4.1 Krav för ett CI-system

Systemkrav är de krav som ställs på mjukvaran och anger vilka avvägningar man gör t.ex. mellan olika icke-funktionella krav som oftast är ömsesidigt uteslutande, exempelvis kan en applikation skrivas på ett tydligare sätt för att senare kunna underhållas till förlust av prestanda och resurseffektivitet. I systemkrav anges även vilka funktionella krav som ligger i fokus, dvs. vad applikationen ska kunna utföra för tjänst i huvudsak. Kraven som ställs på mjukvara kan kategoriseras enligt funktionella och icke-funktionella krav [17].

4.1.1 Funktionella krav

Funktionella krav för ett CI-system beskriver vad systemet ska göra. Här kommer några exempel på funktionella krav för ett CI-system [5, 7, 30, 32, 41]:

● Kodhantering (eng. code management): Hantering av ändringarna i källkod och möjliggörandet av att återvända till äldre versionen och tillstånd av applikationen vid behov.

● Kompilering/bygge av källkod (eng. compiling/building source code): Kompilering av källkod via CI-systemet.

● Testning: Olika typer av tester ska kunna utföras via CI-systemet. Det finns olika sätt att kvalitetssäkra källkod, bl.a. via statisk analys, enhetstest, stresstest och integrationstest samt systemtest.

● Återkoppling (eng. feedback/notification): Utvecklare som checkat in kod måste på något sätt bli underrättade om CI-systemet upptäcker fel i den incheckade koden. Detta kan ske via exempelvis email, dashboard/WUI (eng. web-based user interface,

dvs. webbaserat användargränssnitt), SMS eller IM (eng. instant messaging).

Vissa projektgrupper använder sig av andra sätt att notifiera gruppmedlemmar om att kodbasen är i ett brutet tillstånd, därför är det bra om CI-systemet tillåter administratören att konfigurera återkopplingen till en hög grad.

● Distribution (eng. deployment): Källkod som kompilerats och testats kommer vid en viss tidpunkt under projektets gång att behöva distribueras till slutanvändare och övriga intressenter (eng. stakeholder). Detta kan automatiseras via CI-system som skapar jar-filer, tar-filer eller paketerar körbar mjukvara i en så kallad “installer”, dessa utdelningsbara (eng. distributable) filer kan sedan delas ut till intressenter.

Sida | 22 ● Administration: Hantering av användare och användargrupper med en lista över

privilegier som kan tilldelas till dessa.

● Byggserverhantering (eng. build agent management): Hantering av byggservrar som utför centrala funktionaliteter för CI-system. En byggserver är en enhet som utför själva arbetet som ett CI-system delegerar till enheten, t.ex. kompilering av källkod och testning av kod. Byggservrar kan hanteras och ställas in med olika prioriteringsnivåer för byggen och utlösare (eng. triggers).

● Resurshantering (eng. resource management): Kontroll över diskanvändning, komprimering, lagring, säkerhetskopiering av data och övervakning av resursanvändning och tillståndet av CI-systemet.

4.1.2 Icke-Funktionella krav

Icke-funktionella krav för ett CI-system beskriver hur systemet ska utföra funktioner. Här kommer några exempel på icke-funktionella krav för ett CI-system [17, 25-28, 42]:

● Prestanda (eng. performance): Prestanda är ett mått på hur snabbt ett CI-system agerar när det utför ett visst arbete. Exempel på olika typer av arbeten är uppstart av CI-systemet eller större moduler, återhämtning från fel, kommunikation med utomstående komponenter, bearbetning av anrop (eng. queries), stabil användning av GUI:t och byggning av källkod för projekt.

● Användbarhet (eng. usability): Användbarhet för ett CI-system avser huruvida god eller dålig interaktionen mellan användare och systemet är, alltså hur lätt det är att använda sig av systemet som användare. Ett användbart CI-system är ett system som stödjer användarens inlärningsprocess och gör det lätt för användaren att vänja sig vid gränssnittet och använda den på ett effektivt sätt, t.ex. kan detta göras genom att följa en standard för var vissa knappar ska ligga och användas, användaren kan då intuitivt lära sig använda CI-systemet eftersom GUI:t liknar många andra system. Ett användbart system ökar också feltolerans (dvs. det är svårt att begå kritiska fel som påverkar större delar av systemet och inte går att ångra).

● Utbyggbarhet (eng. extensibility): Ett CI-system ska vara lätt att utvidga och modifiera. Utvecklare av CI-system måste därför se till att tillgodose ett gränssnitt eller API för tredjepartsutvecklare så att CI-systemet kan modifieras men så att denna modifikation ej påverkar CI-systemets robusthet på ett negativt sätt.

● Tillförlitlighet (eng. reliability): Ett tillförlitligt CI-system har förmågan att kontinuerligt utföra funktioner, uppgifter och vara tillgänglig för att utföra diverse tjänster på begäran av klienter eller användare. Detta ska kunna ske under en längre tid utan avsevärda försämringar eller fel som uppstår pga. att systemet hålls i drift. Dessutom ska systemet vara funktionellt även om delsystem eller beroende komponenter (eng. dependencies) fallerar.

● Stabilitet (eng. stability): Med stabilitet menar man CI-systemets förmåga att vara robust under en längre tid av användning men även att modifiering av systemets periferi- och kärnkomponenter inte ska påverka systemets prestanda.

● Tillgänglighet (eng. availability): Ett CI-system som är tillgängligt är ett system som kan interagera med klienter eller användare under en längre tid och har en låg stilleståndstid (eng. downtime). Ett CI-system med hög drifttid (eng. uptime) är tillgängligt och möjliggör användare att få tillgång till information eller resurser på