docOn The Minimum dys - Al-Zara_20150119 - MUEP
download 
Report Transcription
On The Minimum dys - Al-Zara_20150119 - MUEP
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 onetime 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="UTF8" standalone="no"?> 2 <! Author: Petrus K. 3 Description: A custom ant build script based on an autogenerated 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="ciresearchteamcitytestproject"> 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/junit4.11.jar"/> 23 <pathelement location="lib/hamcrestcore1.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 CIserver (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
