1. No category

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
Data- och telekommunikationsteknik
19 januari 2015
Examinator:
Handledare:
Gion Svedberg
Mia Persson
Tore Nestenius
This page intentionally left blank.
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 IEEEreferensstil och hänvisningar till litteratur för att få en bättre förståelse för den
vetenskapliga metoden.
iii
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, ickefunktionella krav
iv
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 “nonfunctional 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, nonfunctional requirements, quality attributes
v
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
3.5.3 Utförandet av användbarhetstest och behandling av svarsdata ........................ 20
vi
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
vii
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
CI-system. Avsnitt 4.1.1 och 4.1.2 handlar om funktionella och icke-funktionella krav för CIsystem. Hur de ställs upp, valideras och testas förklaras i avsnitt 4.1.3 och 4.1.4.
Sida | 1
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 | 2
“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 | 3
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 litteraturundersö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 mjukvaruutvecklingsverktyg 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 | 4
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 CIprocesser 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 CI-system i .NET samt ger en beskrivning av olika CIservrar. 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 | 5
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]
Fig. 2: Agila metoder [20]
Sida | 6
● 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 | 7
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 | 8
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. XMLformat) 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
Fig. 4: arbetsflöde för CI-system[23]
Sida | 9
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 CIsystem:
● 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, CISida | 10
●
●
●
●
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 CI-system och vilka svårigheter som kan uppstå när man försöker använda sig av CIsystem 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 | 11
● 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 CIsystem) 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
10. Automatisera paketering och distribution av mjukvara
Sida | 12
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
I följande avsnitt förklarar vi hur vi har utfört de olika stegen.
Sida | 13
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å CIsystem. Syftet med litteraturundersökningen var att samla information och fakta om CIsystem, 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 ickefunktionella 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 | 14
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 | 15
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 | 16
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 CIsystem (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 | 17
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 CIsystem och kravtestade 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 CIsystem server. Serverns systemspecifikationer beskrivs i bilaga 9.
Sida | 18
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 ickefunktionella kravet användbarhet är ett av de viktigaste kraven som måste uppfyllas i ett CIsystem. 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 marknadsundersö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 | 19
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 CIsystemet ä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 | 20
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 | 21
● 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å
Sida | 22
begäran. Med tillgänglighet menas även om ett CI-system endast kan nås från en viss
plats (inom ett visst nätverk) eller om det kan nås via internet.
● Skalbarhet (eng. scalability): Skalbarhet är en egenskap hos ett CI-system som
beskriver dess förmåga att hantera och prestera under en ökad eller växande
arbetsbörda. Exempelvis kan skalbarhet syfta på förmågan hos ett CI-system att öka
sin prestanda och bearbeta en viss arbetsbörda snabbare när man utökar resurserna
som CI-systemet har att tillvarata. Detta kan antingen göras genom att byta ut gamla
eller slitna komponenter mot nya för en centraliserad server (t.ex. lägga till RAMminne eller installera ett bättre CPU), eller att använda sig av decentraliserad
bearbetning av arbetsbördan, dvs. en fördelning av arbetsbördan (eng. load
balancing).
● Återhämtning (eng. recoverability): Ett CI-system med en fungerande
återhämtningsförmåga kan återställas till ett fungerande tillstånd om ett kritiskt fel
skulle inträffa. Systemet måste ha en förmåga att säkerhetskopiera och utföra vissa
uppgifter på ett tillförlitligt sätt och utan att orsaka kostnadsförluster.
● Effektivitet (eng. efficiency): Ett effektivt CI-system använder resurser på ett effektivt
sätt, dvs. en överanvändning av resurser sker inte relativt med den arbetsbördan
som tilldelats till systemet. Systemet har en förmåga att bl.a. tilldela minne till olika
processer, fördela processorkraft mellan olika processer och att förbruka ström på
ett effektivt sätt.
4.1.3 Hur ställer man upp krav för system?
Under kravhanteringsprocess “eng. requirements engineering process“ kan olika tekniker
användas för att hjälpa utvecklare att ställa upp krav för ett system. Några av de tekniker
beskrivs av [17, s. 100-107] som följande:
1. Krav upptäckt (eng. requirements discovery): är en process för att samla in
information om ett befintligt system, för att sedan kunna avgöra vilken målgrupp av
användare som kommer att använda systemet och vilka krav som ställs på systemet
enligt denna information.
2. Intervjuer (eng. interviewing): där utvecklare ställer frågor till systemanvändare kring
deras system som kommer utvecklas.
3. Scenario (eng. scenarios): är en berättelse som beskriver på vilket sätt systemet
kommer användas.
4. Användningsfall (eng. use cases): där systemet beskrivs med hjälp av flera grafiska
modeller som UML-sekvens eller statiska diagram. Med andra ord, identifieras alla
aktörer som kommer att interagera med systemet och deras roll i interaktionen
beskrivs grafiskt.
I vår studie har vi följt en undersökningsprocess (avsnitt 3), vi utförde en enkätundersökning
(se avsnitt 3.1) där vi ställde några frågor kring CI-system till utvecklare och företagare som
använder sig av CI-system för att samla in information kring krav för CI-system och vi skrev
ett användbarhetsscenario (se avsnitt 4.4.4). Vi har således använt oss av “requirement
discovery”, “interviewing” och “scenarios” teknikerna.
Sida | 23
4.1.4 Kravtest och utvärdering
Det finns ett antal kravvalideringstekniker som kan användas för sig eller i kombination med
varandra [17, s. 110], några av dessa beskrivs nedan:
1. Kravrecensioner (eng. requirements reviews).
2. Test-case generation.
3. Prototyping: Här demonstreras en körbar modell av systemet till slutanvändare
(utvecklare, kunder) så att de kan experimentera med modellen för att se om den
uppfyller deras verkliga krav samt identifiera eventuella problem och planera möjliga
lösningar.
Enligt E. Folmer, J. Gurp och J. Bosch har användbarhet (eng. usability) blivit en viktig faktor
vid utveckling av programvara och har även visat sig vara avgörande för framgången av
programvarusystem. Många mjukvaruprojekt har påvisat att programvara som har
användbarhetsproblem inte kan anpassas utan större förändringar i programvarukonstruktionen. Att lösa användbarhetsproblem under senare faser av utvecklingsprocessen
kostar tid, pengar och förhindrar utvecklare från att uppfylla alla användbarhetskraven
vilket resulterar i system med mindre än optimal användbarhet. [43]
Vår marknadsundersökning har påvisat att det icke-funktionella kravet användbarhet är ett
av de viktigaste kraven som måste uppfyllas i ett CI-system och vi har därför valt att
utvärdera CI-systemet TeamCity med avseende på användbarhet.
Tekniken som vi har valt för att validera kravet användbarhet är “prototyping” med hjälp
avanvändbarhetsscenario som beskrivs i avsnitt 4.4.4.
Vi har valt prototyping-tekniken för att den ger användare en möjligt att testa hur väl
systemet stödjer deras arbete enligt krav som ställs på systemet. Tekniken hjälper även
användaren att få fram nya idéer samt ser till så att man hittar starka och svaga sidor i
systemet. Detta kan sedan leda till fastställandet av nya systemkrav. En funktion beskrivs
ibland i en systemspecifikation som verkar vara användbar och väl definierad. Men när
denna funktion kombineras med andra funktioner, så upptäcker användare ofta att deras
ursprungliga uppfattning var felaktig eller ofullständig. [17]
4.2 Resultat från marknadsundersökningen
Vår marknadsundersökning bestod av en enkät som innehåller 19 frågor varav 15
flersvarsfrågor och 4 fritextfrågor. Syftet med flersvarfrågorna var delvis att få kvantitativ
svarsdata för en enklare behandling och delvis för att underlätta för deltagaren att svara på
frågorna. Syftet med fritextfrågorna var att få rikare information och en bättre förståelse för
hur utvecklarna identifierar och definierar minimala krav för CI-system dvs. kvalitativ
svarsdata. Frågorna skickades via social medier som bl.a. LinkedIn, Twitter och Facebook,
och var riktade till företagare och utvecklare som använder sig av CI-system. Resultat som vi
fick utav marknadsundersökningen presenteras grafiskt och analyseras nedan.
Sida | 24
Analys av fråga 1
Enligt Goodman, Elbaz och [1, 2, 4-6] kom CI-system först till användning inom mjukvaruutveckling men har sen dess även använts i andra typer av verksamheter. För att ta reda på
vilka verksamheter som använder sig av CI-system så ställde vi denna fråga. Svarsdatan
pekar på att 74% av svarsobjekten anger att de använder sig av CI-system inom en Data/IT
verksamhet, 13% Teknologi/Vetenskap, 5% Logistics/Transport och 3% Ekonomi/Finans
samt 5% har andra verksamheter. Enligt svarsdatan så används CI-system mest inom Data/IT
branschen.
Fig. 6: “Type of business”
Analys av fråga 2
För att veta hur stor verksamheten är som mest använder sig av CI-system så ställdes denna
fråga. Av svaren som vi fick från svarobjekten i enkätundersökningen så kunde vi enligt EUkommissionens [44] definition benämna 21% som små företag där de har mindre än 50
anställda, 29% som medelstora företag som har 50-250 anställda och 50% som stora företag
med fler än 250 anställda. Enligt svarsdatan är det huvudsakligen stora företag som
använder sig av CI-system.
Fig. 7: “Size of the company”
Sida | 25
Analys av fråga 3
För att få fram meningsfull svarsdata så försökte vi nå ut till ett stort antal företagare och
utvecklare (ca 300) inom teknikbranschen som faktiskt använder sig av CI-system. För att
säkerställa att enkäten besvaras av svarsobjekt som sysslar med CI-system ställde vi denna
fråga. Svarsdatan påvisar att 97% av de som deltog i undersökningen använder CI-system
Fig. 8: “Companies that utilize CI-systems”
Analys av fråga 4
Vi ville undersöka hur stor andel av utvecklare i en verksamhet som använder sig av CIsystem. På så sätt kan vi få en uppfattning om CI-system påverkar hela eller endast några
delar av arbetsprocessen i verksamheten. Vi har valt en 10% inkrementell ökningsskala
vilket innebär att t.ex. svarsalternativ 1 = 10%, 5 = 50%, 10 = 100%. Svarsdatan visar att 41%
av svarobjekten har svarat att 100% av andel utvecklare använder sig av CI-system i deras
verksamhet. Enligt svarsdatan så påverkar CI-system hela arbetsprocessen hos de flesta
verksamheter.
Fig. 9: “Percentage of developers that use or are affected by the CI-system”
Sida | 26
Analys av fråga 5
Här undersöker vi vilken CI-systemmjukvara som används mest i näringslivet för att senare
kunna använda oss av denna data i vår studie. Av de 39 svar som vi mottagit var det 41%
som använder Jenkins, 32% använder TeamCity, 5% använder Cruise Control, 5% använder
Bamboo, 5% använder Continua CI - FinalBuilder och resten 16% använder andra CIsystemmjukvaror som inte finns med på listan. Alltså enligt svarsdatan så är det Jenkins som
är mest känd CI-system ute på marknaden.
Fig. 10: “CI-system software that is used in the company”
Analys av fråga 6
För att kunna kategorisera främsta fördelarna av CI-system och förstå vad utvecklarna gillar
och föredrar i deras system ställdes den frågan. Alltså tyckte de flesta enligt svarsdatan att
deras CI-system var lätt att använda.
Fig. 11: “Main advantages with your CI-system”
Sida | 27
Analys av fråga 7
Här frågade vi deltagarna att välja vad de ogillar i deras CI-system för att kunna kategorisera
främsta nackdelarna av CI-system. De flesta anser att deras CI-system inte har några
nackdelar.
Fig. 12: “Main disadvantages with your CI-system”
Analys av fråga 8
Av denna fråga försökte vi ta reda på hur ofta ett CI-system används hos olika verksamheter.
Svarsdatan påvisar att CI-system används kontinuerligt hos de flesta verksamheterna.
Fig. 13: “Frequency of performing builds”
Sida | 28
Analys av fråga 9
För att kunna veta hur lång tid CI-system brukar ta i olika verksamheter för att genomföra
ett bygge ställdes denna fråga. Svarsdatan visar att det tar olika tid för olika CI-system i olika
verksamheter att genomföra ett bygge på grund av olika faktorer som påverkar CI-system
prestanda så som snabb mjukvara och gammal hårdvara … osv. Tiden anges i HH:MM:SS
format. Men de flesta som deltog i undersökningen angav att deras CI-system i snitt tar en
timme för att genomföra ett bygge.
Fig. 14: “Time for your CI-system to build a project”
Analys av fråga 10
För att ta reda på om CI-system leder till bättre prestanda och produktionsvärde i en
verksamhet [4-6] ställdes denna fråga. Svarsdatan visar att 97% av svarobjekten tycker att
verksamhetens prestanda och produktionsvärde har ökat med hjälp av CI-system.
Fig. 15: “Company’s performance after using CI-system”
Sida | 29
Analys av fråga 11
För att ta reda på vilka huvudsakliga funktionella krav som ett CI-system brukar ha hos de
flesta verksamheter ställde vi denna fråga. Frågan besvarades i fritext och vi fick därför ut rik
kvalitativ information som behövdes tolkas. Efter tolkning grupperades och kvantifierades
svaren. Diagrammet visar att de flesta svarsobjekt har angett:
● compile/build source code
● test
● feedback
● package/deployment
Dessa krav kan sägas vara de huvudsakliga funktionella krav som ett CI-system ska uppfylla.
Fig. 16: “The basic functional requirements of a CI-system (qualitative sample)”
Sida | 30
Analys av fråga 12
För att bekräfta fritextsvaret från fråga 11 gav vi svarsobjekt en möjlighet att besvara
samma typ av fråga med hjälp av flersvar. Vi tänkte att bästa sätt att få svar på denna fråga
var att låta svarsobjekten göra det åt oss genom att ange de funktionella krav de har för
deras CI-system. Svarsdatan visar att de flesta som deltog i undersökningen valde:
● compiling/building source code
● test (unit test, static analysis)
● feedback
Dessa kan påstås utgöra de minimala funktionella kraven för CI-system i enligt vår
marknadsundersökning.
Fig. 17: “The basic functional requirements of your CI-system (quantitative sample)”
Sida | 31
Analys av fråga 13
Vi ville inte bara veta vilka funktionella krav som svarsobjekten hade på CI-system utan även
vilka av dessa krav som de ansåg var viktigast, därför ställde vi denna fråga. Ur diagrammet
kan vi avläsa att de flesta ansåg att “compile/build source code” var det viktigaste kravet
som måste uppfyllas, med bred marginal. Men även följande krav ansågs viktiga att uppfylla:
● VCS/SCM management
● testing
● provide feedback to developer
Fig. 18: “Most important functional requirements for this CI-system”
Sida | 32
Analys av fråga 14
Samtliga svarsobjekt anser att deras CI-system uppfyller minimala funktionella krav
(compiling/building source code, test, feedback).
Fig. 19: “Does your CI-system meet the minimum functional requirements?”
Analys av fråga 15
För att ta reda på vilka huvudsakliga icke-funktionella krav som ett CI-system brukar ha hos
de flesta verksamheter ställde vi denna fråga. Frågan besvarades i fritext och vi fick därför ut
rik kvalitativ information som behövdes tolkas. Efter tolkning grupperades och
kvantifierades svaren. Diagrammet visar att de flesta svarsobjekt har angett performance
usability och reliability. Dessa krav kan sägas vara de huvudsakliga icke-funktionella krav
som ett CI-system ska uppfylla.
Fig. 20: “The basic non-functional requirements of your CI-system (qualitative sample)”
Sida | 33
Analys av fråga 16
För att bekräfta fritextsvaret från fråga 15 gav vi svarsobjekt en möjlighet att besvara
samma typ av fråga med hjälp av flersvar. Vi tänkte att bästa sätt att få svar på denna fråga
var att låta svarsobjekten göra det åt oss genom att ange de funktionella krav de har för
deras CI-system.
Svarsdatan visar att de flesta som deltog i undersökningen valde:
● extensibility
● stability & reliability
● maintainability
● usability
Dessa kan påstås utgöra de minimala icke-funktionella kraven för CI-system i enligt vår
marknadsundersökning.
Fig. 21: “The basic non-functional requirements of this CI-system (quantitative sample)”
Sida | 34
Analys av fråga 17
Vi ville inte bara veta vilka icke-funktionella krav som svarsobjekten hade på CI-system utan
även vilka av dessa krav som de ansåg var viktigast, därför ställde vi denna fråga. Ur
diagrammet kan vi avläsa att de flesta ansåg att “usability” var det viktigaste kravet som
måste uppfyllas följt av “maintainability”. Även följande icke-funktionella krav anses vara
viktiga:
● stability & reliability
● extensibility
● performance
Fig. 22: “Most important non-functional requirements for your CI-system”
Sida | 35
Analys av fråga 18
De flesta som deltog i undersökningen tycker att deras CI-system uppfyller minimala ickefunktionella krav (extensibility, stability, reliability, maintainability).
Fig. 23: “Does your CI-system meet the minimum non-functional requirements?”
Analys av fråga 19
Den sista frågan var för att veta om de som deltog i undersökningen är intresserade för att
ta reda på slutresultatet. Svarsdatan visar att de flesta tackade ja.
Fig. 24: “Respondent’s desire to be notified of the final results”
Sida | 36
4.3 Resultat från litteraturundersökning
Litteraturundersökningen var en formell sammanställning och uppräkning av hur ofta vissa
nyckelord förekommer i litteratur kring CI-system. Vi kategoriserade då nyckelord i
funktionella krav, icke-funktionella krav och som ett tillägg avläste vi även omnämnandet av
olika CI-server mjukvaror som vi sedan kan jämföra med de mjukvaror som nämndes i
marknadsundersökningen. De flesta huvudfrågor och delfrågor från vår frågeställning
besvaras av resultat från både litteratur- och marknadsundersökningen, det är därför viktigt
att vi ställer liknande frågor och tittar efter liknande signaler från båda undersökningarna.
Vi hänvisar läsaren till avsnitt 3.1.1 för mer information kring utförandet av litteraturundersökningen. Se bilaga 3 för rådatan och uppställningen av litteraturundersökningen.
I litteraturundersökningen har vi formellt avläst 10 webbartiklar, 2 böcker och 7
vetenskapliga artiklar [2, 5, 7, 9-16, 29-35] och spårat kopplingar mellan funktionella- och
icke-funktionella krav. De flesta krav listade vi enligt [25-28], dock fanns det krav som kom
till vår kännedom när vi läste igenom källorna, även dessa lades till i matrisen.
Nedan redogör vi resultat för undersökningen som åskådliggörs grafiskt i diagram. Vi
analyserar även resultaten och kan ibland tolka resultaten.
Sida | 37
Funktionella krav som omnämns i litteraturen
Vi undersökte vilka funktionella krav som nämns i litteraturen och fick fram nedanstående
resultat. Det visar sig att följande funktionella krav omnämns mest:
● Källkodshantering (eng. source code management)
● Kompilering av källkod (eng. build source code)
● Körning av tester (eng. run tests)
● Notifiering [av status för bygge] (eng. feedback & notifications)
Vi kan även se att andra funktionella krav är betydande men nämns inte lika ofta:
● Möjliggörandet av byggautomatisering (eng. enable automation)
● Förse infrastruktur som möjliggör upprepbara byggen (eng. provide infrastructure for
repeatable builds)
● Distribution [av mjukvara] (eng. deployment)
Ovanstående funktionella krav nämns ofta som betydelsefulla funktioner för CI-system i
litteraturen.
Fig. 25: “Functional requirements”
Sida | 38
Icke-funktionella krav som omnämns i litteraturen
Vi undersökte även vilka icke-funktionella krav som nämns i litteraturen.
Följande icke-funktionella krav omnämns mest:
● Prestanda (eng. performance)
● Användbarhet (eng. usability)
● Flyttbarhet (eng. portability)
● Interoperabilitet (eng. interoperability)
Vi kan på diagrammet se rätt stora gap mellan de icke-funktionella krav som nämns mest
och de som nämns mer sällan. En till sak som är viktig att påpeka är att icke-funktionella
krav ofta inte nämns explicit utan genom “förväntningar”, t.ex. att ett CI-system ska bygga
källkod snabbt vilket tyder på ett prestandakrav. En indelning av dessa “förväntningar” är i
vissa fall överlappande eller tvetydig. Hur vi gjort kan närmare granskas i matrisen för
litteraturundersökningen (se bilaga 3).
Fig. 26: “Non-functional requirements”
Sida | 39
CI-server mjukvara som omnämns i litteraturen
Slutligen undersökte vi även vilken CI-server mjukvara som nämns i litteraturen och hur ofta
mjukvaran omnämns. Vi kan på nedanstående diagram se att följande CI-server mjukvaror
nämns mest i litteraturen:
● CruiseControl och dess varianter
● Jenkins
● Hudson
● Bamboo
● TeamCity
● Buildbot
Kanske är det inte så förvånande att CruiseControl är mest omnämnt i litteraturen om tar
hänsyn till att den första versionen av CruiseControl släpptes under början av 2001. Dock
kan man undra varför AnthillPro som även det släpptes 2001 inte är mer omnämnt i
litteraturen. Här kan det handla om allt från en diskrepans i marknadsföring mellan de två
mjukvarorna till att utvecklare har lättare att ta till sig CruiseControl, denna diskussion är
dock utanför ramarna för vår studie. Något annat som är av intresse med denna data är att
TeamCity inte nämns lika ofta som t.ex. Jenkins, Hudson eller till och med Bamboo i
litteraturen. Detta trots att TeamCity, enligt vår marknadsundersökning, anses användas av
ca 32% av tillfrågade utvecklare, där 42% uppges använda Jenkins men endast 5% uppges
använda Bamboo.
Fig. 27: “CI-server software”
Sida | 40
4.4 Användbarhetstestning
Vi gick tidigare igenom ett antal icke-funktionella krav, däribland det icke-funktionella kravet
användbarhet (eng. usability). Under senare delar av examensarbetet ställde vi upp ett
användbarhetstest och mätte användbarheten för TeamCity, men innan resultatet för dessa
mätningar och slutsats kan dras måste vi gå igenom vad som menas med användbarhet och
hur ett användbarhetstest ställs upp.
4.4.1 Kategorisering av användbarhet via användbarhetsattribut
Användbarhet har enligt Folmer, Gulp och Bosch att göra med hur enkelt det är för
slutanvändaren att utföra en viss uppgift med hjälp av systemet och på vilket sätt systemet
stödjer denna process. I vår studie vill vi ta reda på hur lätt det är för slutanvändaren att
utföra en rad olika nyckelfunktioner som stöds av de flesta CI-system (enligt litteraturundersökning och marknadsundersökning).
Det finns olika sätt att kategorisera användbarhet. Nedan följer Folmer, Gulp och Bosch
kategoriseringen med hjälp av användbarhetsattribut [43, 45]:
● Lärbarhet (eng. learnability) - Hur snabbt kan en användare komma igång med att
använda ett system som hon inte har använt tidigare, samt hur lätt det är för
användaren att minnas hur man använder sig av systemet
● Effektiv användning (eng. efficiency of use) - Antalet uppgifter användaren kan utföra
under en viss tid med hjälp av systemet
● Tillförlitlighet (eng. reliability) - Andelen fel som uppstår när man använder sig av
systemet och hur lång tid det tar att återhämta sig från fel
● Tillfredsställelse (eng. satisfaction) - Användarens subjektiva åsikt kring användandet
av systemet
Vi kommer dock att kategorisera användbarhet enligt Bass kategorisering av huvudområden
för scenarion [46] som beskrivs nedan, men använder oss även av vissa ovanstående
användbarhetsattribut för att få ett helhetsperspektiv utifrån testarens synpunkt (detta
redogörs i avsnitt 4.4.6).
4.4.2 Kategorisering av användbarhet via huvudområden
Bass [46] använder sig av ett annat sätt att kategorisera och strukturera användbarhet så att
det kan testas. Vi använde oss främst av detta sätt att kategorisera användbarhet när vi
ställde upp användbarhetstestet.
Huvudområden som betecknar användbarhet [46]:
● Inlärning av systemets funktioner (eng. Learning system features) - På vilket sätt
hjälper systemet användaren att bli bekant med systemets olika funktioner och hur
man
använder
sig
av
dessa?
Har CI-systemet ett tydligt (grafiskt) gränssnitt som gör det lätt för framförallt nya
användare att snabbt lära sig använda systemet.
● Effektiv användning av systemet (eng. Using a system efficiently) - Hur kan systemet
hjälpa användaren att utföra uppgifter på ett mer effektivt sätt.
Sida | 41
Här kommer vi att titta på om CI-systemet har effektiva sätt att automatisera och
skapa genvägar för processer som ofta används och därför bör vara ytterst
effektiviserade.
● Minimera inverkan av fel (eng. Minimizing the impact of errors) - Vad kan systemet
göra för att avvärja användarfel. Vad händer om användaren råkar ta bort eller
modifiera
kritiska
komponenter
av
utvecklingsinfrastrukturen?
Har systemet dialogrutor eller säkringar som kan motverka kritiska fel?
● Anpassning av systemet för användarens behov (eng. Adapting the system to user
needs) - Hur kan systemet anpassas för att bli mer användbart för användaren?
Vi kommer att titta på om tidigare utförda operationer och händelser i systemet
påverkar användarupplevelsen. Vi tittar även på om gränssnittet kan ändras till
användarens fördel.
● Inge förtroende och tillfredsställelse (eng. Increasing confidence and satisfaction) Hur bekräftar systemet för användaren att denne utfört önskvärd åtgärd?
Vi tittar efter bekräftelsedialoger och andra indikationer som förmedlar förändringar
av systemets tillstånd till användaren.
4.4.3 Indelning av beståndsdelar för användbarhetsscenario
När man väl definierat vad som menas med användbarhet kan man övergå till att beskriva
hur användbarhet ska mätas. Bass anger ett användbarhetsscenario (eng. usability scenario)
som kan delas upp i ett antal beståndsdelar. Dessa beståndsdelar påvisar omständigheterna
och avgränsningar för mätningen av användbarhet för ett visst system.
Användbarhetsscenariot kan avgränsas och delas upp i följande beståndsdelar:
● Källa för indata (eng. source of stimulus) - Källan för indata är en självständig entitet
och kan vara allt från en individ till ett datorsystem eller annan typ av självständig
aktör.
I fallet med användbarhetstestning (eng. usability testing) är användaren källan för
indata.
● Indata (eng. stimulus) - Indata är en omständighet, villkor eller önskemål som måste
övervägas
när
denna
når
mottagaren.
I fallet med användbarhetstestning är indatan kategoriserat enligt de
huvudområden som beskrevs i avsnitt 4.4.2. Användaren vill alltså lära sig
systemets funktioner, effektivt kunna använda systemet, minimera inverkan av fel,
anpassa systemet för sina behov och känna förtroende och tillfredsställelse med
användningen av systemet.
● Mottagare (eng. artifact) - En mottagare för indatan måste identifieras. Detta kan
antingen
vara
hela
systemet
eller
en
del
av
systemet.
I fallet med användbarhetstestning är det hela systemet.
Sida | 42
● Miljö (eng. environment) - Utskick av indata och mottagandet av denna sker i en viss
miljö och under vissa omständigheter. Exempelvis kan systemet vara i ett tillstånd av
överbelastning, normalkörning eller i ett avstängt tillstånd. Andra typer av tillstånd
kan
även
äga
rum.
I fallet med användbarhetstestning sker relevanta händelser vid körtid eller vid
konfiguration av systemet (så som t.ex. installation av systemet). Interaktioner med
systemet innan dess räknas till “interaktioner mellan utvecklare och systemet” och
kan därför inte innefattas i detta scenario.
● Respons (eng. response) - Respons är den händelsen som sker efter att indatan tagits
emot
och
behandlats
av
mottagaren.
I fallet med användbarhetstestning förväntas systemet kunna uppfylla användarens
behov genom att förse henne med programfunktioner som möjliggör utförandet av
önskvärda uppgifter. Detta återspeglas via responsen som genereras.
● Mätning av respons (eng. response measure) - När responsen genereras måste
denna mätas på något sätt för att systemet ska kunna kravtestas och för att man ska
kunna fastställa om systemet besvarat indatan med rätt typ av respons.
Responsen i användbarhetstestning kan mätas på ett antal olika sätt: [47-48]
○ Tiden det tog (eng. task time) för användaren att utföra en viss uppgift
○ Antalet fel som uppstod
○ Antalet problem som användaren löst
○ Användarens tillfredsställelse med hur uppgiften löstes mha. systemet
○ Kunskapsökning, känner användaren att hon förstått hur man använder
systemet för att utföra specifika uppgifter?
○ Förhållandet mellan antalet lyckade operationer och totala antalet
operationer som utförts
○ Hur mycket tid/data gick förlorat när ett fel inträffade (vare sig felet
orsakades av systemet eller användaren är ej relevant i detta mätningsfall)
I utförandet av användbarhetstestet kommer vi att välja några av dessa mätningar av
respons som vi anser är mest relevanta för vår studie.
Sida | 43
4.4.4 Uppställning av användbarhetsscenario
Vi utgick från Bass kategorisering av användbarhet och beskrivning av användbarhetsscenario när vi ställde upp vårt scenario [46, s. 106]. CI-systemet TeamCity testades utifrån
detta scenario:
Beståndsdel av Värden
scenario
Källa för
indata
Användare
Indata
Vill
●
●
●
●
●
Lära sig systemets funktioner
Effektivt kunna använda systemet
Minimera inverkan av fel
Anpassa systemet för sina behov
Känna förtroende och tillfredsställelse med användningen av
systemet
Mottagare
CI-system (TeamCity)
Miljö
Normalkörning
Respons
CI-systemet förser användaren med följande responser:
1. För att stödja “Inlärning av systemets funktioner”:
● GUI:t är tydligt och lättanvänt
● GUI:ns design är baserad på “progressive disclosure”
2. För att stödja “Effektiv användning av systemet”:
● Det är enkelt att automatisera funktioner som ofta
kommer att användas t.ex. konfiguration av byggskript
● Återanvändning av data/kommandon som tidigare
inmatats
3. För att stödja “Minimera inverkan av fel”:
● Dialogrutor och säkringar inför mer omfattande
operationer
● Möjlighet att “ångra” (eng. undo) ändringar
4. För att stödja “Anpassning av systemet för användarens behov”:
● Systemets utseende och funktionalitet kan ändras
utifrån användarens behov
5. För att stödja “Inge förtroende och tillfredsställelse”:
● Systemets tillstånd åskådliggörs tydligt för användaren
● Större ändringar bekräftas genom t.ex.
bekräftelsedialoger
Mätning av
respons
● Tid för att utföra en uppgift (eng. task time)
● Antalet problem som användaren löst
● Användarens tillfredsställelse med hur uppgiften löstes
Sida | 44
4.4.5 Uppställning av testformulär och användarenkät
Baserat på användbarhetsscenariot ovan har vi utformat ett testformulär (se bilaga 6) som
vi fyller i för att sammanställa svarsdata från testaren efter utförandet och inspelning av
test. Eftersom vissa svar endast kan besvaras av testaren själv och ej observeras via
inspelning av test har vi även utformat en användarenkät (se bilaga 7) som testaren fyller i
under testets gång.
I testformuläret har vi delat upp uppgifter enligt de responser och huvudområden som
anges i användbarhetsscenariot. Uppgifterna är inte specifika för något enskilt CI-system
och kan därför tillämpas på såväl TeamCity som andra CI-system. Vi har dessutom sett till att
funktionella krav som anses viktiga enligt litteratur- och marknadsundersökningarna
innefattas i testformuläret. Vi har exempelvis med uppgifter där testaren ska bygga källkod
för Java-projektet som vi skapade eller köra tester för Java-projektet, detta eftersom
exempelvis “bygge av källkod” och “testning” framgått som viktiga funktionella krav för CIsystem (se avsnitt 5 för slutsatser kring viktiga funktionella och icke-funktionella krav för CIsystem). Med hjälp av inspelningen av testsessioner kan vi fylla i tiden som förflöt när
testaren utförde en viss uppgift (eng. task time) samt kontrollera om uppgiften löstes
korrekt. I testformuläret fylls även in svarsdata från användarenkäten som endast kan
besvaras av testare, t.ex. tillfredsställelse av att lösa en viss uppgift.
Den andra större dokumentationsartefakten för användbarhetstestning var som nämnt
användarenkäten. Denna fylldes i under testets gång av testaren. Användarenkäten är
TeamCity-specifik och kan till skillnad från testformuläret inte användas för andra CI-system,
den måste i sådant fall skrivas om. Trots detta anknyter den till testformuläret och
användbarhetsscenariot på ett sådant sätt att man kan påstå att den konkretiserar riktlinjer
angivna i dessa artefakter så att de kan tillämpas på TeamCity på ett testbart sätt. I denna
form fyllde testaren bland annat i hur hon upplevde att lösa specifika uppgifter med hjälp av
systemet. Vi var noggranna med att endast inkludera frågor i användarenkäten som inte kan
besvaras via observation. Användarenkäten var inte endast till för att fyllas i av testaren
under testsessionens gång, utan här fanns även all information beskriven för att testaren
ska kunna utföra uppgifterna i TeamCity. En detalj som är värd att nämna är att ordningen
på uppgifterna är strukturerad och optimerad för att minimera förvirring under utförandet
av uppgifter och minska tiden för att utföra testet för samtliga testare, ordningsföljden
beskrivs i testformuläret. För att anknyta till kategorisering av användbarhet enligt Folmer,
Gulp och Bosch lade vi även till 4 korta frågor i slutet av användarenkäten som testaren
svarar på för att delge sin uppfattning om TeamCity enligt dessa 4 kategorier.
Sida | 45
4.4.6 Resultat från användbarhetstestning
I detta avsnitt redovisas de resultat som vi fick fram av användbarhetstestet och analysen av
svarsdatan från testerna som utfördes. Användbarhetstestet är också av betydelse för att
svara på vår andra huvudfråga, om man kan “testa, jämföra och värdera CI-system”. I just
denna studie kommer vi inte att utföra användbarhetstestet på flera olika CI-system men
det är något som kan vara intressant att utföra (se avsnitt 6.3 “fortsatt forskning”).
Bilaga 6 påvisar hur vi samlat och sammanställt data som kommer att presenteras grafiskt i
form av diagram. Bilaga 7 är användarenkäten som användes för att samla in denna data
och agerar som ett gränssnitt mellan oss och testare. Läsaren hänvisas till dessa bilagor för
att ta del av mer utförlig information kring genomförandet av användbarhetstester.
Resultatdatan som kommer att presenteras i detta avsnitt berör olika aspekter av
användbarhetstestet som vi tycker är extra intressanta att titta på. Olika statistik kring
utförandet av testerna samt testarnas subjektiva intryck av att lösa uppgifter och av
TeamCity i sin helhet kommer att åskådliggöras. Samtliga diagram belyser skillnader mellan
testgruppen som bestod av 5 testare och kontrollgruppen som bestod av 1 testare.
Vi analyserar resultaten som redogörs och kan i vissa fall även tolka resultaten. Varje
diagram förses med en förklaring till hur mätningen genomfördes och ibland även en
förklaring till varför vi mätte just detta. Därefter följer en saklig redogörelse av hur datan
som presenteras i diagrammen ska avläsas, följt av en subjektiv tolkning av datan där detta
är möjligt.
Sida | 46
Totalt antal uppgifter som löstes
Vi kontrollerade hur många uppgifter av totalt 17 st som löstes av testare efter varje
testsession via användarenkäten och inspelningar. En del testare ansåg sig vara klara med
vissa uppgifter men det framkom efter granskning av inspelning att detta inte stämde, vi
korrigerade svarsdatan utefter vår uppfattning om huruvida uppgiften löstes korrekt eller ej.
Vi kan på nedanstående stapeldiagram avläsa att kontrollgruppen löste alla 17 uppgifter
medan testgruppen löste nästan alla 17 uppgifter. Testgruppen hade 16.4 uppgifter lösta i
snitt vilket innebar att 3 fel uppstod under de 5 testsessionerna. Varför testgruppen inte
lyckades lösa alla uppgifter är svårt att avgöra utifrån den data som vi samlade in, det kan
antingen bero på att användarenkätens uppgiftbeskrivning för vissa uppgifter var otydlig
eller yttre faktorer som att TeamCity i vissa fall är så användarvänlig och layout-mässigt
anpassad för att stödja nya användare att utföra vissa operationer. Eftersom felen uppstod
bland 3 olika uppgifter (uppgift 3, 4 och 14) är det mer sannolikt att det har att göra med
interaktionen mellan testare och TeamCity snarare än ett allmänt fel i utformandet av
användarenkäten. Vi menar att ett fel i användarenkäten hade kommit till uttryck om olika
testare begick samma fel under utförande av testet (dvs. om felet uppstod på samma
uppgift). Uppgifterna i vilka fel uppstod tillhör huvudområdena “Anpassning av systemet för
användarens behov”, “Inlärning av systemets funktioner” och “Inge förtroende och
tillfredsställelse”.
Trots vår diskussion om de 3 felen som uppstod kan vi konstatera att det nästan “perfekta
resultatet” för antal korrekt utförda uppgifter tyder på att TeamCity stödjer lärbarhet för
användare som aldrig använt systemet tidigare.
Fig. 28: “Totalt antal uppgifter som löstes”
Sida | 47
Total tid för utförande av samtliga uppgifter
Vi tittade inte bara på hur många uppgifter som löstes, vi tittade även på hur lång tid det tog
för testarna att utföra alla uppgifter. Vi gjorde detta genom att gå igenom inspelningarna av
testsessionerna och kolla hur lång tid det tog för varje testare att gå vidare till nästa uppgift,
från att uppgift 1 påbörjades till att uppgift 17 avslutades.
Vi ser intressant data i nedanstående stapeldiagram (jämfört med diagrammet för “totalt
antal uppgifter som löstes”). Kontrollgruppen genomförde samtliga uppgifter på 20 minuter
och 19 sekunder, medan testgruppen utförde uppgifterna på 43 minuter och 18 sekunder.
Vi ser därför en markant skillnad mellan oerfarna TeamCity användare och erfarna
användare med avseende på hur snabbt vissa operationer kan utföras i TeamCity.
Att kontrollgruppen utförde samtliga uppgifter betydligt snabbare än testgruppen tyder på
att TeamCity stödjer användbarhetsattributet effektiv användning.
Fig. 29: “Total tid för utförande av samtliga uppgifter”
Sida | 48
Användarnas tillfredsställelse av att lösa samtliga uppgifter
Efter varje utförd (eller outförd) uppgift angav testaren hur han eller hon upplevde att
uppgiften löstes. Detta gjordes utefter en Likert skala där 1 innebär en låg tillfredsställelse
med utförandet av en viss uppgift och 5 innebär hög tillfredsställelse.
I stapeldiagrammet kan vi avläsa en relativt hög nivå av tillfredsställelse för båda grupperna,
dock ser vi att testgruppen var aningen mindre tillfredsställd i genomsnitt. Detta beror
förmodligen på att testarna i testgruppen inte alltid visste hur de ska göra för att lösa vissa
uppgifter. Vi kan också efter granskning av testformuläret se en korrelation mellan missnöje
och
misslyckande
av
utförandet
av
specifika
uppgifter.
Om vi tittar på kontrollgruppen kan vi se att testaren angivit nivå 5 av tillfredsställelse på
samtliga uppgifter förutom uppgift 1, 6 och 11. Dessa uppgifter tillhör huvudområdet
“Inlärning av systemets funktioner”. Om vi istället tittar på testgruppen kan vi se att
testarna angivit en hög nivå av tillfredsställelse med 5,0 i snitt för uppgift 8 och 13. En låg
nivå av tillfredsställelse kan vi avläsa för uppgift 4 med 2,8 i snitt. Uppgifterna med ett högt
utslag tillhör huvudområdena “Inlärning av systemets funktioner” och “Minimera inverkan
av fel”. Beträffande uppgiften med lågt utslag tillhör den huvudområdet “Anpassning av
systemet för användarens behov”.
Vi kan se att på det stora hela verkar TeamCity stödja användbarhetsattributet
tillfredsställelse. Det verkar dock finnas rum för förbättring när det gäller användarens
tillfredsställelse och upplevelse av hur pass anpassningsbart systemet är för användarens
behov.
Fig. 30: “Användarnas tillfredsställelse av att lösa samtliga uppgifter”
Sida | 49
Total tid för utförandet av enskild uppgift
Under efterbehandligsfasen av testsessionerna tittade vi på hur lång tid det tar för varje
testare att utföra varje enskild uppgift. Startpunkt och slutpunkt markerades när testaren
påbörjade en ny uppgift i användarenkäten genom att gå till nästa sida. På så sätt kunde vi
ta tidspunkter på ett objektivt sätt istället för att gissa oss fram till när en viss uppgift
påbörjades eller avslutades. Vissa testare kommunicerade även med oss mellan utförandet
av uppgifter, detta noterades och räknades bort för att inte driva upp datan till högre nivåer
pga. dessa “pauser”.
Vi kan väldigt tydligt se från linjediagrammet att kontrollgruppen låg snäppet under
testgruppen vad gäller snabbheten i att utföra uppgifterna. Dock kan vi se att
genomsnittstiden för utförandet av enskild uppgift för testgruppen var aningen lägre på 1
minut och 10 sekunder jämfört med 1 minut och 16 sekunder för kontrollgruppen. Vad
detta kan bero på är svårt att fastställa, dock kan vi konstatera att det har att göra med
uppgiften “Kompilera källkod för ett projekt” som tillhör responsen “Det är enkelt att
automatisera funktioner som ofta kommer att användas” och huvudområdet “Inlärning av
systemets funktioner”.
Fig. 31: “Total tid för utförandet av enskild uppgift”
Sida | 50
Tidigare erfarenhet av CI-system
Till skillnad från tidigare redovisad resultat så presenterar vi via detta stapeldiagram inte
mätningar. Vi redogör här hur testarna har svarat när de tillfrågades vilken tidigare
erfarenhet de har av CI-system och vilken CI-systemmjukvara de har använt sig av.
Som nämnt i utförandet av användbarhetstestet så var målgruppen för testerna användare
som både hade erfarenhet av CI-system tidigare men ej av TeamCity och användare som
tidigare använt sig av TeamCity. Detta åskådliggörs rätt tydligt i stapeldiagrammet då vi ser
att endast testaren från kontrollgruppen angav att han hade erfarenhet av TeamCity. Han
angav även erfarenhet av CruiseControl.net.
Slutligen vill vi även påpeka att tidigare erfarenhet av CI-system kan ha en betydelse för
olika statistik och data som erhålls från denna typ av användbarhetstest. Det kan vara så att
Jenkins är likt eller olikt till användning och utseende som TeamCity. Detta innebär att
inlärningskurvan för TeamCity kan bero på vilken tidigare erfarenhet av CI-system man har,
därför är detta viktigt att belysa och ta hänsyn till både i vår studie och liknande studier,
genom att exempelvis ställa motsvarande fråga i andra enkäter.
Fig. 32: “Tidigare erfarenhet av CI-system (båda grupper)”
Sida | 51
Hur pass väl stödjer TeamCity “Lärbarhet”?
Som tidigare nämnt så använder vi oss av 4 användbarhetsattribut för att fastställa vilket
intryck testarna har av TeamCity. Vi börjar med att diskutera lärbarhet. Lärbarhet har att
göra med hur snabbt användaren lär sig använda systemet och hur lätt det är att minnas hur
man använder systemet.
Vi kan från diagrammet avläsa att kontrollgruppen angav den högsta nivån för lärbarhet.
Kanske beror detta på att denna testare redan är bekant med hur TeamCity används och
därför även anser att nya användare kommer att snabbt kommer att lära sig hur man
använder TeamCity.
Om vi tittar på testgruppen kan vi se att de allra flesta svarat att de anser att TeamCity
stödjer lärbarhet. Denna data är aningen mer intressant att titta på, främst pga. dessa
testare uppgav att de inte använt TeamCity tidigare. Detta tyder på att nya användare efter
utförandet av 17 uppgifter tycker att TeamCity är ganska bra på att lära användaren hur
man kommer igång med användningen av CI-systemet.
Fig. 33: “Hur pass väl stödjer TeamCity ‘Lärbarhet’?”
Sida | 52
Hur pass väl stödjer TeamCity “Effektiv användning”?
Effektiv användning av ett system innebär att en användare snabbt kan utföra operationer i
systemet och kan effektivisera det han eller hon genomför med hjälp av systemet ju mer
bekant han eller hon blir med användandet av systemet.
Resultatdatan som åskådliggörs via diagrammet påvisar även här att de flesta testare har en
uppfattning om att TeamCity stödjer effektiv användning. Till skillnad från föregående
diskussion om lärbarhet, är det mer betydelsefullt att belysa kontrollgruppens uppfattning
av effektiv användning. Detta eftersom en testare med tidigare erfarenhet av TeamCity
förmodligen har använt systemet under en viss tid och kan därför ha en uppfattning om
TeamCity “håller i längden”. Om vi tittar på testgruppen kan vi se att de flesta angett nivå 4
för just detta användbarhetsattribut. Både testare 4 och 5 har angett att TeamCity stödjer
effektiv användning trots att deras totala tid för utförandet av uppgifterna hörde till de
längre tidtagningarna.
Tolkning: Att de markerat nivå 5 kan bero på att de under testets gång ansåg att det gick
fortare framåt när de lärde sig använda systemet bättre, men kanske också pga.
testsessionen var så pass långt gången att de snabbt ville “fylla i den sista sidan” i
användarenkäten och bli klara med testsessionen.
Fig. 34: “Hur pass väl stödjer TeamCity ‘Effektiv användning’?”
Sida | 53
Hur pass väl stödjer TeamCity “Tillförlitlighet”?
Ett system som är tillförlitligt är ett system utformat på så sätt att en användarens
interaktion med systemet genererar ett lågt eller obefintligt antal fel vid “normalt bruk”.
Tillförlitlighet innebär även att ett system snabbt kan återhämta sig från fel som kan uppstå.
Som vi kan se på diagrammet nedan så har samtliga testare angett högsta nivå för att påvisa
att TeamCity stödjer tillförlitlighet. Detta är rätt ointressant data att diskutera eftersom det
inte finns någon variation, dock kan vi konstatera att TeamCity är ett tillförlitligt system
utifrån denna data.
En intressant sak som vi kan påpeka är testare 3’s svar på frågan. Denna testare angav att
han inte hade tillräckligt med erfarenhet av TeamCity för att dra denna slutsats och att
ytterligare användning av TeamCity krävs för att på ett bestämt sätt kunna fastställa om
TeamCity faktiskt är tillförlitligt.
Fig. 35: “Hur pass väl stödjer TeamCity ‘Tillförlitlighet’?”
Sida | 54
Hur pass väl stödjer TeamCity “Tillfredsställelse”?
En användares tillfredsställelse med ett system är hur denna individ subjektivt upplever
användningen av systemet. Som nämnt har testaren efter varje uppgift svarat på hur
tillfredsställd han eller hon är med hur uppgiften löstes. Även på slutet av användarenkäten
frågar vi testaren hur tillfredsställd han eller hon är med TeamCity i stort.
Vi kan även i detta diagram se en homogenitet mellan svarsdatan där endast små avvikelser
förekommer. De allra flesta testare har angett nivå 4 av tillfredsställelse för TeamCity.
Ännu en intressant sak som kan påpekas är testare 2’s svar för denna fråga där testaren
angett att en längre tid med användandet av CI-systemet krävs för att kunna fastställa om
TeamCity är tillfredsställande att användas.
Fig. 36: “Hur pass väl stödjer TeamCity ‘Tillfredsställelse’?”
Sida | 55
5. Slutsats
Vår frågeställning bestod av 2 huvudfrågor och 4 delfrågor (se avsnitt 1.3).
Efter genomförd marknadsundersökning och litteraturundersökning kan vi dra en slutsats
kring vad ett CI-system principiellt bör bestå av, vilka funktioner den bör förse användaren
med samt vilka kvalitetsattribut som bör eftersträvas.
Svaren till vår första huvudfråga “Vilka funktionella och icke-funktionella krav måste CIsystem uppfylla för att vara till nytta för användning?” är följande:
● Funktionella krav:
○ Källkodshantering (eng. source code management)
○ Kompilering av källkod (eng. build/compile source code)
○ Exekvering av byggskript (eng. running arbitrary build scripts), med möjlighet
till byggautomatisering (eng. enable build automation)
○ Körning av tester (eng. run tests)
○ Notifiering av status för bygge (eng. feedback/notification of build status)
○ Stöd för paketering och distribution av mjukvara (eng. support deployment of
stable software)
● Icke-funktionella krav:
○ Prestanda (eng. performance)
○ Användbarhet (eng. usability)
○ Tillförlitlighet (eng. reliability)
○ Utbyggbarhet (eng. extensibility)
○ Stabilitet (eng. stability)
○ Underhållsmässighet (eng. maintainability)
Efter genomförd användbarhetstest kan vi även besvara vår andra huvudfråga och därmed
validera en del av den slutsats vi fått fram via första huvudfrågan.
Vår andra huvudfråga “Kan man enligt fastställda krav testa, värdera och jämföra CIsystem?” besvaras positivt via de resultat som vi redogör i avsnitt 4.4.6. Genom en
utvärdering av användbarhet för CI-systemet TeamCity demonstrerade vi detta praktiskt.
Genom att använda sig av testformuläret som vi fick fram under utförandet av
användbarhetstestet och genom att modifiera användarenkäten för ett annat CI-system kan
man även utföra användbarhetstestet för andra CI-systemmjukvaror.
Sida | 56
Delfråga 1 “Vilken mjukvara för CI-system används mest?” besvaras av både litteraturundersökningen och marknadsundersökningen.
Enligt undersökningarna kom vi fram till följande:
● Litteraturundersökningen pekar på:
○ CruiseControl och dess varianter
○ Jenkins
○ Hudson
○ Bamboo
○ TeamCity
○ Buildbot
● Marknadsundersökningen pekar på:
○ Jenkins
○ TeamCity
CruiseControl och dess varianter nämns fortfarande i litteratur och är en väletablerad CIserver mjukvara som funnits i över 10 år. Hudson som senare blev Jenkins har en stor
marknadsandel och nämns även den i litteraturen. TeamCity nämns inte så ofta i litteratur,
däremot visar marknadsundersökningen att även den har en stor marknadsandel. Vi kan dra
slutsatsen att Jenkins används mest, tätt följd av TeamCity men att även andra CI-server
mjukvaror så som CruiseControl nämns i litteraturen och säkerligen används än idag.
Delfråga 2 “Vilka för- och nackdelar finns det för ett CI-system?” besvaras av
marknadsundersökningen och diskuteras även i avsnitt 2.4. Med hjälp av denna fråga vill vi
ta reda på vad som utmärker vissa CI-system från andra och vad det är som gör att en grupp
utvecklare väljer att använda ett CI-system över ett annat. Vi tittar också på eventuella
nackdelar som utvecklare tycker att deras CI-system har. Svarsobjekten för
marknadsundersökningen har angivit att de främsta fördelarna med deras CI-system är att
det är lättanvänt, stabilt och tillförlitligt.
När svarsobjekten tillfrågades om nackdelar med deras CI-system var det en signifikant
andel som inte kunde identifiera någon betydlig nackdel. Om vi däremot tittar på de
svarsobjekt som identifierade nackdelar med sitt CI-system nämnde de svårigheter med att
felsöka, en hög kostnad (av att sätta upp och underhålla systemet) och instabilitet. Andra
nackdelar specificerades också men dessa nämns ej här.
Delfråga 3 “Hur pass utbredd är användningen av CI-system bland utvecklare inom företag
som använder sig av dessa system?” besvaras av marknadsundersökningen (se analys av
fråga 4). 41% av svarsobjekten svarade att 100% av deras utvecklare använder sig av CIsystemet och övriga svarsobjekt anger att ca 60-100% av utvecklare på företaget påverkas
av CI-systemet. Endast tre svarsobjekt utav 39 svarade att CI-systemet endast påverkar 10%,
30% resp. 50% av deras verksamhet, där de resterande angav en större andel utvecklare
Sida | 57
som påverkas av CI-systemet. Vi kan därför konstatera att nästintill 100% av utvecklare på
företagen påverkas av CI-systemet där ett sådant är implementerat.
Delfråga 4 “Leder CI-system till en mer effektiv utvecklingsprocess för mjukvaruutvecklare?”
besvaras av marknadsundersökningen (se analys av fråga 10). 97% av svarsobjekten har
svarat att deras CI-system leder till att deras verksamhet kan prestera bättre. Att en
tillämpning och användning av CI-system har övervägande fördelar jämfört med dess
nackdelar nämns även i litteraturen. Därmed kan vi dra slutsatsen att ett CI-system leder till
en mer effektiv utvecklingsprocess för mjukvaruutvecklare.
Sida | 58
6. Diskussion
I detta avsnitt vill vi diskutera sådant som tidigare nämnts i rapporten. Vi börjar med att
diskutera krav som CI-system bör uppfylla enligt våra undersökningar i avsnitt 6.1 och
huruvida vår uppfattning om vilka krav som var viktiga stämde under tidiga skeden av
examensarbetet. I avsnitt 6.2 redovisar vi smärre fel och misstag som gjordes under
examensarbetets gång men även alternativa tillvägagångssätt och förbättringsförslag, med
andra ord utföranden av moment som hade kunnat göras på ett annat sätt. Slutligen
kommer vi i avsnitt 6.3 att spåna på framtida forskningsförslag och försöka klargöra hur
man kan gå vidare med de resultat som vi kommit fram till i vår studie.
6.1 Diskussion av kraven
Vi kan från både litteratur- och marknadsundersökningen komma underfund med att CIsystem består av betydligt fler funktionella krav än vad vi hade förväntat oss
(grönmarkerade) under tidiga skeden av examensarbetet. Av dessa undersökningar framgår
det att följande funktionella krav är betydelsefulla:
● Källkodshantering (eng. source code management)
● Kompilering av källkod (eng. build/compile source code)
● Exekvering av byggskript (eng. running arbitrary build scripts)
● Körning av tester (eng. run tests)
● Notifiering av status för bygge (eng. feedback/notification of build status)
● Stöd för distribution av mjukvara (eng. support deployment of stable software)
● Möjliggörandet av byggautomatisering (eng. enable build automation)
○ Förse utvecklarna med en infrastruktur som möjliggör upprepbara byggen
(eng. provide infrastructure for repeatable builds)
● Hantering av byggartefakter (eng. internal handling of build artifacts)
Vi kan dock se att de funktionella krav som vi utgick från fick högt utslag i undersökningarna.
Vi förutsåg inte att övriga funktionella krav som listas ovan (ej grönmarkerade) även är av
betydelse.
Den största överraskningen för oss var beträffande icke-funktionella krav där vi förväntade
oss att “performance” (grönmarkerat) skulle få högst utslag. Visserligen påvisar båda
undersökningarna att “performance” är ett eftersträvat icke-funktionellt krav för CI-system,
däremot visade sig att det fanns andra minst lika betydelsefulla icke-funktionella krav (ej
grönmarkerade) som både litteraturen och slutanvändare av CI-system påpekade. Samtliga
icke-funktionella krav som är av intresse listas nedan:
●
●
●
●
●
●
●
●
Prestanda (eng. performance)
Användbarhet (eng. usability)
Flyttbarhet (eng. portability)
Interoperabilitet (eng. interoperability)
Utbyggbarhet (eng. extensibility)
Stabilitet (eng. stability)
Tillförlitlighet (eng. reliability)
Underhållsmässighet (eng. maintainability)
Sida | 59
Varför stämde då vår tidigare uppfattning om vilka krav som ett CI-system måste uppfylla
inte helt överens med den slutsats som vi kom fram till efter undersökningarna? Troligtvis
beror det på ett flertal olika anledningar. Under förstudien hade vi inte all information till
vårt förfogande och vi hade därför en väldigt vag idé om hur CI-system används och vad de
består av. Dessutom skiljer sig beskrivningar av CI-system och användandet av vissa begrepp
mellan olika författare och källor, något som gör det svårt att dra slutsatser från ett stort
antal källor [4]. Marknadsundersökningen var till stor hjälp för att ta reda på vilka krav ett
CI-system ska uppfylla och en bra vägvisare när vi försökte göra tvetydiga begrepp, som vi
stötte på under litteraturundersökningen, entydiga.
6.2 Förbättringar
Nedan presenterar vi olika förbättringar och alternativa lösningar samt reflektioner kring
hur vissa moment hade kunnat utföras utifrån andra förutsättningar (så som en obegränsad
tidsomfattning eller en större budget):
● Utförande av intervjuer som medel för en marknadsundersökning istället för en
enkätundersökning: Det finns en rad olika skäl till varför intervjuer kan användas för
att utföra en marknadsundersökning istället för att använda ett opersonligt medium
som enkäter. I studier där man använder sig av intervjuer kan man ofta inte nå ut till
lika många individer som man kan med hjälp av enkäter, däremot kan man inrikta sig
på att träffa nyckelpersoner för ens studie. Exempelvis hade en intervju med Kent
Beck eller Martin Fowler gett oss rik information om hur CI-system området ser ut
just nu. Intervjuer ger en mer kvalitativ data att arbeta med och kanske mer
tankeväckande svar. Intervjuaren kan ändra frågor, klargöra punkter och ställa nya
frågor beroende på vilken riktning intervjun tar, detta kan leda till en rikare
marknadsundersökning. [24, s. 323]
● En fråga i marknadsundersökningen ställdes på ett oklart sätt: Fråga 4 i
marknadsundersökningen borde ha formulerats på ett mer konsekvent sätt.
Frågan som ställdes var “What percentage of your developers uses or is affected by
the CI-solution?”. Ursprungligen ville vi ta reda på hur många anställda på företaget
(även de som inte direkt jobbar med mjukvaruutveckling eller annan IT-verksamhet,
t.ex. kundservice, försäljningsavdelningen eller PR-avdelningen) som påverkas av
företagets
CI-system.
Ett exempel på ett sådant scenario är: Kundservicen för företag X är överbelastad
med klagomål eftersom en uppdatering i ett mjukvarupaket som företaget lanserat
skapat problem för deras kunder. Efter att mjukvaruutvecklarna tagit till sig
användning av CI-system så är kundservicen inte lika belastad, även under perioder
där
många
uppdateringar
lanseras
till
kunder.
Tyvärr ställdes frågan på ett sätt som innebar att vi endast fick ut svarsdata som
tyder på hur utvecklarna på företaget berörs. Därför var vi tvungna att i ett senare
skede även omformulera delfråga 3, något som inte påverkade integriteten av
Sida | 60
studiens syfte eller mål men gott kunde undvikas och klargöras innan enkäten
skickades iväg.
● Vi hade kunnat ställa upp och jämfört flera olika CI-system: Genom att göra detta
kan man utifrån fler referenspunkter utvärdera prestandan och funktionaliteten av
ett visst CI-system, TeamCity i vårt fall. Uppställning av ett CI-system med hjälp av
exempelvis Jenkins, CruiseControl eller Bamboo hade varit spännande, tyvärr tar
detta också tid och innebär en större omfattning av examensarbetet.
● Vi hade även kunnat utföra flera typer av icke-funktionella tester: I vår studie
undersökte vi användbarhet (eng. usability). Det hade även varit intressant att titta
på och mäta andra icke-funktionella krav, t.ex. prestanda (eng. performance),
utbyggbarhet (eng. extensibility) eller tillförlitlighet (eng. reliability). Dock innebär
detta liksom föregående punkt en ökad omfattning av examensarbetet, inte endast
eftersom det tar tid att utföra utan även för att ytterligare kunskaper måste
införskaffas inom dessa områden.
● Körning av CI-system via virtuella maskiner (VM): Det finns flera fördelar med att
använda sig av virtuella maskiner för att köra CI-system. Nedan kommer vi att ange
hur användning av virtuella maskiner både hade kunnat underlätta
användbarhetstestningen men också hur det hade skapat fler möjligheter för
simuleringar av olika slag:
○ Man kan via en virtuell maskin installera och konfigurera TeamCity på ett
säkert sätt, i den mening att om ett fel uppstår så kan man återställa
TeamCity till ett tidigare tillstånd eller helt enkelt rensa TeamCity från den
virtuella maskinen.
○ Användning av virtuella maskiner medför en positiv egenskap om man tittar
på säkerhetsaspekten av att tillåta utomstående enheter att koppla upp sig
mot en server (i syfte att utföra tester). Kör man t.ex. TeamCity via en virtuell
maskin så kan utomstående användare som har för avsikt att sabotera eller
skada maskinen som de fått tillgång till endast navigera inom ramarna för
den virtuella maskinen. Detta innebär att förändringar i systemet som görs
snabbt kan återställas till ett fungerande tillstånd utan att påverka
värdsystemet (dvs. operativsystemet som kör den virtuella maskinen). Under
vårt arbete har vi som nämnt använt TeamViewer och har fått vara försiktiga
med att uppkopplade testare inte utför ändringar i systemet som kan vara
skadliga.
○ Man återställer CI-systemet till ett “testbart tillstånd” efter varje test, så att
nästa testsession kan utföras. Under detta examensarbete var vi tvungna att
anteckna vilka ändringar användaren gör i CI-systemet och sedan återställa
dessa efter att testet genomförts så att nästa testare utgår från samma
situation. Med virtuella maskiner kan detta göras betydligt lättare genom att
återställa CI-systemet till tidigare s.k. “snapshots”.
Sida | 61
○ Man skulle kunna köra 2 instanser av TeamCity parallellt och utföra olika
tester på dessa. På så sätt kan man smidigare upptäcka skillnader mellan
instanserna och fastslå vad skillnaden orsakas av.
○ När man kör ett system via en virtuell maskin så har man en väldigt precis
kontroll över allokering av hårdvaruresurser för just denna virtuella maskin.
Om man då kör TeamCity via en virtuell maskin så kan man utföra olika tester
med varierande parametrar och hårdvarubegränsningar för att se skillnader i
utslag utifrån dessa parametrar.
○ Användning av TeamCity på en virtuell maskin som agerar centralenhet och
build agents på andra virtuella maskiner som utför själva jobbet för att
simulera kommunikation mellan olika fysiska enheter i en typisk CI-system
miljö där man ofta har skalbar decentralisering av CI-systemet och inte kör
både TeamCity och dess build agents på samma server/maskin.
● Körning av CI-system i Linux: Unixliknande operativsystem är att föredra för att
ställa upp CI-system. Exempelvis är körning av CI-system i Linux tillförlitligare i den
mening att fel och stabilitet inte påverkas lika mycket när servern är igång under en
längre tid. Det är även enklare att konfigurera CI-system via Linux om man är bekant
med gränssnittet och de verktyg som finns att tillgå. Vi hade inte stora problem med
tillförlitlighet när vi körde TeamCity i Windows 8 men det fanns en del problem med
skrivrättigheter och tillgång till konfigurationsfiler för TeamCity. Även uppstart av
TeamCity eller då användning återupptogs efter en tid av TeamCity som varit i drift
under längre tid var ibland trögt. Vi hade även problem med virtuella
nätverksadaptrar
när
vi
försökte
ställa
upp
virtuella
maskiner.
Ett annat moment som kan lösas på ett smidigare sätt i Linux är SSH uppkopplingar
för fjärrstyrning. Detta kan då användas istället för TeamViewer. TeamViewer
upplevdes som “trögt” av många testare i den mening att det fanns en viss
latens/fördröjning och möjligtvis paketförlust i anslutningen mellan testarens enhet
och servern och att testaren ibland fick klicka ett par extra gånger för att kunna
navigera
i
TeamCity
via
TeamViewer.
Anledningen till varför vi inte använde oss av Linux var för att vi inte hade förkunskap
om detta operativsystem, men det är något som är värt att titta på och kanske hade
vissa moment kunnat lösas på ett smidigare sätt om vi använt oss av Linux.
● Förberedandet av användbarhetstester kan automatiseras: De förberedelser som
gjordes inför användbarhetstesterna var manuella. Delvis har detta att göra med att
vi inte använde virtuella maskiner men en del inställningar gjordes även utanför en
tänkt “VM-miljö”. Exempel på dessa förberedelser är schemaläggning av testare och
uppdatering av status (t.ex. om en testare ändrar tid), sätta igång användarenkäten
och TeamViewer för användning, skicka ut uppkopplingsinstruktioner till testare,
sätta igång inspelning av testsession när testaren väl kopplat upp sig samt
efterbehandling av testsessionen som innebar allt från att stänga ner
användarenkäten och TeamViewer, till att uppdatera schemaläggning och bokföring
Sida | 62
av testare, skicka ut “tack mejl” till testare och behandla svarsdatan. Många av ovan
nämnda uppgifter kan automatiseras och förenklas, på så sätt minskar man
arbetsbördan av att utföra testerna och kan därför fokusera sin tid på annat.
● Smärre fel i designen av användbarhetstestet: Ett antal smärre fel smög sig in i
designen av den dokumentation som skapades för användbarhetstestet. Nedan
presenteras dessa fel:
○ Bakgrundsinformation som testkandidater angav när de anmälde sitt intresse
för användbarhetstestet och i användarenkäten innan testet utfördes
behövde inte ha med fältet “task assignment”. Detta var till för att ge en
rikare bild av testarens bakgrund men var något som de flesta testare inte
tog till sig. Det räcker alltså om testaren endast anger “occupation”.
○ Både testgruppen och kontrollgruppen klarade de flesta uppgifter (eng.
tasks) under användbarhetstestet. Båda grupperna gick igenom 17 uppgifter
där kontrollgruppen klarade 17 uppgifter och testgruppen klarade 16.4
uppgifter i snitt. Det vore intressant att veta varför vissa inte klarade av alla
uppgifter och just därför hade vi ett fritextfält där testaren motiverade varför
hon inte klarade just den uppgiften. Dock kunde den beskrivande texten, som
angav att testaren ska motivera varför hon misslyckades med uppgiften, vara
lite mer detaljrik och kräva att testaren anger om felet låg i TeamCity eller om
det var uppgiftsbeskrivningen som var vag. Man skulle även kunnat föra en
diskussion med testaren efter en misslyckad uppgift för att få en bättre bild
av vad som gick fel, detta är speciellt viktigt när man utför
användbarhetstest, att man vet vad som gick fel och varför, så att detta
senare kan åtgärdas.
● Användning av bättre verktyg: Detta examensarbete utfördes utan en budget. Vi
använde oss av gratisverktyg och medel som försågs av Malmö Högskola för att
kunna utföra samtliga moment. Dock hade vissa moment kunnat utföras både
snabbare och kanske med en större grad av kontroll om vi använt oss av verktyg som
kostar lite extra. Exempel på vad som hade kunnat göras annorlunda om vi haft en
budget att tillgå presenteras nedan:
○ Användning av SurveyMonkey.com eller liknande verktyg för att utföra
marknadsundersökning via enkäter men även användarenkäten som
användes för användbarhetstestet. Vi använde oss i vårt arbete av Google’s
gratisverktyg och dessa fungerar utmärkt när man vill få fram mindre och
enklare artefakter och dokument, men det var mycket som var omständigt
och saknades i t.ex. Google Forms. En teknisk begränsning var att det inte går
att manipulera olika element samtidigt och utföra flera operationer åt
gången (eng. bulk operations). Detta innebär att en uppställning av t.ex. 20
frågor tar relativt lång tid eftersom man inte enkelt kan behandla och
återanvända tidigare inmatningar. En annan teknisk begränsning var att
Google Forms stöd för logisk utgrening är bristfällig och därför kräver
Sida | 63
kringgående (eng. workaround) som även dessa har begränsad användning.
Exempelvis vill man ofta dölja vissa element och endast visa dessa om
användaren svarat på ett visst sätt, detta kan inte göras i Google Forms och
innebär därför att svarsobjektet presenteras med lite för mycket information
än vad som är nödvändigt.
○ Rekrytering av testare via tjänster som t.ex. UserTesting.com. Med hjälp av
denna typ av tjänst kan man snabbt och enkelt skräddarsy ett
användbarhetstest och få testare som är avlönade för att utföra testet. Efter
utförda test får man en detaljerad rapport och andra artefakter för att
bedöma hur pass användbar systemet som man testat är. Tjänsten
UserTesting.com kostar $49 för en videoinspelning eller $225/månad.
En fördel med att använda sig av denna typ av tjänster är att man snabbt kan
få svarsdata som kan bearbetas. Momenten med att skicka ut inbjudningar
för marknadsundersökningens enkät och användbarhetstestet var rätt
tidskrävande. Marknadsundersökningen nappade individer på rätt snabbt,
inbjudningarna för användbarhetstestet tog dock en lite längre tid trots att vi
nådde ut till mer än 400 individer för båda delarna. Denna tid kunde ha
sparats in genom att använda sig av olika tjänster där man förses med en
grupp testare.
○ Slutligen vill vi påpeka att hårdvara även kan användas för användbarhetstest
som utförs fysiskt (ej via internet). Exempelvis kan man använda sig av olika
instrument som “eye tracking” för att få in rik data från testare som på ett
mer tillförlitligt sätt beskriver hur testaren upplever utförandet av
användbarhetstestet. Detta kräver antingen att hårdvaran finns tillgänglig för
oss och att testerna då måste utföras lokalt eller att testare som befinner sig
på olika platser måste ha tillgång till hårdvaran eller teststudios varifrån
testerna kan utföras.
Sida | 64
6.3 Fortsatt forskning
En del nya frågeställningar uppkom under genomförandet av denna studie. Det finns nog
många olika spår som man kan gå vidare på för att utforska CI-system:
● Man skulle kunna titta på vad som gör vissa CI-system bättre än andra. Konsensus
verkar vara att CI-system i de flesta fall är nyttigt för verksamheter, men om man
istället för att titta på vilka krav ett CI-system ska uppfylla tittar på vad det är som
gör att vissa utvecklingsteam använder sig av en viss CI-systemmjukvara istället för
en annan, kan man nog ta reda på en hel del intressanta saker kring state-of-the-art
CI-system.
● Man kan titta på vilka olika typer [13] av CI-system som finns. Man utgår från en
modell [4] och tittar på hur olika delar av ett CI-system hänger ihop samt redogör för
varför vissa typer används i vissa sammanhang.
● Analysera CI-system utifrån en reglerteknisk synvinkel där man tittar på vad som
händer när ett överflöde av incheckningar sker. Hur hanterar utvecklare ett oreglerat
flöde av arbetsenheter som bearbetas av CI-systemet, motverkar detta själva
continuous integration-processen eller kan CI-system anpassas för att hantera dessa
typer av “svängningar”?
● Skapa CI-systemmjukvara som kan integrera och använda sig av befintliga verktyg
och plugins som finns till andra CI-systemmjukvaror.
● Implementera flera olika CI-system och kravtesta dessa enligt de krav som vi
framfört. Vidareutveckla vår modell för att utvärdera CI-system.
Sida | 65
Referenser
Bibliografi
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
K. Marcin, B. Craig, “Continuous integration in .NET”, Stamford: Manning Publications,
2011.
Y. Ki, M. Song, ”An Open Source-Based Approach to Software Development
infrastructures”, ASE, 2009, s. 525-529.
K. Beck, Extreme Programming Explained: Embrace Change, Upper Saddle River:
Addision-Wesly, 1999.
D. Ståhl, J. Bosch ”Modeling continuous integration practice differences in industry
software development”, Journal of Systems and Software, vol. 87, s. 48-59,
Januari 2014.
M. Fowler, “Continuous Integration”, maj 1, 2006,
http://martinfowler.com/articles/continuousIntegration.html. [Hämtad: 25 feb 2014].
M. Larsson, N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila
metodikens utformning i praktiken," Examensarbete, Malmö högskola, Sverige, 2009,
http://muep.mah.se/handle/2043/8343. [Hämtad: 12 mars 2014].
Abdul, F.A; Fhang, M.C.S. “Implementing Continuous Integration towards
Rapid Application Development”, ICIMTR, 2012, s. 118-123.
Volodymyr Melymuka. TeamCity 7 Continuous Integration Essentials: A step-by-step
introductory tutorial and intelligible practical guide to successfully
applying Continuous Integration via TeamCity, Birmingham: Packt Pub, 2012.
P. Duvall , M. Steve, G. Andrew. Continuous integration: improving
software quality and reducing risk, Saddle River. NJ: Addison-Wesley, 2007.
Farley, Dave; Humble, Jez. Continuous Delivery Reliable Software Releases through
Build, Test, and Deployment Automation, Boston: Pearson Education, 2010.
M. Bathie, “Continuous Integration- Basic Overview and Best Practices”, CollabNet, April
11, 2010,
http://blogs.collab.net/cloudforge/continuous-integration-overview-best-practice.
[Hämtad: 7 mar 2014].
L. White, “Continuous Integration Strategies”, Red Hat, nov 8, 2013,
http://developerblog.redhat.com/2013/11/08/ci-strategies. [Hämtad: 6 mar 2014].
C. T. Brown, R. Canino-Koning, “Continuous Integration”, The Architecture of Open Source
Applications, first edition, A. Brown, G. Wilson, Calif. : Creative Commons, 2011, s 125-139.
E. Duvenage, “Continuous integration basics”, WordPress, nov 14, 2011,
http://www.eugeneduvenage.com/series/continuous-integration-2/.
[Hämtad: 7 mar 2014].
H.M. Yuksel, “Using continuous integration and automated test techniques for a robust
C4ISR system”, ISCIS 2009, s. 743- 748.
Eun Ha Kim, “Implementing an Effective Test Automation Framework”, COMPSAC 2009,
s. 534-538, 20-24.
Sida | 66
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
I. Sommerville. Software Engineering: International computer science series,
Ninth edition, Boston: Addison-Wesley, 2001.
Future Publishing Limited. “The new design methodologies”, Oct 30, 2012,
http://www.creativebloq.com/design/new-design-methodologies-1012599.
[Hämtad: 15 aug 2014].
Livermore, J.A. “Factors that impact implementing an agile software development
methodology”, SoutheastCon, 2007, s. 82-86, 22-25.
QAI Global Service. “ Agile Methodology”,
http://www.qaiglobalservices.com/SCRUM-Master-Agile-Methodology-Consulting.html.
[Hämtad: 15 aug, 2014].
Ronald E. Jeffries. “What is Extreme Programming?”, Xprogramming, March 16, 2011
http://xprogramming.com/what-is-extreme-programming/. [Hämtad: 15 aug 2014].
J. Baumeister, J. Reutelshoefer. “Developing knowledge systems with
continuous integration”, Proceedings of the 11th International Conference on Knowledge
Management and Knowledge Technologies, 2011, vol 33 , 4 sidor.
PRQA Programming Research. “Continuous Integration”,
http://www.programmingresearch.com/products/continuous-integration-jenkinsplug-in/. [Hämtad: 21 maj 2014].
M. Saunders; P. Lewis; A. Thornhill, Research methods for business students, Fifth
edition, Harlow: Pearson Education Limited, 2009.
G. Borrêga, “Functional Requirements and Their Poor Cousins: The Truth About
Non-Functional Requirements (NFRs), Platform - OutSystems, mar 25, 2013
https://www.outsystems.com/blog/2013/03/the-truth-about-non-functionalrequirements-nfrs.html. [Hämtad: 3 aug 2014].
M. Griffiths, “Non-Functional Requirements - Minimal Checklist”, Leading Answers,
march 29, 2009,
http://leadinganswers.typepad.com/leading_answers/2009/03/nonfunctionalrequirements-minimal-checklist.html. [Hämtad: 5 aug 2014].
T. Stålhane, “Non-functional requirements”, NTNU,
http://www.idi.ntnu.no/emner/tdt4242/materials/Non-functionalrequiements.ppt.
[Hämtad: 5 aug 2014].
P. B. Hoggett, “Making Quality Software: 12 non functional requirements every
app should have”, WordPress, jan 7, 2011
http://eyefodder.com/2011/06/quality-software-non-functional-requirements.html.
[Hämtad: 6 aug 2014].
Agileheads, “Continuous Integration Basics”, mar 8, 2012,
http://agileheads.wordpress.com/2012/03/08/continuous-integration-basics/.
[Hämtad: 8 mar 2014].
P. M. Duvall, “Continuous Integration”: Improving Software Quality with Continuous
Integration, 2007, Stelligent Inc, http://www.wjug.org/wjug/docs/ci-quality-bw.pdf.
[Hämtad: 8 mar2014].
Sida | 67
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46]
[47]
[48]
Xamarin, “Introduction to Continuous Integration with Xamarin”: Integrating Xamarin
Projects into a Continuous Build Workflow,
http://developer.xamarin.com/guides/cross-platform/ci/intro_to_ci/.
[Hämtad: 9 mar 2014].
D. Bowler, “Ten Best Practices For Continuous Integration”, CollabNet, okt 9, 2012,
http://blogs.collab.net/devopsci/ten-best-practices-for-continuous-integration .
[Hämtad: 10 mar 2014].
E. Crewe, “Continuous Integration (C.I)”,
https://docs.google.com/presentation/d/1Lagu5-PZp22XxL2voBmORv04R6UngRUJ
s5SClshT2Ck/present. [Hämtad: 11 mar 2014].
W. Billingsley, J. Steel, “A comparison of two iterations of a software studio course based
on continuous integration”, ITiCSE, 2013, s. 213-218.
S. Stolberg, “Enabling Agile Testing Through Continuous Integration”, AGILE 2009,
s. 369-374.
John W. Creswell. Qualitative, Quantitative, and mixed methods approaches, 4th
edition, Lincoln: SAGE Publications, 2014.
Sarah L. Collie, P. Jesse Rine; ”Survey Design: Getting the results you need”,
Office of Process Simplification, May 26, 2009,
http://www.virginia.edu/processsimplification/resources/survey_design.pdf.
[Hämtad: 6 maj 2014].
Oppenheim, A. N. Questionnaire design, interviewing and attitude measurement, New
edition, Continuum, London and New York, 2001.
Stukát, S, Att skriva examensarbete i utbildningsvetenskap, upplaga 2, Lund:
Studentlitteratur AB, 2011.
E. Gotab, Forskningsetiska principer: inom humanistisk-samhällsvetenskaplig
forskning, Sverige: Vetenskapsrådet, 2002.
Thought Works. “Continuous Integration”,
http://www.thoughtworks.com/continuous-integration. [Hämtad: 1 aug 2014].
Quyen L, Nguyen. “Non-Functional Requirements Analysis Modeling
for Software product Lines”, MISE, 2009, s. 56-61.
E. Folmer, J. Gurp, J. Bosch. “Software Architecture Analysis of Usability”,
Berlin Heidelberg: Springer-Verlag, 2005.
G. Verheugen. Den nya definitionen av SMF-företag: Användarhandbok och mall för
försäkran, EU: Europeiska kommissionen 2006.
E. Folmer, J. Gurp, and J. Bosch. “Scenario-based assessment of software
architecture usability”: In Proceedings of Workshop on Bridging the Gaps Between
Software Engineering and Human-Computer Interaction (SE-HCI). IFIP, 2003, s. 61–68.
Bass, L; Clements, P.; Kazman, R. Software architecture in practice , 3 uppl, Upper
Saddle River NJ: Addison-Wesley, 2012.
J. Sauro, “Measuring Errors in the User Experience”, Measuring U, Maj 15, 2012,
http://www.measuringusability.com/blog/errors-ux.php. [Hämtad: 5 sept 2014].
J. Sauro, “Measuring Usability Average Task Times in Usability Tests:
What to Report?”, Measuring U, April 21, 2010,
http://www.measuringusability.com/average-times.php. [Hämtad: 4 sept 2014].
Sida | 68
[49]
[50]
Khushboo. S, Kishore. M. N, “Continuous Integration Using Team Foundation Build”
Microsoft Developer Network, Microsoft Corporation, jan 2006,
http://msdn.microsoft.com/en-us/library/ms364045(v=vs.80).aspx. [Hämtad: 1 aug 2014].
T. Krishnan, “Continuous Integration & Hudson”, Slideshare, May 03, 2010,
http://www.slideshare.net/thyagk/continuous-integration-system.
[Hämtad: 23 mar 2014].
Sida | 69
Bilaga 1
2014-10-14
Historical background
© 2014 Edument AB. All Rights Reserved
Continuous Integration
&
Deployment
System Development Methods
Kent Beck
Martin Fowler
In 1997, have Kent Beck and a team of developers at
Chrysler Comprehensive Compensation (C3) project,
invented Extreme Programming (XP). [1]
Martin Fowler said: “This was my first chance to see
Continuous Integration in action with a meaningful
amount of unit tests”.[2]
System Development Methods
The most pupular traditional sequential methods in
system development:
Ian Sommerville
Development methods is a must to manage
and improve development process in any
organization working with system
development.[3]
Waterfall Method
Waterfall method is an old method of those
traditional sequential methods.[3]
In which the work process is flowing downwards
• Waterfall method
• Agile method
• Extreme programming
Agile methodologies
Agile is a newer approach of those traditional
sequential methods and a generic term for
several development methods.
.
1
2014-10-14
Agile Development Methodology
Agile changed the way devlopers organize
their work. With Agile developers analysis,
designs, builds, and tests depends on
pruduct’s requirements.
Continuous Integration (CI)
"Continuous Integration originated with the Extreme
Extreme Programming (XP)
XP is one of Agile software development methods.
It was developed to handle the needs of software development. It
performed by teams of few developers to be commensurate with the
changing requirements. [1]
What is CI?
Definition 1
Programming development process, as one of its original
twelve practices” [2].
What is CI?
Why CI ?
Definition 2
A developers goal is to create perfekt applications
with less time and work as possible. Reaching this
goal is not easy now, because the applications are
getting more complex and consists many parts. [5]
2
2014-10-14
One of the most important
keys to improving applications
and streamline the work is to
automate som parts of the
work that are possible to
automate. [5]
One of the best ways to
automate som of the work is
to implement
Continuous integration (CI) [5]
Reasons of using CI
• Reduce risks: Bugs and problems can be detected
and solved earlier by implementing a
CI-system, because the testing
and integration is already
done earlier in the
developementprocess. [5]
Reasons of using CI
•
Deployable software:
To make sure that the
developed software will work
as expected the installation
process has to be automated. [5]
Which leeds to bettersoftware.
Reasons of using CI
• Increase project visibility:
Project members’ll get better
control over the project because of
the feedback mechanism, which
allows them to see the final results
and place of errors to be fixed. [5]
Reasons of using CI
• Fast incremental builds: CI provides faster build, test
and feedback which helps developers to finde bugs
and errors earlier in the development process. [5]
3
2014-10-14
Frequency of performing builds
0% 0%
21%
79%
CI-Tools
Essential CI-Tools
The quality of a CI-system depends on tools that the
system contains. We can either buy an expensive CIsystem that is feature-proof and often easy to use, or
we can choose a CI-system that is less future-proof and
often require more work before it can be used, but are
almost for free or low cost. [5]
• Helps developers to revert the codebase to
a bug-free state in case of build fail, unittest
fail or bugs detection.[5]
Advantages with CI-system
Other
Stable
Reliable
Low cost
Fast
Easy to troubleshoot
Ease of use
None
0
Responses
5
Ease of use
0
23
Easy to
troubleshoot
15
10
15
• Source code control
• Continuous integration
server
• Feedback mechanism
• Build manager
• Unit test framework
• Code analysis tool
• Testing tools [5]
CI-Advantages
Advantages with CI-system
None
Continuously
Daily
Weekly
Monthly
20
25
Fast
Low cost
Reliable
Stable
Other
7
14
16
19
10
• Fixing integration and problems
continuously avoids last-minut stress of
releasing data.
4
2014-10-14
CI-Advantages
CI-Advantages
• Early warning when the code is broken or
incompatible
• Povides fast feedback to developers about code
quality and functionallity.
• Early warning when detecting incompatible
changes on the code
• Frequent controll on the code helps developers
to create better and less complex code.
• Makes the current build available all times
so that developers can test, demonstrate, or
release the build.
• Metrics that developers get from automated
testing helps developing good quality and
functionality code.
• Provides fast unit testing of all changes
CI-Disadvantages
CI-Disadvantages survey
• Some developers complaining that Continuous
Integration causes kind of bottleneck at the work
because of the hard roles. [5]
Disadvantages with CI-system
Other
Unstable
Unreliable
High cost
Slow
Difficult to troubleshoot
Difficult to use
None
0
None
Responses
20
5
Difficult to
Difficult to
troublesho
use
ot
1
4
10
Slow
1
15
20
High cost Unreliable Unstable
4
1
25
Other
3
6
CI-Disadvantages
• Increment of maintenance and hardware costs. [6]
• Experience for the first-time setup required.
• It requires speciell software to get best results.
• CI causes a backup because developers cannot check
in code that is not completed.
Advantages VS Disadvantages
Most developers who use CI believe that the
advantages of using CI will covers the disadvantages.
Because they will save both time when they find and
fix integration problems earlier in the development
and they will save money when they complete the
project earlier. [6]
5
2014-10-14
CI-Workflow
” In the CI process, developers check code into the version control
repository. The automated CI system polls the repository for changes
and then builds and tests the code. Results are posted to a feedback
system where the team members can see the results” [5].
Manual Build & CI-server
Manual Build
Here the developer has to check out the head of
the mainline in the integration machine where he
now can find his last checkin. He then starts the
integration build , and wait for results. He’ll be done
with his commit if the buid succeed. [2]
Why manual build?
Doing time schedule buildings, like every night or in
specific time doesn’t means that it’s continuous build
not either Continuous Integration because the main
point with continuous integrations is to detect and fix
bugs and problems as soon as possible. [2]
James Shore
A schedule build like every night means that bugs and
problems will lie undisconverd in the system for a long
time and that will take more time to detect and remove
them. And this is contrary to the principle of
Continuous Integration. [2]
Why manual build?
• It’s easier and faster to detect and fix the
problem by using manual build .
The problem will be one of 3 things if
something goes wrong.
- your own code
- Integrations with someone else code
- Enviromental changes. [7]
• “The code in revision control always builds
and passes tests. Period”. [7]
Why manual build?
• We do not need to fix somebody else's
mistakes or broken build due to
negligence.
• Manual build leeds to better test and
better design because it’ll keep your
build times down and avoids long
integrations.
6
2014-10-14
CI-Server
It acts like an observer to the repository
because as soon as the repository finishes a
commit, the server will send the source
automatically onto an integration machine to
start the build and then send feedback to
developer by e-mail, SMS or dashboard. [2]
CI-Benefits
•
•
•
•
•
•
•
•
No more long integrations [8]
Better communication
Increase project visibility
Detect bugs and problems faster
Saving alot of debugging time
Enhance confidence and improvement
No more worrying about not working codes.
Faster software delivery by reducing integration
issues
Why CI- Server?
CI-Server is a helpful tool according to developers
who are using it. [2]
for example CI server’s web pages provides:
• An indication of who is building.
• What changes made.
• History of changes.
• Last activities on the project.
• Control of what developers have been doing.
• Get a sense of the project's status.
CI-System Practices
Continuous Integration system has many
practices. And the best ten practices
according to Martin Fowler are: [2]
1. ”Maintain a Single Source Repository”[2]
which can be demonstrated in several stages:
• A clean machine should be able to fully build your
application without external dependancies.
• Make sure to use a source code management
system, also make sure everyone uses the
repository to checkout and commit their code to.
• Do not store actual build artifacts such as binaries
or executables.
• Store everything you need in the repository to
fully build your application including source code
but also test scripts, properties files, install
scripts, third party libraries, IDE configurations.
• Branching is a feature of source code
management systems, but make sure you use it
to a bare minimum. Make sure everyone works
off the mainline and frequently integrates their
changes into mainline.
7
2014-10-14
2. ”Automate the Build” [2]
Going from source code compilation to run time
execution can be a complicated process and
shouldn't be handled manually by developers as
the process is prone to human errors and can be
automated.
3. ”Make Your Build Self-Testing” [2]
Traditionally, building an application means
compiling, linking and executing code, omitting the
process of testing the code for bugs.
While IDEs can catch obvious bugs through static
analysis many slip through the net.
A good way to add another level of error detection is
to include automated tests in the build process.
Make sure to include everything in the automated
build. Going back back to (1), nothing else should be
required from a clean machine to fully build the
system.
Make sure your build tool can analyze what needs to
be built and customize the build according to the
changes that have been made, no need to rebuild
everything from scratch if a minor change was made.
For self-testing code to be useful you need to write a
whole suite (a bunch of) automated tests that cover a
large part of the code base (high code coverage).
Going back to (2), the whole suite of tests needs to be
able to trigger from a simple command.
For a build to be self-testing the failure of a test
should cause the build to fail.
4. ”Everyone Commits To the Mainline Every Day”[2]
Of course, tests can't find everything and poorly
written tests can't detect the presence of bugs.
However, having imperfect tests run frequently is
preferred over perfect tests that are never
written at all.
Integration is primarily about communication.
Frequent integration allows developers to quickly
notify their team about changes of the project.
Of course, there are prerequisites for the developer
before a commit to the mainline should be made.
8
2014-10-14
The developer needs to update their working
copy to match the mainline (other developers
may have made changes since the last
checkout), resolve any conflicts and make sure
that his code builds locally without errors,
including passing tests. Only then is he free to
commit to the mainline.
By being engaged to this practice, developers
quickly identify conflicts within the project. Conflicts
that stay undetected for weeks can be very hard to
resolve.
A series of errors can be detected early and
resolved, such as compilation conflicts and textual
conflicts. Even bugs can be detected that would
otherwise occur as a result of lack of integration.
It is advized that developers commit to the repository
at least a day, preferably several times a day.
The more frequently your team commits, the easier it
is to identify and resolve errors.
Furthermore, breaking down a days of work into small
chunks of a few hours helps track and provide a sense
of progress.
The regularity of commits can help project managers
to track progress with KPI.
5. ”Every Commit Should Build the Mainline on an
Integration Machine”[2]
Every time a developer commits his code, the CIsystem should trigger a build of the mainline.
6. ”Keep the Build Fast”[2]
The developer who commits needs to monitor the
mainline build so it can be fixed if it breaks.
He's not done until the CI system is done building
and testing the latest revision of the code.
Practically impossible if building takes a lot of time,
more about this in (6).
The whole point of CI is to provide rapid feedback. This
can only be enforced by optimizing the build process, as
a long build can become a bottleneck, disrupting the CI
process and wasting precious development time.
The build time relies on the complexity and scope of the
project. The XP guideline of a ten minute build is within
reason.
9
2014-10-14
Concentrated effort should be put in to optimizing the
build process as every minute reduced off the build
time is aminute saved every time a developer commits
,which could add up to a lot of time!
A solution to this problem is setting up a deployment
pipe (aka. build pipeline or staged build)
which basically means that the ”monolithic big
bang” build will be separated into several stages.
For more complex projects, the usual bottleneck lies in
the testing phase.
More so when tests involve external services
such as databases.
The first stage build will be called the commit build.
During this stage only the highest priority tests
will be run, to ensure a good balance between
code coverage and build time.
Once the first stage build is successful developers can
resume development of the system.
Meanwhile further thorough tests can be run
”in the background” which leads us to the
second stage build.
The suite of tests that is run during the second
stage buildis more encompassing and involves
testing of endto end behavior, thus it might take
a couple of hours to run.
With the first stage build having compiled and
run localized unit tests (where external services
are comitted), the secondstage build run tests
that involve larger scale interactions.
Builds performed after the initial commit build are
said to contain ”pure tests” as they thoroughly
investigate for errors that are not detectable in
the commit build.
Whenever bugs are detected in stage builds
subsequent to the commit build, developers try
to adapt or introduce new tests to the commit
build, to assure that the bug stays fixed in the
commit build if it should reappear at later releases.
The second stage build runs whenever higher
priority tasks are not run and picks up the latest
stable commit build for further testing.
The example of the two stage pipeline is used for
explanatory purposes. In practice, any number of stages
can be used in a deployment pipeline.
Furthermore, builds subsequent to the commit build can b
e parallelized and the workload may be distributed
and scaled over a large number of machines.
By distributing the workload of later build stages, it is
possible to introduce further automated testing without
sacrificing the need for a fast building of the commit build.
10
2014-10-14
7. ”Test in a Clone of the Production Environment” [2]
The whole point of testing is of course to detect and
resolve any issue that the system would have
in production (the environment where customers
use the system).
Issues may arise if the production environment is
significantly different from the development and tes
ting environment.
In practice, it may be hard to replicate the production
environment. For example if you're writing
desktop software it's virtually impossible to test
your system in every kind of environment running
various third party software.
The developer should however be aware that
Every difference in the test and production
environment poses a risk and may potentially
be a source of error.
8. ”Make it Easy for Anyone to Get the Latest Executable”[2].
Agile development of software addresses one of the
most difficult parts of software development:
How do we build the right software for the customer?
It's often very hard for the customer to specify
what he wants in advance, it's much easier to
point out what needs to be fixed or changed.
Ideally, the same version of the database software is
running under the same version of operating system
in the two environments.All libraries that are present
in the production environment should also be present
in the test environment. The same IP addresses and
ports should be used, running on the same hardware
and platform, etc.
Virtualization is a great way to put together test
environments as everything can be saved into the
virtualization. Virtualization also allows for running
of multiple tests on one machine or even simulation
of multiple machines in a network on a single
physical machine.
For this purpose, everyone involved with the proj
ect including the customer should with ease be
able to get hold of the latest stable executable.
Make sure there's a place where people involved
with the project have access to and can get hold
of the latest stable executable.
Preferably, also make sure that previous stable
executable are available.
11
2014-10-14
9. ”Everyone can see what's happening” [2]
As mentioned in (4), (Continuous) Integration is
Primarily about communication.
Make sure everyone can easily see the state of the
system and recent changes that have been made.
The state of the mainline build is one of the most i
mportant things to communicate, it's important
that everyone is on the same page.
Some CIsystem software offer dashboards that
display if there's a build in progress and the state
of the most recent mainline build.
Furthermore, CIsystem software can provide
more details about these events.
Often times, team leaders are interested in this
kind of information to get a sense of who's
being active and to keep an overview over the sta
te of the system.
Another advantage with dashboards is that
Peripheral people that are not co-located with
The main team of developers can from a remote
location get a sense of the project's status.
Many teams are not content with a dashboard, instead
hooking up various ”build sensors” such as light display
sand lava lamps with red and green colours indicating
stable or broken states of the mainline build.
Yet another advantage is that dashboards can be
used to aggregate build information and project
status of several different projects, thus providing
a centralized place where this information can be
viewed.
But CI-systems aren't necessary to enforce this
practice.
Unique physical tokens such as rubber chickens or
toys may be passed around the office to indicate
what developer in a team is doing the current build.
10. ”Automate Deployment”[2]
In other cases, aural signatures, such as ringing a
bell, are used to communicate the status of builds.
Regardless of how teams choose to communicate,it'
s very important that the state of the mainline
build is communicated in a clear way and that
this information is readily available to anyone
involved in the project!
As previously mentioned, usually several environments
are used during development of software at
enterprise level.
Since executable are frequently moved between
These environments, it's preferred to automate
the deployment process.
This is made possible and can be simplified and
automated with scripts.
12
2014-10-14
Of course, this also means that deployment into
Production should be automated and possible
to do with ease.
While it is true that deployment into production is
not something that every development team will
want to do every day, a routine for doing this
should nevertheless be set up to assure that this
process is easy to set in motion once it's needed
and that deployment to production can be done
quickly.
As well all know, bad things happen and if worst
comes to worst, and a critical bugs are found in the
production environment it's good to be able to
quickly revert to the last known stable state.
Automated rollbacks also reduce tension in the team
regarding deployment, encouraging developers to
deploy more frequently at lower risk ofcritical failure,
meaning new features get released quicker!
This allows developers to test out new features,
fixes and changes in a smaller scale before fully
deciding on whether to keep the changes or discard them
Another benefit of automated deployment is as
with other forms of automation, the reduced risk
of human errors.
It's a cheap practice to utilize as it uses the same
capabilities as mentioned in (6).
Another capability that should be considered is
Automated rollback.
Automated deployment can even be taken one
step further!
The practice of deploying a trial build with the lat
est features and fixes to a subset of users allows
the development team to see the impact of the
latest changes before gradually rolling the latest
build out to the entire user base.
How To Du It?
According to (thoughtworks)[8]
• Developers have to check out their code into
their own workspaces.
• Developers have to commit changes they have
made to the repository.
• The CI server monitors the repository and checks
out changes when they occur.
• The CI server builds the system and runs unit and
integration tests.
• The CI server releases deployable artefacts for testing.
• The CI server assigns a build label to the version of the
code it just built.
• The CI server informs the team of the successful build.
• If the build or tests fail, the CI server alerts the team.
• The team fix the issue at the earliest opportunity.
• Continue to continually integrate and test throughout
the project.
13
2014-10-14
Team responsibilities
It’s important that a team developers have some kind
of policies to follow, when working with Continuous
Integration. Policies that let teams having better
control and manage on themselves, to complete the
work successfully. [8]
CI- Team Objections And Solutions
When the job increases, developers have to change
the style of their work to fet the new situation. This
can lead to objections from some team members
that working with Continuous integration like the
following: [5]
CI- Team Objections And Solutions
Objection:
• It’s difficult for developers to follow up the
continuous and very fast changes. [5]
Solution:
• It’ll be easier to follow up if dovelopers start out
with a simple build a day, and increase it later on
when they feel that they can.
Team responsibilities
(thoughtworks)[8] have explained some
polices that developers have to follow:
•
•
•
•
•
”Check in frequently
Don’t check in broken code
Don’t check in untested code
Don’t check in when the build is broken
Don’t go home after checking in until the
system builds” [8]
CI- Team Objections And Solutions
Objection:
• CI brings additional tasks to developers like CIsystem setup and maintainance and this will take
them away from the main task. [5]
Solution:
• Developers will save much more time when the
systen is fully integrated because they will be
able to build code, test code and fix bugs earlier
and faster . [5]
CI- Team Objections And Solutions
Objection:
• CI requires additional expenses when it comes to
hardware and software costs. [5]
Solution:
• You can actuelly start out with old equipments lik an
old PC as your CI server and so on. [5]
14
2014-10-14
CI- Team Objections And Solutions
Objection:
• Developers have to compile and test their code.
Solution:
• Compiling and testing helps developers to use their
brains to solve application problems. But CI
automates much of the work process. [5]
Objection:
• It takes along time before a CI-system can be
included into the project. [5]
Solution:
• You’ll be able to use som of CI-tools no matter
how much time your project needs to use CI. But
the easier and better way to do that is by creating
the new project under CI process. [5]
Size of the company that using with CIsystem
CI and type of business
5% 5% 0%
3%
CI- Team Objections And Solutions
Administration
13%
Computer / IT
Technology / Science
74%
21%
50%
29%
Economy / Finance
Logistics / Transport
Other
Percentage of developers uses or affected by
the CI-solution
18
Company's performance after using
CI-system
0%
16
Small (up to 50
employees)
Medium (50 - 250
employees)
Large (over 250
employees)
3%
14
Percentage (1=10%,
5=50%, 10=100%)
12
10
8
6
Responses
4
Worse performance
No change
97%
Better performance
2
0
1
2
3
4
5
6
7
8
9
10
15
2014-10-14
Continuous Delivery
Continuous Delivery (CD)
"Continuous delivery is a series of practices
designed to ensure that code can be rapidly
and safely deployed to production by
delivering every change to a production-like
environment”. [9]
“For many organizations Continuous Delivery
isn’t just a deployment methodology, it’s critical
to doing business” [10]
CD- Survey
CD- Benefits
Som of CD benefits are the following: [12]
• Delever most important changes and
improvements faster.
• Ability to release in high quality and usability.
• Ability to increase development team in a
continuous process by skipping batch processes.
When to use CD?
CD- Benefits
• Save money and time by eleminating batch
process.
• Developers have more time to think and
complete the work.
• Developers work in low stress condition.
• Improve cooperation between development and
operations
Continuous Delivery should be used when: [12]
•
•
•
•
•
Having online service
Having longer release time
Having a new product to develope
Having a big project with many contributors
Having to release security patches frequently
16
2014-10-14
CD- Practices
CD- Practices
Som of CD practices: [13]
1. Manage and version controll your code and include
everything like documents, configuration parameters,
databases.
2. Automate everything that make sense to you like
unite testing, integration testing, regression testing.
3. Automate your deployments.
Continuous Deployment
4. Fix the problem that you get probably at it’s root
and follow the process again from the beginning.
5. Allocate some time for frequent maintenance
and improvment if you want to reach the benefits.
6. Decide a clear process and let your teams
follow it, everyone should cooperate to get CD
started, and to keep it going.
Continuous ( Delivery VS Deployment)
1. Deliver every change of code to an environment
continuously to be tested automatically. [15]
Jez Humble
According to (Jez Humble) who is the author of
Continuous Delivery.
“it is the practice of releasing every good build to
users” [14]
2. “Then every change that passes the automated tests
is deployed to production automatically.” [15]
Continuous Improvement
Continuous Improvement
“A process based on continuous improvement is essential to
the rapid delivery of quality software. “ [14]
“Continuous improvement is an ongoing effort to
improve products, services or processes. These efforts
can seek “incremental” improvement over time or
“breakthrough” improvement all at once”. [16]
17
2014-10-14
Continuous improvement tools
Four-step quality model or plan-do-check-act (PDCA)
cycle is the most used tool for continuous
improvement. It’s also known as Deming Cycle or
Shewhart Cycle: [16]
What PDCA- cycle means?
“Plan: Identify an opportunity and plan for change.
Check: Use data to analyse the results of the change
and determine whether it made a difference.
Do: Implement the change on a small scale.
Act: If the change was successful, implement it on a
wider scale and continuously assess your results. If the
change did not work, begin the cycle again”. [16]
Continuous improvement methods
There are many methods for continuous
improvement. But the widely used methods are
Six Sigma, Lean, and Total Quality Management .
All of them are found to enhance teamwork,
employee involvement, systematize processes and
reducing defects, variation and cycle time. [16]
(Continuous and Continual) Improvement?
“The terms continuous improvement and continual
improvement are frequently used interchangeably.
But some quality practitioners make the following
distinction”. [16]
(Continuous VS Continual) Improvement
“Continual improvement: a broader term preferred by
W. Edwards Deming to refer to general processes of
improvement and encompassing “discontinuous”
improvements that is, many different approaches,
covering different areas.
Continuous improvement: a subset of continual
improvement, with a more specific focus on linear,
incremental improvement within an existing process.
Some practitioners also associate continuous
improvement more closely with techniques of statistical
process control”. [16]
David Bolton
“A Version Control System (VCS) is an application,
desktop or web-based that lets developers keep
their source code and binary and resource files
stored away along with information about
different versions” [19]
18
2014-10-14
Version Control
Why Version Control?
”The simplest way to explain Version control is that
it's used to keep a repository of your project files
together with a history of all your code changes in
one place. This allows the developers of the project
to track every change made to the code, who made
the change and the reasons for the code change.”[20]
”Version control is essential when working with a team
of developers.
• Using version control will allow multiple developers to
work on the same file at the same time.
• If you were using version control you could just revert
your code back to before you started developing that
feature.” [20]
Why Version Control?
Version Control Options
• ”Version control will record who wrote a piece of
code.
• Version control is also a good way to keep your
code shared on multiple computers.
• Tagging is an important feature you need to take
advantage of when working with version control.
When you have completed a piece of work and
ready to deploy the code, you then tag this version
of the code.” [20]
SVN
”SVN or Subversion: Is very popular due to the fact
that it's very easy to understand and very straight
forward to work with. The WordPress plugin
repository uses SVN. It works by having a central
server for your repository, this repository is split into
3 key areas...Trunk, Branches and Tags. Each one of
these areas have an important role to play. ” [20]
”There are many different types of version control,
here we are just going to look at the two most
popular version control repositories, Git and SVN.” [20]
GIT
”At the moment GIT is probably the most popular
version control which is aided by the popular
websiteGithub. Like I said before GIT and SVN are
quite similar but the workflow is a bit different.
SVN has one central repository, but GIT has
multiple repositories, one central repository but
each developer has their own repository.” [20]
19
2014-10-14
Software configuration management (SCM)
SCM Best Practices
”Using a SCM System To:
•
•
•
•
•
•
•
Jacky Estublier
“SCM is the control of the evolution of
complex systems,…, for the purpose to
contribute to satisfying quality and
delay constraints.” [17]
Store and version all source code
Utilizing private developer workspaces
Third-party libraries
Properties files
Database schema
Test scripts
Install scripts” [18]
Best Practice
CI- Servers Comparison
Name
”Utilizing Private Developer Workspaces
•
•
•
•
Work in isolation
Revert to known “good” states when needed
Checkpoint their changes
Share only mature, well-tested code with other
team members” [18]
Platform
License
Windowsbuilders
Javabuilders
MSBuild,NAnt,
Visual Studio,
Duplicates finder
for .NET
Ant, Maven 2/3,
IDEA .ipr based,
IDEAInspections,
IDEADuplicates
finder,Gradle
TeamCity
Servlet Container
Proprietary
Team
Foundation
Server
Windows,VSTM
Proprietary
MSBuild
Ant, Maven
Shippable
Hosted
Proprietary
MSBuild, NAnt
Ant, Maven,
Gradle
QuickBuild
Cross-platform
Proprietary
MSBuild,NAnt,
Visual Studio
Ant, Maven 1,
Maven 2
Creative
Jenkins/Hudson Servlet Container Commonsand
MIT
MSBuild, NAnt
Ant, Maven 2
, Kundo
Other.Builders
Notification
Rake, FxCop,
Command Line
E-mail, XMPP,
RSS, IDE,
SysTray
Custom script,
Command line
E-Mail, SOAP
Ruby, Python,Node.js
E-mail, Campfire
,Java,Scala,C Sharp
Rake, Shell script,
Command Line
E-mail, XMPP,
RSS, GoogleTalk,
Remote API
Grails,Phing,
Android, Email,
Rake,Ruby, Cmake, GoogleCalendar,
Gradle, SCons,Python
IRC,XMPP,
Shell script, Gant
RSS, witter
IDEIntegration
Eclipse, Visual
Studio, IntelliJ
IDEA, RubyMine,
PyCharm,
PhpStorm
,WebStorm
Integration
Jetbrains
Youtrack, JIRA,
Bugzilla,FishEye,
FindBugs, PMD,
dotCover,NCover
Visual Studio,
Eclipse
Unknown
No
GitHub, Heroku
Eclipse,
IntelliJ IDEA,
Visual Studio
JIRA
Eclipse,
IntelliJIDEA,
NetBeans
Bugzilla,
GoogleCode,
JIRA,Redmine,
Mantis, Trac
CruiseControl
Cross-platform
BSD-style
NAnt, Rake,
and Xcode
Apache Ant,
Phing, Maven
catch-all 'exec'
E-mail, CCTray
Eclipse
Unknown
Bamboo
Servlet Container
Proprietary
MSBuild,NAnt,
Visual Studio
Ant, Maven 1,
Maven 2,Maven 3
custom script,
command line,
Bash
XMPP, Google
Talk, Email,RSS,
Remote API
IntelliJIDEA,
Eclipse,
Visual Studio
FishEye,Crowd,
JIRA,Clover
AnthillPro
Cross-platform
Proprietary
Shell script,
Batch script,
Cross-platform
commandline,
Groovy script,Make,[6]
RTC Jazz,[7]
TFS Build[8]
Email, XMPP
,RSS, Systray
Eclipse,
Visual Studio
(many)[9]
MSBuild,[1]NAnt,[2 Ant,[4]Maven 1, 2,
]
Visual Studio[3]
& 3[5]
Refrences
References:
[1] Kent Beck. ” Extreme Programming Explained”: Embrace change, U.S, 1999.
[2]Martin. Fowler, “Continuous Integration”,
http://martinfowler.com/articles/continuousIntegration.html [e- resurce], 2006
[3] Ian Sommerville,”software Engineering”, Ninth Edition, Addison-Wesley , 2011.
[4] Duvall, Paul ; Matyas, Steve; Glover, Andrew. “Continuous integration”: improving
software quality and reducing risk, Saddle River, NJ, 2007.
[5] K.Marcin ; B.Craig, “Continuous Integration in .Net” [e-book], 2011
[6] V.Bakhov, “ Continuous Integration For Database Development” [e-resurce], 2011
[7] James Shor, “ The Art Of Agile”, http://www.jamesshore.com/Blog/ContinuousIntegration-on-a-Dollar-a-Day.html e- resurce. 2007
[8] http://www.thoughtworks.com/continuous-integration
[9] Yuli Deng,”Continuous Delivery Software Developing System On Vlab Platform”, Arisona
State University, 2013
[10] James, Turnbull, http://www.jamesturnbull.net/
[11] http://www.continuousagile.com/unblock/cd_costs_benefits.html
[12] http://www.continuousagile.com/unblock/cd_costs_benefits.html
[13] http://www.dbmaestro.com/2014/04/six-top-tips-for-continuous-delivery/
[14] J. Humble; D. Farley.” Continuous Delivery”: Reliable Software Releases Through Build,
Test, And Deployment Automation, Addition Wesley, 2010
[15] http://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff
[16] http://asq.org/learn-about-quality/continuous-improvement/overview/overview.html
[17] Jacky Estublier.” Software Configuration Management: A Road Map”, Proceedings of the
Conference on The Future of Software Engineering, USA 2000.
[18] http://www.accurev.com/whitepaper/pdf/scm-continuous-integration.pdf
[19] http://cplus.about.com/od/glossar1/g/versiondefn.htm
[20] http://agile.dzone.com/articles/version-control-git-vs-svn>
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Slide 2: Kent Beck: http://blog.trifork.com/2012/12/07/goto-night-12-12-12-and-breaking-news/
Martin Fowler: http://bzmedia.com/agility/
Slide 3: Ian Sommerville: http://www.scotlandis.com/about-scotlandis/meet-the-board/biographies
Slide 4: http://zenexmachina.wordpress.com/2013/04/03/prince2-processes-vs-agile-development-methodologies/
Slide 5: http://www.creativebloq.com/design/new-design-methodologies-10125997
Slide 6: http://id.wikipedia.org/wiki/Berkas:Agile_Method.jpg
Slide 7: http://www.arieon.com/products.html
Slide 8: http://xprogramming.com/what-is-extreme-programming/
Slide 9: http://blog.smartbear.com/codereviewer/the-value-of-continuous-integration-at-smartbear/
Slide 10: Martin Fowler: http://martinfowler.com/bliki/
Slide 11: Paul Duvall: http://research.gigaom.com/analyst/paul-duvall/
Slide 14: https://danceclasschallenge.files.wordpress.com/2013/02/i-get-it.gif
Slide 15: http://www.easierliving.com/blog/2012/06/05/prepare-for-care-reducing-the-risk-of-stroke/
Slide 16: https://keystonebytes.com/remote-services-s/software-install
Slide 17: http://socialmediatoday.com/amanda-ryan/951776/visibility-equals-credibility
Slide 18: http://www.tutorialspoint.com/sdlc/sdlc_iterative_model.htm
Slide 19: http://zeroturnaround.com/rebellabs/the-build-tool-report-turnaround-times-using-ant-maven-eclipse-intellij-and-netbeans/
Slide 22: http://zeroturnaround.com/wp-content/uploads/2013/08/CI-ecosystem-diagram.jpg
Slide 24: http://www.lofric.com/en/UrinaryHealth/Problems-due-to-illness-or-injury/Strictures/Advantages-of-CID
Slide 28: http://www.lofric.com/en/UrinaryHealth/Problems-due-to-illness-or-injury/Strictures/Advantages-of-CID
Slide 31: http://www.programmingresearch.com/products/continuous-integration-jenkins-plug-in/
Slide 34: James Shore: http://www.agilebrazil.com/2012/en/programacao/convidados/james-shore/
Slide 91: James Turnbull, http://www.jamesturnbull.net/
Slide 93: http://blog.cloudbees.com/2014/05/the-business-benefits-of-continuous.html
Slide 99: Jez Humble, http://www.oreilly.com/pub/au/5712
Slide 100: http://www.tryerr.com/2014/01/from-release-testing-to-continous.html
Slide 101 http://www.soltiusme.com/soltius/services/continuous-improvements
Slide 103 http://maaw.info/Chapter8.htm
Slide 108: David Bolton: http://cplus.about.com/od/glossar1/g/versiondefn.htm
Slide 115 : J. Estublier: http://arnetminer.org/person/j-estublier-312866.html
Slide 118: http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
20
2014-10-14
© 2014 Edument AB. All Rights Reserved
Introduction
CI-server software are used to enforce and
support Continuous Integration.
Continuous Integration
with TeamCity
Introduction
Installing TeamCity
TeamCity is a popular CI-server software
developed by JetBrains.
In this presentation we explore TeamCity and
learn how to use it.
Installing TeamCity
Installing TeamCity
Installing TeamCity
Download TeamCity from
http://www.jetbrains.com/teamcity/download/
We will look at TeamCity 8.1.1 in this presentation
but make sure you download the latest version for
your personal or business use.
Choose the features that you want installed.
1
2014-10-14
Installing TeamCity
Choose the server port that you want TeamCity to use.
Installing TeamCity
Configure Build Agent properties.
Installing TeamCity
Installing TeamCity
Specify which user will be running the TeamCity Server
service.
Specify which user will be running the TeamCity Agent service.
Starting up and accessing TeamCity
Starting up and accessing TeamCity
Starting up and accessing TeamCity
Now that you have installed TeamCity,
let’s start it up and access it through the web
browser.
2
2014-10-14
Starting up and accessing TeamCity
Run the “runAll.bat” batch file with the “start” switch to start the
TeamCity Server service.
By default, you can use the following command:
C:\TeamCity\bin\runAll.bat start
Starting up and accessing TeamCity
Starting up and accessing TeamCity
Access the setup instruction page by typing in the IP adress
and port of the TeamCity server machine (“localhost” in our
case).
Setting up TeamCity after installation
Setting up TeamCity
after installation
TeamCity should be up and running constantly, however if you
wish to shut TeamCity down then do the following:
Run the “runAll.bat” batch file with the “stop” switch to stop the
TeamCity Server service. By default, you can use the following
command:
C:\TeamCity\bin\runAll.bat stop
Setting up TeamCity after installation
Setting up TeamCity after installation
In order to run TeamCity,
we need to connect it to a database.
Verify the location of the data directory.
3
2014-10-14
Setting up TeamCity after installation
Setup your connection to your database of choice (we’re using
MySQL).
Setting up TeamCity after installation
If the MySQL JDBC driver is not found in your environment,
make sure you download it.
Setting up TeamCity after installation
Setting up TeamCity after installation
Once downloaded, move the .jar file containing the driver to the
TeamCity /lib/jdbc folder.
Click on the “Refresh JDBC drivers” button and make sure
TeamCity loads the driver correctly.
Setting up TeamCity after installation
Setting up TeamCity after installation
Fill in the rest of the fields in the form in order to establish a
connection to your database.
Make sure a database is set up prior to filling out the form, the
following statement may be used on your MySQL control panel
to create a TeamCity compliant database.
4
2014-10-14
Creating a user account for TeamCity
Creating a user account for TeamCity
Creating a user account
for TeamCity
In order to log in and interact with TeamCity,
you need to set up a user account.
Creating a user account for TeamCity
Creating a user account for TeamCity
Access the “Create Administrator Account” page by navigating
to the localhost/setupAdmin.html page.
Fill in the username of the administrator and the password.
Overview of TeamCity
Overview of TeamCity
Overview of TeamCity
Now that we can log in to TeamCity as an
admin user, let’s take a look at the different
sections of TeamCity and what they do.
5
2014-10-14
Overview of TeamCity
The first page that you’re presented with is the “Overview
page”, also known as the “Projects page”.
You have an overview of all projects from this page.
Overview of TeamCity
This is the “Agents” page.
This page provides an overview of Build Agents. You can view
properties of Build Agents here or set up new Build Agents.
Overview of TeamCity
This is the “Changes page”.
VCS changes (changes committed to the repository) are
displayed on this page.
Overview of TeamCity
This is the “Build Queue page”.
Builds that have been triggered (and scheduled) will queue up
and be listed on this page.
Overview of TeamCity
Overview of TeamCity
This is the “User Settings page”.
You can set up your TeamCity profile and user-specific settings
on this page.
This is the “Administration page”.
Only a user with administrative privileges will be able to access
this page. A wide range of global and project-specific settings
can be accessed and changed from this page.
6
2014-10-14
Setting up a sample project
Setting up a sample project
Setting up a sample project
Now that we have taken a look around
TeamCity, let’s set up a sample project that we
can work with.
The sample project will be a Java-project, being
built with an Ant build script and tested with
the JUnit unit testing framework.
Setting up a sample project
Setting up a sample project
Here’s an overview of our project.
We have 2 Java-classes and a JUnit test class.
We also have a custom build script which we will be using.
Setting up a sample project
Demo02.java is also a demonstration of a functional class. It’s
included in this project to show that a project may of course
consist of more than 1 class.
Demo01.java is a demonstration of how what a functional class
in a Java project can do. It has 2 methods that concatenate a
string and calculate a sum.
Setting up a sample project
Test01.java is a JUnit test class that consists of a test suite
containing 2 test cases. Each test case tests the 2 methods of
Demo01.java: demoStringConcatenate & demoCalcSum.
7
2014-10-14
Setting up a sample project
Setting up a sample project
build_custom.xml is an Ant build script (the Eclipse-generated
build.xml will not be used). This build script consists of various
targets, on this slide we can see the “init” target which initializes
file and folder structures pre-compilation.
On this slide we can see the “build”, “clean” and “run” targets
which compile the project, clean (ie. delete) generated binaries
and other artifacts, and run the project.
Setting up a sample project
Running the project locally
Running the project locally
On this slide we can see the “test” target which runs JUnit tests
included in the project.
Running the project locally
Running the project locally
Now that we have a project in place, let’s run it
in the IDE and in the CLI.
We are using Eclipse as our IDE and Windows
Command Prompt as our interfaces
but of course any IDE and CLI can be used.
Demo01 is running, also creating an instance of Demo02.
“hello” and “world” is concatenated into “helloworld”.
5 and 10 is added up into 15.
8
2014-10-14
Running the project locally
Test01 is running, displaying both console output stream
(bottom) and the passing of unit tests (right).
Both tests passed successfully.
Running the project locally
Demo01 can also be run through Ant via the CLI, this
command directs Ant to build_custom.xml and runs the target
“run”:
ant -f build_custom.xml run
Running the project locally
build_custom is building and testing the project.
Console output stream of the junit tests can be read.
Running the project locally
Test01 can aswell be run through Ant via the CLI, this
command directs Ant to build_custom.xml and runs the target
“test” (which performs unit tests):
ant -f build_custom.xml test
Setting up and installing Ant & JUnit
Setting up and installing Ant & JUnit
Setting up and installing
Ant & JUnit
We’ve demonstrated how to use Ant and JUnit
both within the IDE and outside (via the CLI).
Let’s take a step back and go through the
installation and integration process of
connecting Ant and JUnit to the IDE.
9
2014-10-14
Setting up and installing Ant & JUnit
Navigate to the JUnit homepage (http://junit.org/) and read
about JUnit or simply proceed to the installation page.
Setting up and installing Ant & JUnit
You should know have these 3 archive files in your download
folder.
Setting up and installing Ant & JUnit
Refer to the Apache Ant manual if you have trouble installing
Ant or want to learn more about Ant in general.
Setting up and installing Ant & JUnit
Navigate to the Apache Ant “Binary Distributions” page
(http://ant.apache.org/bindownload.cgi) and download the .zip
archive.
Setting up and installing Ant & JUnit
Refer to the JUnit FAQ if you have trouble installing JUnit or
want to learn more about JUnit in general.
Setting up and installing Ant & JUnit
Installing JUnit in short:
Place the hamcrest-core library and junit library in the /lib folder
of your project.
10
2014-10-14
Setting up and installing Ant & JUnit
For Eclipse, go into the project properties and add the JAR to
the libraries in the Java Build Path. If you have a recent version
of Eclipse, this isn’t necessary as JUnit should already be
provided in the bundle.
Setting up and installing Ant & JUnit
Setting up and installing Ant & JUnit
Installing Ant in short:
Extract the contents of the apache-ant .zip archive into any
folder, I’ve placed it in C:\ant.
Make sure you correctly configure environment variables (refer
to the Apache Ant manual)
Setting up a VCS and commit code
Setting up a VCS
and commit code
Try running the command “ant -version” from any directory in
the CLI (Command Prompt).
The version of Ant should be displayed.
Setting up a VCS and commit code
Setting up a VCS and commit code
In this section, we will demonstrate how to set
up a VCS (version control system)
using a SVN (Apache Subversion) repository
hosted on Google Code.
We will also demonstrate how you can commit
your project files to the repository.
Navigate to the Google code webpage (https://code.google.com/)
and click on “Create a new project”.
11
2014-10-14
Setting up a VCS and commit code
Set up the parameters of your VCS. You can use Git, Mercurial
or Subversion with Google Code, we’re going to use
Subversion.
Setting up a VCS and commit code
Setting up a VCS and commit code
Google Code provides a graphical interface to the SVN
repository. Here’s an overview of the source code.
Setting up a VCS and commit code
So that’s how the interface of Google Code
looks like, now let’s take a look at how to
actually commit the code of the project.
We’re going to use TortoiseSVN to commit
code through a graphical interface. Of course
this can also be done through a CLI but we will
not cover this approach.
Here’s an overview of commit messages and revision changes.
Setting up a VCS and commit code
Navigate to the TortoiseSVN webpage (http://tortoisesvn.net/)
and download TortoiseSVN.
Setting up a VCS and commit code
Make some changes in the source code.
12
2014-10-14
Setting up a VCS and commit code
TortoiseSVN spots the differences in the project folder
(workspace). You must however first commit your existing
codebase for it to track changes done to your project files.
Setting up a VCS and commit code
Any changes made are displayed here, including addition or
removal of files (compared to the most recent revision, the
HEAD revision). Click on OK to commit the changes.
Setting up a VCS and commit code
The changes are displayed and highlighted in the
TortoiseMerge editor.
Setting up a VCS and commit code
Let’s commit the changes. Right-click on the project folder and
select “SVN Commit…”
Setting up a VCS and commit code
Let’s inspect the changes. Right-click on the changed file and
select “Compare with base”.
Setting up a VCS and commit code
We can also inspect committed changes between revisions
through the Google Code graphical interface. Clicking on “diff”
displays changes made in a particular file.
13
2014-10-14
Setting up a VCS and commit code
Monitoring VCS changes via TeamCity
Monitoring VCS changes
via TeamCity
Here’s an example of changes made between r30 and r31
(revision 30 and 31). A lot of code and comment was removed.
Monitoring VCS changes via TeamCity
Not every VCS has a graphical interface.
In fact, most VCSes can only be accessed and
interacted with via CLIs.
Let’s take a look at how we can monitor the
codebase and differences between revisions
in the VCS via TeamCity.
Monitoring VCS changes via TeamCity
Monitoring VCS changes via TeamCity
The first time you navigate to the “Changes” page in TeamCity
you will be presented with an empty list and a message telling
you that your VCS username is not set up. So let’s set it up by
clicking on the link in the text: “your VCS username settings”.
Monitoring VCS changes via TeamCity
Click on “Add new VCS username”.
Once you’ve set up a VCS root (we will go over this later on),
type in which VCS roots you want to monitor and for what
username. The VCS username is the username by which the
VCS identifies you.
14
2014-10-14
Monitoring VCS changes via TeamCity
Monitoring VCS changes via TeamCity
A new VCS username has been added.
The VCS username is the username by which your VCS
(Google Code SVN in our case) identifies you. Look up your
VCS username by checking the logs of your VCS or refer to the
manual of your VCS of choice.
Monitoring VCS changes via TeamCity
Monitoring VCS changes via TeamCity
We can confirm that Google Code SVN identifies us as
[email protected] through the changes page which
lists revisions and details of those revisions (such as who
committed them).
Monitoring VCS changes via TeamCity
We can also click on the white arrows next to the revisions to
expand the details of that particular revision. We’re presented
with build information in the “Builds” tab.
If we navigate back to the “Changes” page of TeamCity, we
can now see that the revisions are correctly displayed.
Monitoring VCS changes via TeamCity
If we click on the “Files” tab, we’re presented with information
about what files were changed for that particular revision.
We can see that “Test01.java” was changed for this revision.
By clicking on the link, we get taken to the “difference viewer”.
15
2014-10-14
Monitoring VCS changes via TeamCity
Setting up a project in TeamCity
Setting up a project
in TeamCity
In the “difference viewer” we can inspect the changes between
revisions, the same way we did through Google Codes
graphical interface. This is particularly useful for those working
with a repository that does not provide a graphical interface.
Setting up a project in TeamCity
Setting up a project in TeamCity
Now that we a sample project and a
connection to the VCS set up, let’s take a look
at how projects can be set up in TeamCity.
Let’s start by navigating to the “Administration” page and
clicking on “Create project”.
Setting up a project in TeamCity
We’ll call our project “my-first-project”.
The Project ID is generated automatically, but we can assign
this manully aswell.
Setting up a project in TeamCity
The project “my-first-project” is now created.
Let’s proceed with setting up a VCS Root.
16
2014-10-14
Setting up a project in TeamCity
A VCS Root is a connection to your repository via TeamCity.
Click on “VCS Roots” at the sidebar on the left-hand side.
Let’s create a new VCS Root by clicking on “Create VCS root”.
Setting up a project in TeamCity
Setting up a project in TeamCity
Refer to your VCS manual to get the URL of your repository.
For Google Code SVN we navigate to “Source/Checkout” to get
the URL of our repository.
Setting up a project in TeamCity
Our VCS Root has been successfully created.
Fill in the information needed to set up a VCS Root.
We’ll call this VCS Root “my-first-project-SVN-google-codeVCS-root” and fill in the URL of the repository under “SVN
Connection Settings”.
Setting up a project in TeamCity
Setting up a project in TeamCity
We’ll call it “my-first-buildconfig”.
Next, let’s head back to the “General Settings” of our project
and select “Create build configuration”.
A Build Configuration is a set of settings which determine
how the project is built. It also determines what happens before
and after builds.
17
2014-10-14
Setting up a project in TeamCity
Setting up a project in TeamCity
The VCS Root has been successfully attached to “my-firstproject”.
Now that we’ve created a Build Configuration, let’s attach it to
the VCS Root that we created moments earlier by selecting it
from the drop-down list and clicking on “Attach”.
Setting up a project in TeamCity
Setting up a project in TeamCity
Now let’s add a Build Step by clicking on “Build Steps” in the
sidebar and then clicking on the “Add build step” button.
A Build Step is a process which will be executed when the
project is run through a particular build configuration.
Setting up a project in TeamCity
We’ll set up our first Build Step as an Ant runner.
Let’s name it “ant-build-step” and point toward
build_custom.xml. Also, let’s make sure it runs the test target
(so that it performs JUnit tests).
Setting up a project in TeamCity
The Build Step “ant-build-step” was added.
Let’s set up another Build Step as a Command Line runner.
This one will just consist of an echo message, but as you can
see this kind of setup provides a lot of possibilities and control
over how the project is built.
18
2014-10-14
Setting up a project in TeamCity
Setting up a project in TeamCity
Both Build Steps are now set up.
Let’s move on and add a Trigger.
Triggers are used to control when the build is to be triggered,
either by an event or at a defined regular time.
Setting up a project in TeamCity
We’ll start by setting up a VCS Trigger.
It will trigger whenever a change is detected in the VCS (so
whenever a new commit reaches the VCS and a new revision
is generated, this Build Configuration will trigger).
Setting up a project in TeamCity
Setting up a project in TeamCity
Next up, we’ll set up a Schedule Trigger.
It will trigger at a regular interval, in this case it will trigger daily
at 2 AM UTC+2, and only if there are pending changes.
Setting up a project in TeamCity
Our Triggers have been added.
Finally, let’s take a look at Failure Conditions.
Failure Conditions are conditions or events that will cause the
build to break. By applying these to the Build Configuration the
development team can strictly control and enforce rules
regarding which builds pass successfully and which builds fail.
19
2014-10-14
Setting up a project in TeamCity
Setting up a project in TeamCity
The Failure condition was added.
We’ll add a Failure Condition that states that if the build log
contains the text “test did not pass” then the build will result in a
failure.
Running a build in TeamCity
Running a build in TeamCity
Running a build
in TeamCity
Now that we’ve set up our project, let’s take a
look at how to run it manually. In other words,
let’s find out how to run a TeamCity build.
Running a build in TeamCity
Running a build in TeamCity
Of course, having it set up with Triggers will
make sure it runs unattended whenever it’s
triggered, but for demonstrational purposes we
will trigger the build manually.
From the “Overview” page, we can see that our projects has no
builds to display, this is because a build has never been run for
this project. So let’s start by running a build.
Run a build of “my-first-buildconfig” by pressing on the “Run”
button on the far right-hand side.
20
2014-10-14
Running a build in TeamCity
The build is now running.
Running a build in TeamCity
By hovering over the green checkmark, we can see that the
build was successful and also which Build Agent ran the build.
Running a build in TeamCity
Running a build in TeamCity
The build has completed running and the green checkmark is
an indication of a successful build, so we can assume that our
codebase is stable.
Running a build in TeamCity
If we expand the “Build shortcuts” menu by clicking on the
arrow to the right, we are presented with a few shortcuts that
will take us to pages which display details about the build.
We can also click on “.zip” right of the “Build log” link to
download the Build Log as a textfile within an archive file.
Running a build in TeamCity
By clicking on the “...” button next to the “Run” button we can
customize and control the next build to a greater degree.
Let’s click on it and see what options we are presented with.
The first tab of the “Run Custom Build” menu is the “General”
tab. Here we can assign a different Build Agent to run the build.
We can also prioritize the build by putting it to the queue top or
we can clean all files in the checkout directory to make sure
that we’re running a “clean build”.
21
2014-10-14
Running a build in TeamCity
The second tab of the “Run Custom Build” menu is the
“Parameters” tab.
Here we can assign various configuration parameters, system
properties or environment variables that may affect the
outcome of the build.
Running a build in TeamCity
Finally, the last tab of the “Run Custom Build” menu is the
“Comment” tab.
The developer that is triggering the build may leave a comment
here if there’s a particular reason for why this build is to be run.
Taking a look at the Build Configuration
Taking a look at the Build Configuration
Taking a look at the
Build Configuration
Now that we know how to run a build
manually (and through Triggers),
let’s take a look at the information that we are
provided with through the Build Configuration.
Taking a look at the Build Configuration
Taking a look at the Build Configuration
We’ll take a look at the Build Configuration of
ci-research-teamcity-test-project as this project
contains more interesting data to look at.
We’ll be navigating to its Build Configuration
named buildconfig3.
In order to access the Build Configuration we need to click on it
from the “Overview” page.
22
2014-10-14
Taking a look at the Build Configuration
The first tab that we are presented with is the “Overview” tab.
This tab contains a summary of the current state of the Build
Configuration including pending changes, current status and a
list of the recent build history.
Taking a look at the Build Configuration
The third tab is the “Change Log” tab.
This is where you will find information about changes that
occured between and during builds.
Taking a look at the Build Configuration
The second tab is the “History” tab.
This tab contains information about the whole history of builds
done via “buildconfig3”. You can also filter by agent name at
the top of the tab page.
Taking a look at the Build Configuration
If we scroll all the way down to build #13 and #14 we can see
that some files were edited (and summarized in the commit
messages). We can also see that build #13 failed and that the
changes made to Test01.java fixed the codebase so that
build #14 resulted in a successful build.
Taking a look at the Build Configuration
Taking a look at the Build Configuration
The fourth tab is the “Statistics” tab.
Different kinds of metrics and statistics is displayed here in the
form of charts and graphs.
Displayed on the image above is a bar chart for the success
rate of builds run during a set period of time, as well as a line
graph plotting the time of build duration during a period of time.
On this image, we have another two line graphs.
One is displaying the time a build spent in queue before
running during a specified time frame (during a month, as we
can see on the far right side “Range: Month”).
The other is displaying the number of tests that were run during
a particular build, also color coding the nodes to signify the
amount of failed and passed tests.
23
2014-10-14
Taking a look at the Build Configuration
Let’s hover the mouse over these charts and see what
additional information is displayed.
By hovering over this bar we can see that 7 builds were run on
September 14th, out of which 86% passed. So 6 builds passed
during this day and 1 failed.
Taking a look at the Build Configuration
Build #14 spent a relatively long time in queue compared to
other builds. It spent 421 milliseconds in queue.
Taking a look at the Build Configuration
By clicking on a build when highlighting build details, we are
taken to the details of the build results (more about this later).
Let’s take a look at build #13 that had 4 failed tests and 3 that
passed. As we can see the failed tests are:
“testGenerateError”, “testMultipleFailAsserts”,
“testIndexOutOfBoundsExceptionNotRaised” and
“testGenerateFailure”.
Taking a look at the Build Configuration
Build #30 was run on the 3rd of October.
This build had one of the highest measured build duration out
of all of the builds run for this particular Build Configuration at
16.005 seconds.
Taking a look at the Build Configuration
This chart might be a bit tricky to understand at first.
Let’s take a look at build #13.
The green node signifies total amount of tests run, regardless
of if they passed or failed, we can see that there were 7 total
tests run.
The red node signifies total amount of failed tests, 4 failed tests
in this case. We can also see that these 4 tests that failed were
all new tests added recently to the JUnit test class.
Finally, the green node signifies total amount of passed tests, 3
tests passed during this build.
Taking a look at the Build Configuration
Let’s move on from the “Statistics” tab to the next tab,
“Compatible Agents”.
In this tab, we are presented with a list of Build Agents that are
compatible with “buildconfig3” and are able to run it.
By utilizing this configuration, load balancing and decentralized
processing can be put into effect.
24
2014-10-14
Taking a look at the Build Configuration
Taking a look at the Build Configuration
Next up we have the “Pending Changes” tab.
This tab will provide us with a list of pending changes that have
not yet been applied.
Finally we have the “Settings” tab at the end of the tabs bar.
In this tab page we can review and edit the Build
Configurations, very much in the same way we did when we
were setting up a new project.
Taking a look at the Build Results
Taking a look at the Build Results
Taking a look at the
Build Results
Now that we’ve looked at the information that
the Build Configuration can provide, let’s dive a
bit deeper and take a look at the information
that individual Build Results can give us.
Taking a look at the Build Results
Taking a look at the Build Results
Let’s start off with finding an interesting build to look at.
Navigate to the “Overview” or “History” tab of the Build
Configuration and click on a build. We’ll take a closer look at
build #14 by clicking on it.
The first tab that we are presented with is the “Overview” tab.
This tab contains a summary of the Build Results.
We can see that 2 tests passed and that the test was run on
the 19th of September at 22:10:31 and ran for 13 seconds in
total. We can also see the Build Agent that ran it and how it
was triggered (manually or by a Trigger).
25
2014-10-14
Taking a look at the Build Results
Moving on to the second tab, which is the “Changes” tab.
This tab displays changes that were made to the codebase
between builds. As we can see, the latest change made is with
revision 31 of the repository. We can read the commit log
message aswell. Let’s click on the arrow next to “1 file” and see
what happens.
Taking a look at the Build Results
Let’s move on to the third tab “Tests”.
On this tab page we can gather information about tests that
were run for this build. We can see that there were a total of 2
tests run and that they took less than 1 second to run.
The scope of tests can be filtered aswell to customize which
test suites are shown.
Taking a look at the Build Results
Let’s expand the Log tree and view details about the Ant target
“test”. We can see that the test suite has 2 test cases.
We can also see that 2 tests were run during 0.253 seconds.
Both “testCalcSum” and “testStringConcatenate” passed
successfully.
Taking a look at the Build Results
We can see that “Test01.java” was edited in the latest revision
of the codebase.
Taking a look at the Build Results
Moving on to the next tab, “Build Log”.
This is a central functionality of TeamCity and very useful in
determining what went wrong once a build breaks.
Expanding the Log tree reveals detailed information about the
processes and Build Steps that were run during the build.
There is also a way to filter what messages are shown by
selecting a different option in the “View” drop-down list.
Taking a look at the Build Results
The next tab that we will be looking at is the “Parameters” tab.
In this tab we are presented with a list of parameters and
properties that were in effect when the build was run. This is
great for troubleshooting!
26
2014-10-14
Taking a look at the Build Results
Taking a look at the Build Results
Let’s take a look at various parameters that may be of interest.
We can detect the JVM version of the Build Agent that was
performing the build. We can also gather various details about
the Build Agent from the “Parameters” tab.
We can localize the checkout directory of the Build Agent, if we
navigate to that directory we can find the codebase that was
pulled from the repository.
We can also determine who triggered this build (it’s a VCS
trigger in this case).
Taking a look at the Build Results
Taking a look at the Build Results
The OS on which the build was run and the environment
variable “Path” can also be determined by looking through the
“Parameters” tab.
Finally, the last tab that we’ll be looking at is the “Artifacts” tab.
This tab will display all artifacts that were produced by the
build.
27
Bilaga 2
Continuous Integration Survey
How do we define the minimum requirements of a Continuous Integration System?
We are two students from Malmö university in Sweden doing a research on how to define the basic
requirements of a CI-system. The survey takes approximately 5 minutes to fill in.
Your participation is vital to our study and our effort to answer our research questions.
The responses will remain confidential and data gathered in this survey will be handled with care to
make it impossible to trace and identify any specific individual or organization.
If you would like to be notified of the final results of this study, please enter your e-mail address and
check the box at the end of this survey.
Thank you for your participation!
* Required
1. 1 *
What kind of business do you operate?
Mark only one oval.
Administration
Computer / IT
Economy / Finance
Technology / Science
Logistics / Transport
Other:
2. 2 *
How big is your company?
Mark only one oval.
Small (up to 50 employees)
Medium (50 - 250 employees)
Large (over 250 employees)
3. 3 *
Does your company utilize a CI-build solution?
Mark only one oval.
Yes
Sk ip to question 4.
No
Sk ip to question 19.
4. 4 *
What percentage of your developers uses or is affected by the CI-solution (10%, 20%, 30%, 40%,
50% ..... 100%)?
Mark only one oval.
1
2
3
4
5
6
7
10%
8
9
10
100%
5. 5 *
What CI-server software do you use in your company?
Mark only one oval.
Hudson
Bamboo
CruiseControl
Jenkins
BuildMaster
TeamCity
Continua CI - FinalBuilder
Other:
6. 6 *
Why did you choose this CI-system over the others (main advantages with your CI-system)?
Check all that apply.
Low cost (setup and maintenance fee)
None
Ease of use
Fast (building code, processing queries)
Easy to troubleshoot
Reliable (trust the build)
Stable (no system crashes and high availability...etc)
Other:
7. 7 *
What are the main weaknesses with your current CI-system (main disadvantages with your CIsystem)?
Check all that apply.
Difficult to use
Slow
Unstable (causes system crashes, low availability ..etc)
None
Difficult to troubleshoot
High cost (setup and maintenance fee)
Unreliable (don't trust the build)
Other:
8. 8 *
How frequently does your company use the CI-system to perform builds?
Check all that apply.
Continuously (several times a day)
Daily
Weekly
Monthly
9. 9 *
How long does your CI-system take to build a project?
Example: 4:03:32 (4 hours, 3 minutes, 32 seconds)
10. 10 *
Does the CI-system that you have lead to better performance in your company? ("No change"
represented by 2)
Mark only one oval.
1
Worse performance
2
3
Better performance
11. 11 *
How would you describe the basic (functional) requirements of your CI-system (what the system
should be able to do at the minimal level of operation, core functionalities/components)?
12. 12 *
Which of the following are a part of those basic (functional) requirements?
Check all that apply.
Feedback (through e-mail, SMS, Dashboard)
Compiling/Building source code
Test (Unit test, static analysis)
Build agent management (various build agents, build priorities and triggers)
Deployment
Resource management (systems usage, storage, backup and health)
Source code management
Administration (setting up users or groups)
Other:
13. 13 *
Which of the above (functional) requirements that you selected is most important for your CIsystem?
14. 14 *
Does the CI-system that you’re using meet the minimum (functional) requirements that your
company is looking for?
Mark only one oval.
Yes
No
15. 15 *
How would you describe the basic (non-functional) requirements of your CI-system (how well
does it do what it’s supposed to do in terms of performance, usability, reliability, etc.)?
16. 16 *
Which of the following are a part of those basic (non-functional) requirements?
Check all that apply.
Ease to connect with (accessibility)
Response time (usability)
Ease of modification (extensibility)
Ease to be maintained (maintainability)
Stable & no crashes (stability & reliability)
Ease of use (look and feel standards)
Build time (projects/source code)
Easy to debug
Uptime/downtime (availability)
Other:
17. 17 *
Which of the above (non-functional) requirements that you selected is most important for your CIsystem?
18. 18 *
Does the CI-system that you’re using meet the minimum (non-functional) requirements that your
company is looking for?
Mark only one oval.
Yes
No
Notification of study results
19. 19 *
Would you like to be notified of the final results?
Mark only one oval.
Yes
No
20. Please enter your e-mail address if the answer
is "Yes"!
Bilaga 3
litteraturundersökning - källor
Källor (kategori)
Källor
webbartiklar & yrkeskunskap
http://www.aosabook.org/en/integration.html
http://martinfowler.com/articles/continuousIntegration.html
http://developerblog.redhat.com/2013/11/08/ci-strategies
http://blogs.collab.net/cloudforge/continuous-integration-overview-best-practice
http://www.eugeneduvenage.com/series/continuous-integration-2/
http://agileheads.wordpress.com/2012/03/08/continuous-integration-basics/
http://www.wjug.org/wjug/docs/ci-quality-bw.pdf
http://developer.xamarin.com/guides/cross-platform/ci/intro_to_ci/
http://blogs.collab.net/devopsci/ten-best-practices-for-continuous-integration
https://docs.google.com/presentation/d/1Lagu5-PZp22XxL2voBmORv04R6UngRUJs5SClshT2Ck/present
böcker
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Humble, Jez and Farley, Da
Continuous Integration: Improving Software Quality and Reducing Risk (Duvall, Paul M., Matyas, Steve and Glover, Andrew)
vetenskapliga artiklar
Using continuous integration of code and content to teach software engineering with limited resources
A comparison of two iterations of a software studio course based on continuous integration
An Open Source-Based Approach to Software Development Infrastructures
Enabling Agile Testing Through Continuous Integration
Using continuous integration and automated test techniques for a robust C4ISR system
Implementing an Effective Test Automation Framework
Implementing Continuous Integration towards rapid application development
SUMMERING
SUMMERING (NFR gruppering)
1
litteraturundersökning - funktionella krav (del 1)
Funktionella Krav
source code management build source code (though build triggers run arbitrary build scripts (build automation run tests support usage of production-like environment for precise testin assessment of test coverage & code complexity source code formatting & conforming to coding standard generate documentation generate differential artifacts (changelog, change scripts for db, version labeling, ..
1 [6]
1
1 [7]
1
1
1
1
1
1
1
1
1
1
1
1
1
1 [8]
1 [9]
1
1
1
1 [14]
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
19
19
1 [10]
1 [11]
1
1 [15]
1 [12]
1 [16]
1
1 [17]
1 [19]
1 [20]
1 [21]
1 [22]
1 [24]
1 [25]
1 [26]
1 [13]
1
1 [18]
1 [23]
1 [27]
1
1
1
1 [31]
1 [32]
1 [28]
1 [29]
1 [33]
1
1 [34]
1 [35]
1
1
1
1
1 [38]
1
1 [39]
1
16
19
8
9
9
5
1 [30]
1 [36]
1 [37]
1
6
litteraturundersökning - funktionella krav (del 2)
Funktionella Krav
feedback/notifications (build status monitoring, error identification artifact & log storage (product aggregation generate install package build verification (testing) bug/issue tracking software metrics tool (benchmarking/performance measuremen concurrency testing code obfuscation deployment rollback production to stable build multiple architecture builds resource management enable automation & provide infrastructure for repeatable buil scheduling
1 [52]
1
1
1
1 [53]
1
1
1
1
1
1
1 [54]
1
1
1
1 [55]
1 [57]
1
1
1
1 [56]
1
1
1
1
1
1
1
1
1
1
1
1
1 [58]
1 [60]
1 [61]
1
1
1 [62]
1 [63]
1 [64]
1
1
1 [65]
1
1 [59]
1
1
1 [66]
1 [67]
1 [68]
1
1
1
1
1
1 [69]
1
1 [70]
1
1 [72]
1 [75]
1 [76]
1 [73]
1 [71]
1
1 [74]
1
1 [77]
1
1
1
1 [79]
1
18
9
4
1
1
1
3
1
1
1
1
2
1
2
1 [78]
1
1
1
1
13
3
1 [80]
1
1
1 [81]
6
2
16
9
litt.undersökning - icke-funktionella krav (del 1)
Icke-funktionella Krav
performance
availability
how fast can you build a project response times (sending request, interfacing through GUI, startup of system processing times (importing/exporting data, spinning wait cursor-related ease of communication (ease of implementing protocols for intermodular communicatio resource utilization (usage of appropriate resources in an appropriate tim sharing resources uptime/downtime of CI-system, hours of operation (up all the time or scheduled downtime, incl. for maintenanc accessibility to CI-system from workstations (from internet/intranet? connection requirements
1 [89]
1 [90]
1
1 [91]
1 [92]
1 [93]
1 [94]
1
1
1
1
1
1 [95]
1
1 [96]
1 [97]
1 [98]
1 [99]
1
1 [100]
1 [101]
1 [102]
1
1
8
2
4
1
4
1
2
1
3
21
4
litt.undersökning - icke-funktionella krav (del 2)
usability
scalability & capacity
extensibility/flexibility & maintainability
is the usage of the CI-system user-friendly (look and feel standards any mention of UI (web based, graphical, command line, shell detailed feedback / reporting growth requirement - can the system be scaled up? (software performance increases proportionally with added hardware resource throughput - possible to handle a large amount of requests storage - any mention of storage usage or constraint configurability - how easy is it to modify and extend (f.e. with plugins) the CI-syste maintainability/changeability - ease of improving or adapting the system to changes in environment and requireme
1 [111]
1 [112]
1 [113]
1
1
1
1
1
1
1 [114]
1
1
1
1
1
1 [115]
1 [116]
1
1 [117]
1 [118]
1 [119]
1
1
1 [120]
1 [121]
1 [122]
1 [123]
2
21
1 [124]
1
1
8
11
1
1
4
1
1
2
5
1 [125]
3
8
3
litt.undersökning - icke-funktionella krav (del 3)
portability & interoperability
testability
security
multiple programming language suppor can the CI-system be used in various environments (operating systems, hardware platform can the CI-system communicate with other systems through established standards, formats and protocols installability - capability of the system to be installed in a specified environmen co-existence - capability of system to share common resources in a common environment with other independent software/syste components can be isolated and mocked trust policies & authorization
1
1 [132]
1
1
1 [133]
1
1
1
1 [134]
1
1 [135]
1
1 [136]
1 [137]
1 [138]
1 [139]
1
1 [140]
1
1
1
4
1
1 [141]
6
2
1
5
1
18
3
3
3
3
litteraturundersökning - CI-mjukvaror
CI-mjukvara (som nämns)
TeamCity
Jenkins Hudson Team Foundation Build Travis Wercker CruiseControl (incl. CruiseControl.NET & CruiseControl.r Cruise Buildbot CDash Pony-Build (ThoughtWorks) Go Bamboo (Zutubi) Pulse AnthillPro Electric Commander BuildForge Mike CI Continuum TinderBox Automated Build Studio Draco.NET Gauntlet Luntbuild ParaBuild QuickBuild Sin Bitten BuildBeat CM Crossroads Gump PerfectBuild Pragmatic Automation
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1 [142]
1
1
1
1
1
1
1
4
1
1
6
5
1
1
1
7
1
4
1
2
2
5
2
2
4
1
2
1
2
2
1
Bilaga 4
Continuous Integration and Deployment
Petrus Kiendys 1.
Shadi Al Zara Bakgrund
Continuous Integration (CI) är en metod för att effektivt utveckla stabil mjukvara där en grupp
utvecklare är inblandade i ett projekt.
Syftet med exjobbet är att utforska metoden, kvantifiera dess för- och nackdelar, sätt upp krav
för ett CI-system samt implementera ett CI-system för att undersöka om implementationen
uppfyller kraven. Kunskapsinsamlingen kommer att lägga grunden för vidareutveckling av
kursmaterial i ämnet för vår externa samarbetspartner.
Krav och önskemål som ställs på CI-system är att minska kostnaden för
mjukvaruutvecklingsprojekt och samtidigt tillföra ökad funktionalitet i form av detaljrika artefakter
som genereras när CI-systemet bygger källkod. En annan fördel är att projektledare får större
insikt i hur projektet fortskrider och att utvecklare således snabbt kan åtgärda fel.
Eftersom utvecklare enligt CI ska integrera kontinuerligt och dessutom använder sig av en rad
olika analytiska verktyg så upptäcks fel i källkod tidigt i projekt och mer komplexa problem kan
därför tidigt avvärjas. Ett annat krav som ställs på CI-system är således att
mjukvaruutvecklingsgrupper förmodas prestera bättre med ett CI-system som stöd.
Vi har valt att utforska metoden CI eftersom diskussioner med Edument AB (externt företag) har
påvisat att det finns ett intresse och behov i industrin att bedriva ytterligare undersökning och
forskning kring ämnet.
Ett antal rapporter som kan vara relevanta är ”A Comparison of Two Iterations of a Software
Studio
1
Course Based on Continuous Integration” och “Implementing Continuous Integration towards
rapid application development” 2.
2.
Uppdragsbeskrivning
Vi kommer till en början att utföra en grundlig förundersökning där vi lär oss mer om
CI/CD-metoden. Informationen som vi samlat på oss kommer att filtreras, delas upp och
sammanställas i vad som kan utgöra en grund till en nybörjarkurs i CI.
Sedan kommer vi undersöka vilka minimumkrav som ett CI-system måste uppfylla enligt
standarder som framkommer från litteratur samt en marknadsundersökning.
Marknadsundersökningen som utförs kommer att innefatta ca. 10 olika företag som svarar på
olika frågor kring CI.
Vi kommer att utforma en korrekt enkätstudie så att vi försäkrar oss om att vi får användbara
svar ifrån vår marknadsundersökning till vår studie, eventuellt kommer en pilotstudie att
genomföras innan den huvudsakliga marknadsundersökningen genomförs.
Vi kommer att ställa upp funktionella krav och kvalitetsattribut (som är en del av icke-funktionella
krav). Där kommer vi mest att fokusera på performance, usability and availability av ett
CI-system. Vi kommer inte att lägga mycket vikt på testability, security and maintainability.
1 http://dl.acm.org/citation.cfm?id=2462476.2465592 2 http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6236372 1 Både kvalitativ och kvantitativ metod kommer att användas under exjobbets gång, dvs.
Creswells mixed methods.
För att uppfylla krav som ställs på ingenjörer och ingenjörsverksamhet kommer vi att bygga upp
ett CI-system och kravtesta detta system enligt krav som framkommit från litteraturstudien och
marknadsundersökningen. Vi kommer till en början att använda oss av CI-systemet “TeamCity”
för att uppfylla det externa företagets krav. I mån av tid kan vi även kravtesta andra CI-system
för att få in ett mer objektivt perspektiv över den praktiska delen men vi väljer till en början att
avgränsa oss till ett CI-system.
Sammanfattningsvis kommer uppdraget bestå av en sammanställning av kunskap kring CI i
allmänhet och en praktisk beskrivning på hur ett CI-system kan byggas upp mha. TeamCity, en av
de mer populära CI-mjukvarorna. Därefter kommer en marknadsundersökning att utföras bland
svenska företag. Slutligen kommer vi att bygga upp ett CI-system och kravtesta systemet enligt
de krav som framkommit av litteraturstudien och marknadsundersökningen.
3.
Förutsättningar
-
-
4.
System som ska användas:
○ TeamCity, ...
Vart ska arbetet genomföras:
○ MAH
Aktörer:
○ MAH, Edument AB
Externt företag:
○ Edument AB
○ Stora Varvsgatan 6a, Malmö
○ Tore Nestenius
○ [email protected]
○ 040-61 70 720
○ Förväntas arbeta hos företag till 0%
Arbetsplats på högskolan:
○ Behövs
○ Speciell utrustning:
▪ Server/servrar för uppbyggnad av CI-system
▪ Litteratur
Grov tidsplanering med uppgiftsuppdelning
Se bifogad fil Exjobb-tidsplanering VT14 - CI_CD.xlsx för tidsplanering.
2 Bilaga 5
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
Minimum requirements of a CI-system
Petrus Kiendys
PK
Shadi Al-Zara
SA
1. Avgränsning av forskningsfrågan eller huvudproblemet, förtydligande av
kravspecifikationer
1.1 Bakgrund
CI-system används alltmer i näringslivet vid mjukvaruutveckling för att effektivisera
arbetsprocessen och tillföra ökad produktionsvärde.1 I centrum av feedbackloopen mellan
utvecklare och slutanvändare ligger CI-system som bevakar arbetsprocessen, effektiviserar
integration av källkod mellan ett antal olika individer i en utvecklingsgrupp och ger feedback till
utvecklarna så att de kan förbättra källkoden. I takt med en ökad användning av CI-system så
ställs allt högre krav på funktionaliteten som systemen ska tillföra.
1.2 Huvudproblem
Syftet med examensarbetet ä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
tillfredställande för ett utvecklingsteam. Vår frågeställning är således följande:
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 definierade krav testa, värdera och jämföra CI-system?
1
M. Larsson and N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila metodikens utformning i praktiken," Student thesis, Y, 2009 [Online] Available: MAH MUEP, http://muep.mah.se/handle/2043/8343. [Accessed: 2014-03-12].
1
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
1.3 Beskrivande figurer
Fig 1. Workflow för CI-system2
Följande hierarkiska trädstruktur illustrerar uppdelningen av huvudproblemet i delproblem:
Fig 2: Uppdelning av huvudproblemet i delproblem och möjliga lösningsprinciper
2
http://www.programmingresearch.com/products/continuous-integration-jenkins-plug-in/
2
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
1.4 Uppdelning och utförande av arbetet
Examensarbetet kommer att delas upp i fyra olika delar:
1. Vi utför en analys av vilka minimumkrav som behöver uppfyllas för att ha ett välfungerande
CI-system. Kraven tas fram via en litteraturstudie (DP1.1) och en marknadsundersökning
(DP1.2). Vi kommer därefter att dela in kraven i specifika områden dvs. funktionella
(LP1.3.1) och icke-funktionella4 (LP1.3.2) krav för att systematiskt kunna utföra ett
kravtest utefter kraven. Funktionella och icke-funktionella krav kommer att definieras mha.
use cases resp. quality attribute scenarios. Således kommer kravspecifikationen för
CI-system vara förankrat i både vetenskap (LP1.1.2) och industriella erfarenheter (LP1.2.1).
2. När vi väl utformat en kravspecifikation för CI-system så kommer vi att bygga upp en
TeamCity-server (DP2.1). Vi avgränsar oss till just en implementation för att vara säkra på
att kravtest och behandling av data kan utföras i tid. I mån av tid kan vi även tänka oss
implementera flera system och kravtesta dessa.
3. När TeamCity-servern är körbar kan denna testas enligt de krav som vi ställt upp (LP3.1). Vi
kan då på ett mer objektivt och systematiskt sätt redogöra för TeamCitys lämplighet för
användning i olika sammanhang annat än en subjektiv åsikt. Vi kommer även efter testerna
titta på hur TeamCity beskrivs i dokumentation och jämförelsematriser på nätet samt titta
på hur andra system (LP3.2), som vi troligtvis inte hinner mäta, beskrivs.
4. Den sista delen av examensarbetet kommer bestå av att behandla data (DP4) som vi fick
fram från testfasen. Vi kommer här att diskutera och presentera data (LP4.1) samt dra
slutsatser för TeamCity och CI-system utifrån denna data. En artefakt som kommer att
produceras under examensarbetet är kursmaterial (LP4.2) till vår externa handledare, denna
process kommer löpa parallellt med tidigare nämnda delproblem.
Efter diskussioner med vår interna handledare har vi kommit fram till att mixed methods3 är att
föredra som metod när vi analyserar data från marknadsundersökningen och systemtester, samt
att vi ska förhålla oss till Software Architecture in Practice4 när vi utformar den tekniska
specifikationen.
Följande lista med kravspecifikationer har fastställts. Typbetäckningarna m/i/ö avser
minimumkrav, idealkrav resp. önskemål. I tabellen finns också hänvisningar till delproblem och
lösningsprinciper i figur 2 som kravspecifikationer framför allt gäller för:
Krav
-nr.
K1
Typ
m/i/ö
m
K2
m
K3
m/i
Kravspecifikation
Få ut en lista på minst 5 krav för att kunna kravtesta
CI-system
Ha ett körbart CI-system som kan bygga källkod och
köra tester
Formulera 15/20 frågor som ska användas till
marknadsundersökningen
Gäller
för
DP1
DP2
DP1.2
3
Creswell, J.W. (2003). Research design: qualitative, quantitative, and mixed methods approaches. (2. ed.) Thousand Oaks: Sage.
Bass, L., Clements, P. & Kazman, R. (2012). Software architecture in practice. (3. ed.) Upper Saddle River, N.J.: Addison-Wesley.
4
3
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
K4
K5
m/i
ö
K6
K7
m/i
m/i
K8
ö
K9
m
K10
m
K11
m/i
FÖRSTUDIE
2014-03-18
Få ut 10/15 svar från enkätsundersökningen
Bygga upp flera CI-system som kan jämföras med
TeamCity
Kunna köra 5/10 build agents samtidigt
Kunna avläsa resultat från kravtest i mindre/större
detaljnivå
Jämför data från kravtest mellan olika CI-system
Jämför mätdata från test på TeamCity med
dokumenterade egenskaper i både TeamCity och andra
CI-system
Presentera data enligt 3 olika kvalitetsattribut
(performance, usability, availability)
Skapa 5/10 kapitel till kursmaterialet
LP1.2.1
DP2.1
LP2.1.2
DP3
LP2.1.1
LP3.1
LP3.2
LP3.2
LP4.1
LP4.2
2. Informationssökning efter vetenskapliga artiklar och yrkeskunskap
Följande översikt visar sambandet mellan delproblem (DP) och lösningsprinciper (LP) från figur 2
och de vetenskapliga artiklar och den yrkeskunskap som resulterade från informationssökningen.
En kort beskrivning förklarar relevansen av källorna för examensarbetet.
DP, LP
DP2
LP2.1.1
Lp2.1.2
DP4
Källförteckning
Relevans
DP2.1
Volodymyr Melymuka. TeamCity 7
Continuous Integration Essentials, A
step-by-step introductory tutorial and
intelligible practical guide to
successfully applying Continuous
Integration via TeamCity, Birmingham,
2012
Bok som beskriver hur man bygger
upp en TeamCity-server
(CI-system). Hög relevans.
LP1.1.1
Farley, Dave; Humble, Jez.
Continuous Delivery Reliable Software
Releases through Build, Test, and
Deployment Automation, Wesley
Professional,
pp.63, 2010 [Elektronisk resurs]
Bok där man bl.a. behandlar olika
komponenter som ingår i ett
CI-system.
Kawalerowicz, Marcin; Berntson,
Craig. "Continuous integration in
.NET", Manning Publications 2011,
[Elektronisk resurs]
Bok där man bl.a. behandlar olika
komponenter som ingår i ett
CI-system och visar hur man
presenterar data.
4
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
LP1.1.1
DP2
DP1.2
LP1.2.1
DP1
DP1
DP1
FÖRSTUDIE
Duvall, Paul M; Matyas, Steve;
Glover, Andrew. Continuous
integration: improving software quality
and reducing risk, Saddle River, NJ,
2007
Saunders, M; Lewis, P; Thornhill, A.
Research methods for business
students, 5th ed., Pearson Education
,pp. 359-524, 2009
Amy Brown; Greg Wilson. Continuous
Integration in The architecture of open
source applications:
Elegance,Evolution,and a Few Fearless
Hacks, (volume 1), June2. 2011
“Continuous Integration- Basic
Overview and Best Practices”,
http://blogs.collab.net/cloudforge/co
ntinuous-integration-overview-best-p
ractice#.Uw5SUPldVH4
“Continuous Integration”,
http://martinfowler.com/articles/conti
nuousIntegration.html
DP1
“Continuous Integration Strategies”,
http://developerblog.redhat.com/201
3/11/08/ci-strategies-1of3/
LP2.1.1
LP2.1.2
“Introduction to Continuous
Integration with Xamarin”
http://docs.xamarin.com/guides/cros
s-platform/ci/intro_to_ci/
Yuhoon Ki; Meongchul Song, "An
Open Source-Based Approach to
Software Development
Infrastructures," Automated Software
Engineering, 2009. ASE '09. 24th
IEEE/ACM International Conference on
, vol., no., pp.525,529, 16-20 Nov. 2009
LP1.1.2
2014-03-18
Bok där man beskriver CI i stort och
även komponenter som används i
CI-system.
Bok där man förklarar hur man går
till väga när man genomför en
marknadsundersökning genom att
förklara diverse
undersökningsmetoder som
används i näringslivet. Man
förklarar även den praktiska
relevansen av
undersökningsmetoderna.
Utdrag ur bok där komponenter och
funktionella krav för ett CI-system
beskrivs. Medelhög relevans.
Webbartikel där komponenter i ett
CI-system beskrivs. Väldigt hög
relevans eftersom fokus för
artikeln sammanfaller med vår
frågeställning.
Webbartikel av Martin Fowler (en av
grundarna av “agile manifesto” och
nykelperson i ThoughtWorks).
Denna artikel omnämns och
refereras upprepande gånger i
både böcker och vetenskapliga
artiklar. En genomgång av vad CI är
och varför det bör tillämpas.
Medelhög relevans.
Webbartikel där man går in på en
processbeskrivning för hur ett
CI-system bör fungera. Hög
relevans.
Webbartikel där man beskriver
några komponenter i olika delar av
ett CI-System. Medelhög relevans.
Vetenskaplig artikel där man
beskriver fördelar med att använda
automatiserade
mjukvaruutvecklingsverktyg vid
mjukvaruutveckling för mer
komplexa system. Anger
flaskhalsar i mjukvaruutveckling för
större projekt och presenterar en
5
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
LP1.1.2
DP2.1
DP3
LP1.1.2
LP2.1.2
LP1.1.2
LP1.1.2
DP1
DP1.1
LP1.1.2
FÖRSTUDIE
2014-03-18
open-source lösning som förbättrar
utvecklingsmiljön. Beskriver CI som
en del av
mjukvaruutvecklingsverktyg som
används vid större projekt.
Stolberg, S., "Enabling Agile Testing
Vetenskaplig artikel i form av en
through Continuous Integration,"
case study av hur ett CI-system
Agile Conference, 2009. AGILE '09. ,
implementerades när man gick från
vol., no., pp.369,374, 24-28 Aug. 2009 traditionell till agil utveckling och
testning av mjukvara. Beskriver
olika steg/komponenter i ett
CI-system.
Medelhög relevans.
Yuksel, H.M.; Tuzun, E.; Gelirli, E.;
Vetenskaplig artikel i form av en
Biyikli, E.; Baykal, B., "Using
case study som visar hur
continuous integration and
CI-system och automatiserade
automated test techniques for a
tester används för att utveckla
robust C4ISR system," Computer and robusta C4ISR system (command &
Information Sciences, 2009. ISCIS
control, används för kommunikation
2009. 24th International Symposium on mellan militärbefälhavare och
, vol., no., pp.743,748, 14-16 Sept.
styrkor). TeamCity används som
2009
CI-system. Beskriver koncepten
build agents och build configuration
som används i TeamCity. Beskriver
även testning utförligt.
Eun Ha Kim; Jong Chae Na; Seok
Vetenskaplig artikel där man
Moon Ryoo, "Implementing an
beskriver grundläggande steg i
Effective Test Automation
bygge av mjukvara som bl.a.
Framework," Computer Software and
involverar en VCS, en CI-server och
Applications Conference, 2009.
automatiserad testserver.
COMPSAC '09. 33rd Annual IEEE
Medelhög relevans.
International , vol.2, no., pp.534,538,
20-24 July 2009
Bo Jiang; Zhenyu Zhang; Tse, T. H.;
Vetenskaplig artikel där man
Chen, T.Y., "How Well Do Test Case
beskriver olika steg i bygge av
Prioritization Techniques Support
mjukvara mha. CI-system.
Statistical Fault Localization,"
Computer Software and Applications
Conference, 2009. COMPSAC '09.
33rd Annual IEEE International , vol.1,
no., pp.99,106, 20-24 July 2009
Abdul, F.A.; Fhang, M.C.S.,
Vetenskaplig artikel där man
"Implementing Continuous Integration beskriver grundläggande CI-system
towards rapid application
komponenter och
development," Innovation
arbetsprocessen.
Management and Technology
Research (ICIMTR), 2012 International
Conference on , vol., no., pp.118,123,
21-22 May 2012
6
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
DP2.1
DP1
DP2
FÖRSTUDIE
http://confluence.jetbrains.com/displ
ay/TCD8
Staffan Persson. “Introducing
Continuous Integration in an
Enterprise Scale Environment”.
Uppsala Universitet, 2008
2014-03-18
Dokumentation av TeamCity. Hög
relevans.
Examensarbete där man förklarar
hur befintliga
mjukvaruutvecklingsmiljöer kan
ändras för att innefatta en
CI-process. Beskriver komponenter
i ett CI-system. Hög relevans.
3. Genomförbarhetsanalys
Till en början tänkte vi att vårt examensarbete skulle innefatta både sociala och tekniska
aspekter av att tillämpa CI-system i en verksamhet men efter diskussion och feedback från
lärarlaget i samband med problemformuleringsredovisningen blev vi tvungna att omvärdera
omfattningen av arbetet. Vi har därför bestämt oss att avgränsa oss till att endast innefatta en
teknisk aspekt av CI-system i detta examensarbete. Detta innebär att vi kan uppfylla både
MAH’s och vår externa handledares krav under arbetets gång.
Som tidigare nämnt kommer examensarbetet att bestå av 4 delar (se 1.2 Huvudproblem).
Genomförbarheten för att ställa upp krav för CI-system DP1 är mellanhög till hög. Vi har lyckats
hitta enstaka artiklar som objektivt beskriver grundfunktionalitet och krav som CI-system ska
uppfylla. Det är mycket möjligt att vi ger oss in på ett tidigare outforskat forskningsområde och
kommer därför stöta på hinder men även möjlighet till att bidra till forskningen på ett unikt sätt.
Genomförbarheten av DP1.2 är hög eftersom vår externa handledare kan tillhandahålla kontakter
inom näringslivet, undersökningen kan även lägga grund till DP1 eftersom litteraturundersökningen
påvisar att det finns väldigt lite relevanta vetenskapliga artiklar kring ämnet, däremot finns det
mycket med yrkeskunskap i form av webbartiklar och böcker skrivna om ämnet.
Att bygga upp ett CI-system DP2 ska kunna utföras förutsatt att vi får tillgång till hårdvara i tid, vi
upskattar att genomförbarheten för DP2 är väldigt hög. Vi har redan börjat diskutera med
handledare och IT-support för att få tillgång till hårdvara samt börjat orientera oss kring
implementation av TeamCity.
Testa CI-system enligt krav DP3, denna del är beroende av utförandet av DP1 och DP2.
Förutsatt att DP1 och DP2 utförs med tillfredställande resultat uppskattar vi att
genomförbarheten av LP3.1 är hög. CI-system brukar innehålla stöd för mätningar eller
extensibility i form av plugins, oavsett om man använder sig av förstaparts eller
tredjepartsverktyg för test så uppskattar vi att test kommer att kunna utföras. Angående LP3.2
uppskattar vi genomförbarheten till mellanhög. Vi har hittat funktionalitetsmatriser mellan olika
populära CI-system, frågan återstår om dessa datan från dessa matriser sammanfaller med de
krav som vi kommer att ställa upp.
Behandla och presentera data DP4 & LP4.1 är givetvis beroende av föregående delproblem.
Precis som med DP3 så uppskattar vi att genomförbarheten är hög förutsatt att vi har data att
arbeta med från DP3. Skapa kursmaterial LP4.2 genomför vi parallellt med tidigare nämnda
delproblem och uppskattar att genomförbarheten är hög.
7
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
Vi anser att examensarbetet är genomförbart i nuläget, vissa delar kan ta mer tid än vad vi
uppskattar men på det stora hela anser vi att genomförbarheten för examensarbetet är hög.
4. Detaljplanering med ansvars- och uppgiftsuppdelning
8
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
5. Disposition av rapporten
1. Sammanfattning (Abstract)
2. Innehållsförteckning
3. Inledning
a. Bakgrund
i.
Inledning till examensarbete
ii.
Målgrupp för examensarbete
b. Syfte och frågeställning
i.
Varför valde vi detta ämne?
c. Uppdragsbeskrivning
i.
Internt uppdrag
ii.
Externt uppdrag
d. Förutsättningar och avgränsningar
e. Tidigare forskning
f. Metod - Hur arbetet ska genomföras
i.
Creswells “mixed methods” - kvalitativ och kvantitativ dataanalys
ii.
Funktionella och icke-funktionella krav
4. Teknisk beskrivning (Teori) - Grundlig beskrivning av teoretiska aspekter, även lite breddning
åt håll som vi inte tittar närmare på
a. Agila metoder - Vad är agila metoder?
b. Continuous Integration - Vad är CI och varför används det?
c. CI-system - Hur stödjer man arbetsprocessen CI mha. verktyg? Vilka verktyg finns det
att välja mellan?
d. Hur ställer man upp krav för system?
e. Hur ställer man upp tester för system?
5. Utförande - Hur har vi gjort? Varför gjorde vi så?
a. Hur utförde vi studien kring kravspecifikation för CI-system?
b. Varför valde vi TeamCity och hur byggde vi upp CI-systemet?
i.
Vilka CI-system finns det, varför valde vi TeamCity?
c. Vilka tester valde vi att genomföra och vad vill vi komma fram till genom testerna?
6. Resultat
a. Krav för CI-system
b. Uppbyggnad av ett CI-system (TeamCity)
c. Tester
7. Slutsats
8. Diskussion
a. För- och nackdelar med CI-system
b. Stämmer resultaten överens med vår hypotes? - Är resultaten och mätdatan
tillfredställande för att kunna göra en bra bedömning och komma fram till en tydlig
slutsats?
c. Förbättringar - Saker som kan ha gjorts bättre, alternativlösningar
d. Vidare forskning - Frågeställningar som uppkom i samband med studien
9. Referenser
a. appendix A
i.
bilaga 1: Kursmaterial till extern handledare
b. appendix B
9
Examensarbete VT2013 inom
högskoleingenjörsprogram ”Data & telekom” och
”Programvaruutveckling”
Teknik och samhälle
Institutionen för datavetenskap
FÖRSTUDIE
2014-03-18
Källförteckning
1.
2.
3.
4.
M. Larsson and N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila metodikens utformning i praktiken," Student thesis, Y, 2009 [Online] Available: MAH MUEP, http://muep.mah.se/handle/2043/8343. [Accessed: 2014-03-12].
http://www.programmingresearch.com/products/continuous-integration-jenkins-plug-in/
Creswell, J.W. (2003). Research design: qualitative, quantitative, and mixed methods approaches. (2. ed.) Thousand Oaks: Sage.
Bass, L., Clements, P. & Kazman, R. (2012). Software architecture in practice. (3. ed.) Upper Saddle River, N.J.: Addison-Wesley.
10
Bilaga 6
Tester 1 (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Task time [1] Användarens tillfredställelse Löstes uppgiften?
Övrig information
[villkorlig] Om uppgiften inte löstes, varför? [4]
Task nr.
Navigera till "build" sektion av CI-system [7]
0:49
5
1
9
Navigera till "inställningar" sektion av CI-system
7:55
3
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [8]
2:46
5
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [9]
1:09
5
1
8
Öppna en "build log" och granska tester som körts [10]
2:13
5
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
1:28
4
1
7
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [11]
2:43
3
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [12]
5:41
3
1
15
Kompilera källkod för ett projekt [13]
0:42
5
1
Kör enhetstester för ett projekt [14]
1:34
5
1
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
4:14
1
0
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
1:13
4
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:50
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
1:30
5
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
2:27
4
1
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [15]
5:00
5
1
Navigera till "användningsstatistik" sektion av CI-system
6:21
3
0
Minimera inverkan av fel
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.12
49:35
15
Testare identifierare
20141002_1200
10
11
Unable to locate button/interface to create and copy the build configurat
14
4
5
Incorrect input, mistook "Java version" for "Java runtime version"
3
Tester 2 (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Task time
Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför?
Övrig information
Task nr.
Navigera till "build" sektion av CI-system [22]
1:39
5
1
9
Navigera till "inställningar" sektion av CI-system
3:33
4
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [23]
5:04
4
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [24]
1:47
5
1
8
Öppna en "build log" och granska tester som körts [25]
5:18
3
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
1:00
5
1
7
2:16
4
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [27]
6:49
2
1
15
Kompilera källkod för ett projekt [28]
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [26]
1:23
5
1
10
Kör enhetstester för ett projekt [29]
3:20
3
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
2:30
4
1
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
0:54
5
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:01
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
2:36
5
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
3:17
3
1
4
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [30]
5:23
4
1
5
Navigera till "användningsstatistik" sektion av CI-system
0:52
5
1
3
Minimera inverkan av fel
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.18
48:42
17
Testare identifierare
20141006_1300
Tester 3 (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför?
Övrig information
Task nr.
0:47
5
1
9
Navigera till "inställningar" sektion av CI-system
1:25
5
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [38]
1:52
4
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [39]
1:25
5
1
8
Öppna en "build log" och granska tester som körts [40]
3:56
3
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
0:51
5
1
7
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [41]
Minimera inverkan av fel
Task time
Navigera till "build" sektion av CI-system [37]
3:46
4
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [42]
3:18
5
1
15
Kompilera källkod för ett projekt [43]
1:32
4
1
10
Kör enhetstester för ett projekt [44]
1:21
5
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
3:22
3
1
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
2:41
4
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:01
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
1:53
4
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
2:12
3
1
4
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [45]
2:23
4
1
5
Navigera till "användningsstatistik" sektion av CI-system
1:18
5
1
3
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.29
35:03
17
Testare identifierare
20141007_1800
Tester 4 (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Task time
Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför?
Övrig information
Task nr.
Navigera till "build" sektion av CI-system [52]
1:55
4
1
9
Navigera till "inställningar" sektion av CI-system
1:53
5
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [53]
2:06
4
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [54]
1:30
5
1
8
Öppna en "build log" och granska tester som körts [55]
3:26
4
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
2:51
4
1
7
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [56]
2:52
5
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [57]
5:57
4
1
15
Kompilera källkod för ett projekt [58]
1:02
5
1
10
Kör enhetstester för ett projekt [59]
2:41
4
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
3:37
4
1
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
2:44
4
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:22
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
2:46
4
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
4:59
3
1
4
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [60]
1:27
4
1
5
Navigera till "användningsstatistik" sektion av CI-system
1:37
5
1
3
Minimera inverkan av fel
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.29
44:45
17
Testare identifierare
20141008_1500
Tester 5 (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Task time
Användarens tillfredställelse Löstes uppgiften?
Övrig information
[villkorlig] Om uppgiften inte löstes, varför? [64]
Task nr.
Navigera till "build" sektion av CI-system [67]
1:29
5
1
9
Navigera till "inställningar" sektion av CI-system
2:39
4
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [68]
2:53
4
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [69]
1:20
5
1
8
Öppna en "build log" och granska tester som körts [70]
2:17
5
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
1:20
5
1
7
3:21
4
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [72]
4:24
4
1
15
Kompilera källkod för ett projekt [73]
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [71]
1:14
5
1
10
Kör enhetstester för ett projekt [74]
1:09
5
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
3:46
4
1
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
1:38
5
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:38
5
1
Ändra säkerhetsinställningar och ångra ändringen
2:30
4
1
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
3:07
1
0
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [75]
1:50
5
1
5
Navigera till "användningsstatistik" sektion av CI-system
1:53
5
1
3
Minimera inverkan av fel
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.41
38:28
16
Testare identifierare
20141009_1600
13
2
The tester was unable to locate the element that disables visibility of a pro
4
Tester 6 (control)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Task time
Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför?
Övrig information
Task nr.
Navigera till "build" sektion av CI-system [82]
0:28
5
1
9
Navigera till "inställningar" sektion av CI-system
1:45
4
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [83]
2:10
4
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [84]
0:52
5
1
8
Öppna en "build log" och granska tester som körts [85]
0:40
5
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
0:41
5
1
7
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [86]
1:03
5
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [87]
2:18
5
1
15
Kompilera källkod för ett projekt [88]
1:16
5
1
10
Kör enhetstester för ett projekt [89]
1:34
4
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
1:42
5
1
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
0:43
5
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
0:34
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
1:16
5
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
1:35
5
1
4
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [90]
0:34
5
1
5
Navigera till "användningsstatistik" sektion av CI-system
1:08
5
1
3
Minimera inverkan av fel
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.82
20:19
17
Testare identifierare
20141003_1600
Average (experimental)
Mätning av respons
Huvudområde
Inlärning av systemets funktioner
Respons
GUI:t är tydligt och lättanvänt
GUI:ns design är baserad på “progressive disclosure”
Uppgift
Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför?
Övrig information
Task nr.
1:19
4.8
1
9
Navigera till "inställningar" sektion av CI-system
3:29
4.2
1
1
Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [98]
2:56
4.2
1
6
Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [99]
1:26
1
8
Öppna en "build log" och granska tester som körts [100]
3:26
4
1
12
Fäll ut och fäll ihop detaljer kring incheckningar
1:30
4.6
1
Det är enkelt att automatisera funktioner som ofta kommer att använd Lägg till en "trigger" i en "build configuration" [101]
Minimera inverkan av fel
Task time
Navigera till "build" sektion av CI-system [97]
5
7
2:59
4
1
16
Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [102]
5:13
3.6
1
15
Kompilera källkod för ett projekt [103]
1:10
4.8
1
10
Kör enhetstester för ett projekt [104]
2:01
4.4
1
11
Återanvändning av data/kommandon
Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration"
3:29
3.2
0.8
14
Dialogrutor och säkringar
Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker
1:50
4.4
1
17
Möjlighet att “ångra” ändringar
Stoppa en pågående "build"
1:22
5
1
13
Ändra säkerhetsinställningar och ångra ändringen
2:15
4.4
1
2
Anpassning av systemet för användarens beh Systemets utseende och funktionalitet kan ändras
Dölj ett projekt från "Projekt" sektionen av CI-systemet
3:12
2.8
0.8
4
Inge förtroende och tillfredsställelse
Kontrollera om kodbasen för ett visst projekt är stabil (grön) eller bruten (röd) [105]
3:12
4.4
1
5
Navigera till "användningsstatistik" sektion av CI-system
2:24
4.6
0.8
3
Systemets tillstånd åskådliggörs tydligt för användaren
Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1
4.26
43:18
16.4
Testare identifierare
avg_exp
Bilaga 7
Usability test - user form (TeamCity)
Please fill in this form as you're doing the usability test.
This form contains all tasks that you need to complete.
We will monitor your progress through screen capture software during the test.
You may go back to previous tasks to read the task descriptions once again but you may not
change previous answers that you have submitted.
To provide clarification, the help text of each task is simplified by a set number of steps,
denoted by (#), ie. "(1) perform step 1, (2) perform step 2."
If you are unable to complete a specific task, please explain why you were unable to
complete that task.
Please be aware that this is a usability test that is used to measure the usability of TeamCity
and is not targeted at measuring your ability as a tester to solve problems and perform tasks,
so please do not feel under pressure to perform. Simply read the task instructions and do
your best to complete the tasks.
The test contains 17 tasks that you will perform, the 17 tasks are structured into 3 main parts:
- Interaction with the UI & VCS, changing settings
- Compiling and testing code, reading logs
- Setting up a custom build configuration
After completing all of the tasks a short series of questions may be answered in a 1-5 Likert
scale format to convey your overall impression of TeamCity from a usability standpoint.
Feel free to get acquainted with the interface of TeamCity and TeamViewer before you start
taking the test.
An assistant will be offering assistance during the test if needed, please do not hesitate to
type any questions or concerns into the TeamViewer chat.
If you are unable to complete a task and subsequent tasks depend on the completion of that
specific task, the assistant will set up TeamCity so that you can proceed with the test.
The assistant will communicate with you through chat and voice when needed.
Please answer a few short questions below before proceeding with the test.
When you're ready, go to the next page.
* Required
1. Your email *
2. Occupation *
What is your job title? What is your task
assignment (what is it that you do at your
workplace)?
3. Experience with CI-systems (build servers) *
Have you worked with CI-systems (build servers) before? Popular CI-systems include
TeamCity, Hudson, Jenkins, Bamboo and CruiseControl.
Mark only one oval.
Yes
No
After the last question in this section, stop filling out this form.
4. Experience with which CI-systems?
If you answered "Yes" to the question
above, please list the CI-systems that you
have experience with:
5. Experience with TeamCity *
Have you worked with TeamCity before?
Mark only one oval.
Yes
No
6. Notification of study results *
Would you like to be notified of the results of this study?
Mark only one oval.
Yes
No
7. Task 1: Navigate to the " settings" section
of TeamCity
You are currently in the "Overview page". (1)
Navigate to "Administration". (2) Look at the
sidebar to the left. (3) Look at the 3 items
nested under "Integrations". Which item is
located in-between "Issue Tracker" and
"Tools"?:
8. Check all that apply.
Unable to complete task
9. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
10. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
11. Task 2: Change " Authentication" settings and revert the changes
You are currently in the "Administration page". (1) Navigate to "Authentication". (2)
Change the guest user username to "guest123" and (3) save the changes. Next, (4)
revert the changes and (5) confirm that the default settings were restored. Were you able
to successfully make changes and revert the changes?
Mark only one oval.
Yes
No (please explain why below)
12. Check all that apply.
Unable to complete task
13. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
5
low satisfaction
high satisfaction
14. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
15. Task 3: Navigate to " Usage Statistics"
(1) Navigate to "Usage Statistics". What
"java runtime version" is the server running?
(Hint: feel free to use ctrl+F)
16. Check all that apply.
Unable to complete task
17. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
18. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
19. Task 4: Hide a visible project
(1) Navigate back to the "Overview page" (the first page you were presented with) and (2)
hide the project "dt3-robotlego-2012ht-white". Only "ci-research-teamcity-test-project"
should be visible.
Check all that apply.
Done
20. Check all that apply.
Unable to complete task
21. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
22. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
23. Task 5: Verify if a project is stable or broken
Judging by what you can see on the current page ("Overview page"), (1) is the current
build of "ci-research-teamcity-test-project" stable or broken? (You may click on different
elements on this page, but do not navigate from the "Overview page")
Mark only one oval.
Stable
Broken
24. Check all that apply.
Unable to complete task
25. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
5
low satisfaction
high satisfaction
26. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
27. Task 6: Read a commit log message
(1) Navigate to "Changes" to pull information
from the connected VCS. What is the
commit log message of revision 29,
committed "14 Sep 14 19:11"? (Hint: feel
free to copy-paste the message instead of
typing it manually, try right-clicking and
selecting "copy" if ctrl+C is unresponsive)
28. Check all that apply.
Unable to complete task
29. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
30. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
31. Task 7: Expand the details of a revision
(1) Expand revision 29 and specify the name
of the .java file that was edited:
test/packdemo/______
32. Check all that apply.
Unable to complete task
33. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
34. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
35. Task 8: Review code changes of a
revision
(1) Open the changed file of revision 29
(test/packdemo/Test01.java) and specify
what line in that .java source code file was
modified. An example of the "code difference
view" is shown above (lines 22-27 were
removed and lines 37-43 were added). Line
____ was modified in Test01.java for
revision 29:
36. Check all that apply.
Unable to complete task
37. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
low satisfaction
3
4
5
high satisfaction
38. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
39. Task 9: Navigate to the " build" section
The "Build page" of TeamCity is the same page as the “Overview page", (1) navigate to
this page.
Check all that apply.
Done
40. Check all that apply.
Unable to complete task
41. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
5
low satisfaction
high satisfaction
42. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
43. Task 10: Compile the source code for a project
Source code is compiled by clicking on the "run" button and triggering a build. (1) Trigger
a build and wait for it to finish.
Check all that apply.
Done
44. Check all that apply.
Unable to complete task
45. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
46. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
47. Task 11: Run unit tests for a project
Unit tests are also run by triggering a build. (1) Trigger another build and wait for it to
finish.
Check all that apply.
Done
48. Check all that apply.
Unable to complete task
49. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
low satisfaction
5
high satisfaction
50. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
51. Task 12: Open up a build log and verify
unit test results
(1) Navigate to the "Build Log" from the
"Overview page" by accessing (clicking on) a
specific build. Builds are denoted by a
hashtag, f.e. #3 or #25. (2a) The build step
"Step 1/1: Ant" should contain information
about the unit tests that were performed.
Alternatively, you may (2b) switch from the
"Build Log" tab to the "Tests" tab. Please
specify the name of any of the 2 unit tests
that were run: testSt_____ or testCa______
52. Check all that apply.
Unable to complete task
53. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
5
low satisfaction
high satisfaction
54. If you were unable to perform the task, please explain why
Why were you unable to perform the task? (What was the main obstacle in performing
this task, what made it difficult to perform this task?)
55. Task 13: Stop a running build
(1) Go back to the "Overview page" and (2) start a build. Now, (3) stop it before it finishes
running. Were you prompted with a confirmation dialog when you stopped the build?
Mark only one oval.
Yes
No
56. Check all that apply.
Unable to complete task
57. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
58. If you were unable to perform the task, please explain why
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
59. Task 14: Create a new build configuration
(1) Navigate to "Administration" and (2) click on the "ci-research-teamcity-test-project" to
access the general settings of the project. You should now be located in
"Administration/<Root project>/ci-research-teamcity-test-project". As you can see there is
currently one build configuration called "buildconfig3". (3) Copy that build configuration
and (4) name your new build configuration "buildconfig4". (5) Navigate back to the
general settings of your project following the same instructions given at the start of this
task. You should now see two build configurations, "buildconfig3" and "buildconfig4".
Check all that apply.
Done
60. Check all that apply.
Unable to complete task
61. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
low satisfaction
5
high satisfaction
62. If you were unable to perform the task, please explain why
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
63. Task 15: Add a build step to your build
configuration
(1) Click on "buildconfig4" to access the
settings of that build configuration. The
sidebar on the left-hand side provides
access to various settings and aspects of
the build configuration. (2) Add a build step
to the build configuration and (3) choose
Command Line as the build runner type from
the list. In the "Enter build script content"
field you can (4) enter the following: "@echo
Hello World!". Once this has been done and
you have (5) saved your work you can (6)
navigate to the "Overview page" and (7) run
"buildconfig4" and then (8) access the "Build
Log" to verify the results of your work. (9)
Expand "Step 2/2: Command Line" and
specify the message of the third line (above
"Process exited with code 0"):
64. Check all that apply.
Unable to complete task
65. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
2
3
4
5
low satisfaction
high satisfaction
66. If you were unable to perform the task, please explain why
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
67. Task 16: Add a schedule trigger to your build configuration
(1) Navigate back to the settings of "buildconfig4". (2) Add a new trigger to your build
configuration ("buildconfig4"). (3) Choose a "schedule trigger" from the list. (4) Change
some default settings around so that the build triggers "weekly" on "Tuesday" at "07:00".
(5) Save the trigger settings and a new trigger should now appear in the list of "Triggers".
Check all that apply.
Done
68. Check all that apply.
Unable to complete task
69. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
70. If you were unable to perform the task, please explain why
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
71. Task 17: Delete a build configuration
(1) Navigate back to the general settings of the project "ci-research-teamcity-test-project"
where an overview of build configurations are presented. (2) Delete "buildconfig4". Were
you prompted with a confirmation dialog when you were about to delete the build
configuration?
Mark only one oval.
Yes
No
72. Check all that apply.
Unable to complete task
73. User satisfaction *
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Mark only one oval.
1
low satisfaction
2
3
4
5
high satisfaction
74. If you were unable to perform the task, please explain why
Were you able to perform this task with ease? What is your overall satisfaction of
performing this task?
Conclussion and impression of TeamCity (from a usability
standpoint)
75. How well does TeamCity support " Learnability" ?
Is it easy to learn and use TeamCity? Is the design clear and does it enable you to
remember how to "do things" in TeamCity?
Mark only one oval.
1
2
3
4
5
low learnability
high learnability
76. Check all that apply.
Don't know / no comment
77. How well does TeamCity support " Efficiency of use" ?
Is it easy to do certain things without "unecessary steps"? Can you cut down on time by
making use of certain functionality (f.e. easy to edit, copy or delete a large number of
objects)?
Mark only one oval.
1
2
3
4
5
low efficiency of use
high efficiency of use
78. Check all that apply.
Don't know / no comment
79. How well does TeamCity support " Reliability" ?
Is TeamCity reliable? If you accidentally make an error, is it easy to undo/revert changes
and recover from the error?
Mark only one oval.
1
2
3
4
5
low reliability
high reliability
80. Check all that apply.
Don't know / no comment
81. How well does TeamCity support " Satisfaction" ?
What is your overall satisfaction with using TeamCity? Is it usable?
Mark only one oval.
1
2
low satisfaction
82. Check all that apply.
Don't know / no comment
3
4
5
high satisfaction
Bilaga 8
Demo01.java
1 /**
2 * @author Petrus K.
3 */
4 package packdemo;
5
6 public class Demo01 {
7
8
9 /** ­­­Demo methods­­­ **/
10
public String demoStringConcatenate(String str1, String str2) {
11
return str1 + str2;
12
}
13
14
public int demoCalcSum(int int1, int int2) {
15
return int1+int2;
16
}
17
18
19
20 /** ­­­run method­­­
**/
21
public void run() {
22
System.out.println("­­running Demo01­­");
23
System.out.println("demoStringConc:\t"+demoStringConcatenate("hello", "world"));
24
System.out.println("demoCalcSum:\t"+demoCalcSum(5, 10));
25
System.out.println();
26
}
27
28
29 /** ­­­main method­­­
**/
30
public static void main(String[] args){
31
Demo01 d1 = new Demo01();
32
d1.run();
33
34
Demo02 d2 = new Demo02();
35
d2.run();
36
}
37 }
38
Page 1
Demo02.java
1 /**
2 * @author Petrus K.
3 */
4 package packdemo;
5
6 public class Demo02 {
7
8 /** ­­­Demo methods­­­ **/
9
private void demoPlaceholder() {
10
System.out.print("Demo02 isn't doing anything..");
11
new UnsupportedOperationException("Demo02 isn't doing anything..");
12
}
13
14 /** ­­­run method­­­
**/
15
public void run() {
16
System.out.println("­­running Demo02­­");
17
System.out.print("demoPlacehold:\t");
18
demoPlaceholder();
19
System.out.println();
20
}
21
22 }
23
Page 1
Test01.java
1 package packdemo;
2
3 import static org.junit.Assert.*;
4 import org.junit.*;
5
6 public class Test01 {
7
8
Demo01 d1 = new Demo01();
9
10 /** ­­­setup and teardown methods­­­
**/
11
// this method does a one­time setup before all tests are run in this test class
12
@BeforeClass
13
public static void setUpBeforeClass() throws Exception {
14
System.out.println("­­running Test01­­");
15
System.out.println("no. of test cases in this suite:
"+suite().countTestCases()+"\n");
16
}
17
18
19 /** ­­­Test cases­­­
**/
20
@Test
21
public void testStringConcatenate() {
22
assertEquals("something is wrong with Demo01.demoStringConcatenate",
23
"hello", d1.demoStringConcatenate("he", "llo"));
24
System.out.println("testStringConcatenate has passed successfully");
25
}
26
27
@Test
28
public void testCalcSum() {
29
assertEquals("something is wrong with Demo01.demoCalcSum",
30
30, d1.demoCalcSum(10, 20));
31
System.out.println("testCalcSum has passed successfully");
32
}
33
34
35 /** ­­­custom methods used by this class­­­ **/
36
public static junit.framework.Test suite() {
37
return new junit.framework.JUnit4TestAdapter(Test01.class);
38
}
39
40 }
41
Page 1
build_custom.xml
1 <?xml version="1.0" encoding="UTF­8" standalone="no"?>
2 <!­­
Author:
Petrus K.
3
Description:
A custom ant build script based on an auto­generated script by Eclipse 4.4.0
4
More info:
http://ant.apache.org/manual/using.html
5 ­­>
6
7 <!­­ project attributes ­­>
8 <project basedir="." default="build" name="ci­research­teamcity­test­project">
9
<description>
10
simple ant build script for demonstrational purposes
11
</description>
12
13
<!­­ properties ­­>
14
<property name="src.dir" location="src"/>
15
<property name="bin.dir" location="bin"/>
16
<property name="test.dir" location="test"/>
17
<property name="test.report.dir" location="testreport"/>
18
<property name="lib.dir" location="lib"/>
19
20
<!­­ paths ­­>
21
<path id="classpath">
22
<pathelement location="lib/junit­4.11.jar"/>
23
<pathelement location="lib/hamcrest­core­1.3.jar"/>
24
<pathelement location="${bin.dir}"/>
25
</path>
26
27
<!­­ targets ­­>
28
<!­­ TARGET init: initializes file and folder structures before compilation ­­>
29
<target name="init" description="initializes file and folder structures before compilation">
30
<mkdir dir="${bin.dir}"/>
31
<mkdir dir="${test.report.dir}"/>
32
33
<echo message="init completed"/>
34
</target>
35
36
<!­­ TARGET build: compiles the source ­­>
37
<target name="build" depends="init" description="compiles the source">
38
<javac srcdir="${src.dir}" destdir="${bin.dir}" includeantruntime="false"
compiler="modern">
39
<classpath refid="classpath"/>
40
</javac>
41
<javac srcdir="${test.dir}" destdir="${bin.dir}" includeantruntime="false"
compiler="modern">
42
<classpath refid="classpath"/>
43
</javac>
44
45
<echo message="build completed"/>
46
</target>
47
48
<!­­ TARGET clean: cleans the compiled files ­­>
49
<target name="clean" description="cleans the compiled files">
50
<delete dir="${bin.dir}"/>
51
<delete dir="${test.report.dir}"/>
52
53
<echo message="clean completed"/>
54
</target>
55
56
<!­­ TARGET run: runs the demo project ­­>
57
<target name="run" depends="build" description="runs the demo project">
Page 1
build_custom.xml
58
<java classname="packdemo.Demo01" failonerror="true" fork="yes">
59
<classpath refid="classpath"/>
60
</java>
61
62
<echo message="run completed"/>
63
</target>
64
65
<!­­ TARGET test: runs JUnit tests ­­>
66
<target name="test" depends="build">
67
<junit printsummary="withOutAndErr" fork="true" haltonfailure="yes">
68
<classpath refid="classpath"/>
69
<classpath>
70
<pathelement location="${bin.dir}" />
71
</classpath>
72
<formatter type="xml"/>
73
<batchtest todir="${test.report.dir}">
74
<fileset dir="${test.dir}">
75
<include name="**/*Test*.java" />
76
</fileset>
77
</batchtest>
78
</junit>
79
</target>
80
81 </project>
Page 2
Bilaga 9
Systemspecifikationer för CI­server (TeamCity) Hårdvara: ● CPU:
● RAM:
● HDD:
● Nätverkskort:
● Bandbredd:
Inter® Core™ 2 CPU 6300 @ 1.86GHz 1.87GHz, x64-based
4.00 GB
931 GB
Intel® 82566DM Gigabit Network Connection
1000.00 Mbit/s
Mjukvara och miljö:
● OS:
● TeamCity:
● XAMPP:
● Eclipse Luna:
● Apache Ant:
● TeamViewer:
● TortoiseSVN:
Windows 8 Enterprise (2012), 64-bit
8.1.1 (build 29939)
1.8.2
4.4.0
1.9.4
9.0
1.8.8