Q3: Tidigare under examensarbetet har du deltagit vid en demonstration av byggsystemet och dess funktionalitet. Hur tror du att ett sådant system skulle kunna använda för att öka kvalitén på applikationerna ni utvecklar? Det uppskattas om du motiverar ditt svar, diskuterar frågan och/eller ger exempel relaterade till frågan.
Q4: Tidigare under examensarbetet har du deltagit vid en demonstration av byggsystemet och dess funktionalitet. Om du minns, beskriv ett eller flera exempel på situationer i ditt arbete där ett sådant system skulle vara användbart.
B.3
Answers
Attendant 1:
Q1: Upp till ett fåtal gånger per månad. Den vanligaste orsaken är att någon glömt att checka in en nödvändig fil, eller att ny funktionalitet inte blivit testad på både Android och iOS. Q2: Det går oftast ganska fort att rätta till. I fallet att en fil glömts går det väldigt fort att rätta till. Om tex projektfilen på iOS inte har blivit uppdaterad är det också oftast enkelt att fixa. Det som brukar ta mest tid är själva konstaterandet att det är något från repositoriet som inte fungerar och inte något jag själv gjort.
Q3: Det kommer att underlätta mycket vid releaser, både vid själva byggandet av releasen då vi kan vara säkra på att det är exakt det som är i vårt repository som byggs, samt om vi vill gå tillbaka och testa eller patcha en tidigare release. Förhoppningsvis kommer byggsystemet även att fånga en del plattformsspecifika problem, som att en utvecklare pushat in kod som fungerar bra på en plattform men som inte bygger på en annan. Detta borde leda till att vi blir bättre på att testa innan inpushning.
Q4: Vi gör kontinuerliga releaser av ett stort konsultprojekt. Det har hänt att felaktiga in- ställningar har kommit med i releasebyggar, något som vi skulle ha sluppit med ett bra byg- gsystem. I andra projekt har vi haft problem med att gå tillbaka och bygga en tidigare släppt version då vi inte tillräckligt bra dokumenterat hur uppsättningen vid releasebyggen såg ut. Även detta skulle kunna ha lösts med ett bra byggsystem.
Attendant 2:
Q1: Jag uppskattar att det händer ca 20% av gångerna jag gör en git pull.
Q2: Ofta tar det kort tid att identifiera problemet och få hjälp av den som missat något vid incheckningen. Brukar vara fixat inom 15 minuter. Det är mer ett irritationsmoment än något som stjäl mycket arbetstid.
Q3: Framförallt så kommer alla applikationer att byggas på samma sätt, så risken för byg- gfel i en release minimeras. Den kontinuerliga integrationen gör också att små misstag, som att man glömt checka in en fil, upptäcks av ett system snarare än en annan utvecklare. Nå- got som bör göra att arbetet flyter bättre. Vi kan också få bättre kvalitet med hjälp av mer omfattande testfall, utan att komplicera den vanliga utvecklingsmiljön. Testfall som testar specifika delar av en applikation körs vanligtvis av den utvecklare som jobbar på den delen av applikationen. Genom att byggsystemet kör alla tester kan vi vara säkra på att vi inte får regressioner, utan att alla utvecklare behöver sätta sig in i alla olika testfall. I ett längre perspektiv kommer det att underlätta stort för att hålla koll på status på applikationer som släppts. Vi kommer enkelt och snabbt kunna skapa nya releaser om vi exempelvis hittar säkerhetshål i de bibliotek vi använder.
B.3. Answers
Q4: För mig skulle det vara användbart att få en bekräftelse på att jag checkat in alla filer och att testfall fortfarande fungerar, utan att för den skull göra en omfattande manuell process vid varje incheckning. Det vore också väldigt bra att kunna göra nya releaser av vilket projekt som helst utan att manuellt behöva sätta upp en releasemiljö. Det finns massa detaljer som skiljer utvecklingsmiljön från releasemiljön och det är lätt att glömma något när man inte bygger releaser så ofta. Med ett byggsystem räcker det med att trycka på en knapp och så kan man vara säker på att alla moment utförs automatiskt
Attendant 3:
Q1: Någon gång per vecka. Detta är olika beroende på vad jag jobbar med. Har man inte jobbat i ett projekt ett tag är sannolikheten större att förändringar skett som ger en icke- fungerande bygg.
Q2: Oftast tar det mellan 5-15 minuter men kan mera sällan ta 30-60 minuter vid större förän- dringar.
Q3: Release-hantering är en stor grej för oss. Att låta byggsystemet hantera releaser gör att vi kan frånkoppla individuella utvecklare från den hanteringen och därmed ta bort beroendet på individen.
Q4: Eftersom vårt ramverk, Coffee, är multi-plattorm så är det en stor fördel att systemet kan bygga för alla dessa plattformar och direkt visa om någon plattform inte bygger releaser av någon anledning. Lägger man till en plattformsspecifik funktion så tvingas man se till att det bygger på andra plattformar. Att kunna plocka fram och bygga gamla releaser av appar kan vara jätteviktigt. T.ex. kan man behöva patcha en app utan att lägga tiden det tar att uppgradera till den senaste versionen av Coffee.
Bibliography
[1] Mathias Meyer. “Continuous Integration and Its Tools”. In: IEEE Software 31.3 (2014), pp. 14–16. ISSN: 0740-7459. DOI: 10 . 1109 / MS . 2014 . 58. URL: http : / / ieeexplore . ieee . org / ielx7 / 52 / 6802981 / 06802994 . pdf ? tp = %7B % 5C & %7Darnumber = 6802994 % 7B % 5C & %7Disnumber = 6802981 $ %5Cbackslash $ nhttp : / / ieeexplore . ieee . org / xpl / articleDetails . jsp ? arnumber = 6802994 % 7B % 5C & %7DsortType % 7B % %7D3Dasc % 7B % 5C _ %7Dp % 7B % 5C _ %7DSequence % 7B % %7D26filter % 7B % %7D3DAND % 7B % %7D28p % 7B % 5C _ %7DIS % 7B%5C_%7DNumber%7B%%7D3A6802981%7B%%7D29.
[2] K. Beck. “Embracing change with extreme programming”. In: Computer 32.10 (1999), pp. 70–77.ISSN: 00189162.DOI: 10.1109/2.796139.URL: http://dl.acm.org/ citation.cfm?id=619045.621348.
[3] Ade Miller. “A hundred days of continuous integration”. In: Proceedings - Agile 2008 Conference (2008), pp. 289–293.DOI: 10.1109/Agile.2008.8i.
[4] W W Royce. “Managing the development of large software systems”. In: Electronics 26.August (1970), pp. 1–9.ISSN: 03784754.DOI: 10.1016/0378-4754(91)90107-E.
URL: http://www.pi.informatik.tu-darmstadt.de/fileadmin/user%7B% 5C_%7Dupload/Group%7B%5C_%7DPI/LV%7B%5C_%7D%7B%5C_%7DSE%7B%5C_ %7DRE/R%7B%5C_%7D01%7B%5C_%7DWasserfallmodell%7B%5C_%7D%7B%5C_ %7DFolien%7B%5C_%7D%7B%5C_%7DSchwaiger.pdf.
[5] Jez Humble and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Pearson Education, Inc., 2011. ISBN: 9780321601919.
[6] Stefan Dösinger, Richard Mordinyi, and Stefan Biffl. “Communicating continuous inte- gration servers for increasing effectiveness of automated testing”. In: Proceedings of the 27th IEEE/ACM International Conference on Automated Software Engineering - ASE 2012 (2012), p. 374.DOI: 10 . 1145 / 2351676 . 2351751. URL: http : / / dl . acm . org / citation.cfm?id=2351676.2351751.
[7] Daniel Ståhl and Jan Bosch. “Modeling continuous integration practice differences in industry software development”. In: Journal of Systems and Software 87.1 (2014), pp. 48– 59.ISSN: 01641212.DOI: 10.1016/j.jss.2013.08.032.URL: http://dx.doi. org/10.1016/j.jss.2013.08.032.
[8] Saba Hamdan and Suad Alramouni. “A Quality Framework for Software Continuous Integration”. In: Procedia Manufacturing 3.Ahfe (2015), pp. 2019–2025.ISSN: 2351-9789.
DOI: 10.1016/j.promfg.2015.07.249.URL: http://dx.doi.org/10.1016/ j.promfg.2015.07.249.
[9] P Runeson. “A survey of unit testing practices”. In: IEEE Software 23.4 (2006), pp. 22–29.
ISSN: 0740-7459.DOI: 10.1109/MS.2006.91.URL: http://ieeexplore.ieee.
Bibliography
[10] David Saff and Michael D. Ernst. “An experimental evaluation of continuous testing during development”. In: ACM SIGSOFT Software Engineering Notes 29.4 (2004), p. 76.
ISSN: 01635948.DOI: 10.1145/1013886.1007523.
[11] John Downs, Beryl Plimmer, and John G Hosking. “Ambient awareness of build status in collocated software teams”. In: 34th International Conference on Software Engineering, ICSE 2012 (2012), pp. 507–517.ISSN: 0270-5257.DOI: 10.1109/ICSE.2012.6227165. [12] John Downs, John Hosking, and Beryl Plimmer. “Status communication in agile soft- ware teams: A case study”. In: Proceedings - 5th International Conference on Software En- gineering Advances, ICSEA 2010 (2010), pp. 82–87.DOI: 10.1109/ICSEA.2010.20. [13] Romain Pouclet et al. Pro iOS continuous integration. [Elektronisk resurs]. [New York] :
friends of ED/Apress, c2014, 2014.ISBN: 9781484201251.
[14] Spyros Xanthopoulos and Stelios Xinogalos. “A Comparative Analysis of Cross- platform Development Approaches for Mobile Applications”. In: Proceedings of the 6th Balkan Conference in Informatics (2013), pp. 213–220. DOI: 10 . 1145 / 2490257 . 2490292.URL: http://doi.acm.org/10.1145/2490257.2490292.
[15] Per Runeson and Martin Höst. “Guidelines for conducting and reporting case study re- search in software engineering”. In: Empirical Software Engineering 14.2 (2009), pp. 131– 164.ISSN: 1382-3256.DOI: 10.1007/s10664- 008- 9102- 8.URL: http://link. springer.com/10.1007/s10664-008-9102-8.
[16] Timothy C. Lethbridge, Susan Elliott Sim, and Janice Singer. “Studying software en- gineers: Data collection techniques for software field studies”. In: Empirical Software Engineering 10.3 (2005), pp. 311–341. ISSN: 13823256.DOI: 10.1007/s10664- 005-
1290-x.
[17] Scott Chacon and Ben Straub. Pro Git. 2, revised. Apress, 2014.ISBN: 9781484200766. [18] Vincent Driessen. A successful Git branching model. 2010.URL: http : / / nvie . com /
posts/a-successful-git-branching-model/(visited on 04/20/2016).
[19] Jussi Judin. A succesful Git branching model considered harmful. 2016.URL: https : / / barro . github . io / 2016 / 02 / a - succesful - git - branching - model - considered-harmful/(visited on 04/20/2016).
[20] John Ferguson Smart. Jenkins: The Definitive Guide. O’Reilly Media, 2011. ISBN: 9781449313654.URL: https://books.google.se/books?id=4bjDCQAAQBAJ.