CI/CD i molnapplikationer som Google Cloud, Azure och AWS

Linköpings universitet SE–581 83 Linköping

Vårterminen 2019 | LIU-IDA/LITH-EX-G--19/003--SE

CI/CD i molnapplikationer som

Google Cloud, Azure och AWS

CI/CD in cloud applications like Google Cloud, Azure and AWS

Anton Andell

Nigel Cole

Wiktor Karlsson

Eric Lilja

Diba Rezaie

David Thimren

Andreas Zeijlon

Handledare : Jonas Wallgren Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Anton Andell Nigel Cole Wiktor Karlsson Eric Lilja Diba Rezaie David Thimren Andreas Zeijlon

Under VT 2019 ägde projektet rum varav denna rapport är ett av resultaten. Projektets mål var att skapa en CI/CD pipeline vars syfte var tänkt att frekvent kunna leverera fär-digtestad kod till olika molntjänster som Google Cloud Platform, Amazon Web Services och Azure. Projektspecifikationerna gavs av företaget Skira för att skapa en snabbare in-tegrationsprocess för nya utvecklare. Detta så en ny utvecklare skulle kunna lägga mer tid på att koda istället för att gräva ner sig i leverans-/testningsprocessen. Slutprodukten ger företag möjligheten att koda direkt på sitt utvecklingskluster.

Författarens tack

Projektgruppen vill rikta ett stort tack till vår kund Skira som har gett oss möjligheten och resurserna för att genomföra projektet! Vi vill speciellt tacka Joel Glemne på Skira som funnits tillgänglig för rådgivning och givit oss tips och vägledning genom projektets gång. Vi vill slutligen även tacka vår handledare Jonas Wallgren som bistått med feedback och trevliga handledarmöten, och gett oss goda råd på hur gruppen kan förbättra sin presentationsteknik. Tack allihopa!

Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller ix Introduction 1 1 Inledning 3 1.1 Motivering . . . 3 1.2 Syfte . . . 3 1.3 Frågeställning . . . 3 1.4 Avgränsningar . . . 4 2 Bakgrund 5 2.1 Kundens syfte . . . 5 2.2 Tidigare erfarenheter . . . 6 3 Teori 7 3.1 Code-server . . . 7 3.2 Kontinuerlig integration . . . 7 3.3 Kontinuerlig distribution . . . 7 3.4 Pipeline . . . 7 3.5 Mikrotjänster i Kubernetes . . . 8

3.6 Google Cloud Platform . . . 8

3.7 Docker . . . 8

3.8 Telepresence . . . 8

3.9 Spinnaker . . . 8

3.10 YAML . . . 8

3.11 Git och Git hook . . . 8

3.12 Molntjänster . . . 9

3.13 Canary-distribuering . . . 9

3.14 Seleniumtestning . . . 9

3.15 Google Cloud Registry . . . 9

4 Metod 10 4.1 Kravinsamling . . . 10

4.2 Scrum . . . 10

4.4 Utbildning . . . 12 4.5 Erfarenhetsuppfångning . . . 12 5 Resultat 13 5.1 Systembeskrivning . . . 13 5.2 Gemensamma erfarenheter . . . 19 5.3 Värde för kunden . . . 19 5.4 Kvalitetskrav . . . 20

5.5 Översikt över individuella bidrag . . . 20

6 Diskussion 22 6.1 Resultat . . . 22

6.2 Metod . . . 24

6.3 Arbetet i ett vidare sammanhang . . . 26

7 Slutsats 28 A Decentraliserade moln och molntjänster av Anton Andell 30 A.1 Inledning . . . 30 A.2 Bakgrund . . . 31 A.3 Teori . . . 31 A.4 Metod . . . 32 A.5 Resultat . . . 32 A.6 Diskussion . . . 34 A.7 Sammanfattning . . . 36

B Ger en microservice-arkitektur snabbare kodleverans till slutanvändare av Eric Lilja 37 B.1 Inledning . . . 37 B.2 Bakgrund . . . 38 B.3 Teori . . . 39 B.4 Metod . . . 39 B.5 Resultat . . . 40 B.6 Diskussion . . . 41 B.7 Slutsats . . . 43

C En jämförelse mellan muterbar och icke-muterbar serverinfrastruktur av Andreas Zeijlon 44 C.1 Inledning . . . 44 C.2 Bakgrund . . . 45 C.3 Teori . . . 45 C.4 Metod . . . 45 C.5 Resultat . . . 46 C.6 Diskussion . . . 47 C.7 Slutsats . . . 48

D Datasäkerhet inom molntjänster - en litteraturstudie av Nigel Cole 49 D.1 Inledning . . . 49 D.2 Bakgrund . . . 50 D.3 Teori . . . 50 D.4 Metod . . . 51 D.5 Resultat . . . 51 D.6 Diskussion . . . 54 D.7 Slutsatser . . . 55

E.2 Bakgrund . . . 57 E.3 Teori . . . 58 E.4 Metod . . . 59 E.5 Resultat . . . 60 E.6 Diskussion . . . 61 E.7 Slutsatser . . . 62

F För- och nackdelar med Dockercontainrar jämfört med virtuella maskiner av Wik-tor Karlsson 63 F.1 Inledning . . . 63 F.2 Bakgrund . . . 64 F.3 Teori . . . 64 F.4 Metod . . . 65 F.5 Resultat . . . 66 F.6 Diskussion . . . 67 F.7 Slutsats . . . 69

G Klimatpåverkan av molntjänster av Diba Rezaie 70 G.1 Inledning . . . 70 G.2 Bakgrund . . . 71 G.3 Teori . . . 71 G.4 Metod . . . 73 G.5 Resultat . . . 73 G.6 Diskussion . . . 74 G.7 Slutsatser . . . 75 Litteratur 76

Figurer

2.1 Hur en CI/CD pipeline kan se ut. . . 6

5.1 Översikt av systemet. Dev syftar på utvecklingsklustret; Prod syftar på produk-tionsmiljön. . . 14

5.2 Ett flödesschema över inloggningen till systemet. . . 15

5.3 Visual Studio Code som körs med Ubuntu tillgänglig via en webbläsare. . . 15

5.4 Inloggningsidan för en utvecklare på utvecklingsklustret. Här loggar man in och skickas vidare till sin personliga Code-server-instans. . . 16

5.5 Överblick över ett kluster och ett par Code-server instanser som ligger och kör i utvecklingsklustret. . . 17

5.6 Systemanatomi . . . 18

A.1 En bild av hur framtida molnet och internet kan vara uppbyggt.[66] . . . . 34

E.1 Uppdelning av kvalitetskostnad . . . 59

Definitionslista

A/B-leverans A/B-leverans är en strategi där två olika kodversioner exponeras mot varsin halva av slutanvändarna. Kombinerat med datainsamling och statistik används det för beslutsunderlag.

AWS AWS är en förkortning för Amazon Web Services och är en molntjänst som företaget Amazon erbjuder.

Azure Azure är en molntjänst som företaget Microsoft erbjuder erbjuder.

Bambi Bambi är namnet på systemet som projektgruppen har utvecklat.

Canary leverans Canary leverans är en distributionsstrategi där en liten del av användarba-sen får tillgång till en ny version som successivt sprids till fler användare om inga fel inträffat.

CD CD står för Continous Deployment och är en strategi för distribution av kod där koden passerar automatiserade tester innan den släpps ut i produktion.

CI CI står för Continous Integration och är en utvecklingsstrategi där utvecklare integrerar sin kod flera gånger om dagen i en delad kodbas. Genom detta går det att detektera problem tidigt.

Container Container är mjukvara som packar upp kod och all dess beroenden.

Fjärrutveckling Fjärrutveckling innebär utveckling mot en extern miljö där kommunikatio-nen sker över internet.

GCP GCP är en förkortning för Google Cloud Platform och är en molntjänst företaget Google erbjuder.

Git Git är ett versionshanteringsprogram.

Git hook Git hook är det generella namnet på de skript som körs, om man ställer in dem, vid olika gitkommandon.

Hot reload Hot reload är en automatisk systemombyggning vid förändring av källkod.

Microservice-arkitektur Microservice-arkitektur är en server som består av olika delsystem som sammarbetar.

Mikrotjänst Mikrotjänst är ett självständigt delsystem som tillsammans med andra mikro-tjänster utgör ett helt system.

Nodemon Nodemon är ett verktyg som har möjlighet att övervaka en fil för kodförändringar och starta om den i dess fall.

Pipeline Pipeline är en serie processer som ska utföras.

Skaffold Skaffold är ett bibliotek som kan användas för att lyssna på kodändringar och byg-ga om koden vid ändring.

TCP TCP står för Transmission Control Protocol och är ett kommunikationsprotocol som används på internet i stor utsträckning för kommunikationer mellan två datorer.

User story User story är en kort beskrivning av vad en användare vill uppnå. User stories är ett snabbt sätt att hantera kravställning.

1

Inledning

Detta kapitel går igenom syftet med projektet, motivering till varför projektet behövs, vilka frågeställningar som projektmedlemmarna har arbetat med och de avgränsningar som pro-jektet hade.

1.1

Motivering

När en mjukvaruutvecklare ska påbörja sitt nya jobb kan det läggas väldigt mycket tid på att sätta upp miljön på arbetsdatorn. Drömscenariot hade varit att med några kommandon kunna sätta upp miljön och kunna distribuera kod utan några krångligheter. Denna rapport innehåller ett förslag till en lösning på det problemet - Bambi. Med hjälp av Bambi går det att lösa varje ny mjukvaruutvecklares problem och det hjälper företaget att vinna tid på att deras anställda direkt kan börja bidra till företagets kodbas.

1.2

Syfte

Syftet med denna rapport var att ge en detaljerad beskrivning av hur Bambi fungerar och hur utvecklingsprocessen har gått till för att slutresultatet skulle uppnås. Projektet skapades av företaget Skira och handlar om CI/CD i molnapplikationer som Google Cloud, Azure och AWS. Projektet utfördes med öppen källkod där tanken är att både företag och privatpersoner ska kunna ta del av resultatet.

1.3

Frågeställning

Nedan följer de frågeställningar som lade grunden för vad projektet fokuserade på. 1. Hur kan Bambi implementeras för att skapa värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan vara intres-santa för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur mycket av en CI/CD-pipeline-uppsättning kan automatiseras?

1.4

Avgränsningar

2

Bakgrund

Nedan följer bakgrunden till arbetet.

2.1

Kundens syfte

Projektgruppens kund Skira är ett ungt företag som skapades med syftet att ge bättre mat till fler människor, och har sedan det grundades utvecklat digitala tjänster för att skapa mer lönsamhet inom lantbruket [38]. Som många andra mindre företag vill man snabbt, enkelt och billigt kunna distribuera sina tjänster och har därför använt sig av molnlösningar för att åstadkomma detta. Det är också viktigt att smidigt kunna uppdatera sina tjänster, därför an-vänder Skira som många andra företag en microservice-arkitektur för att åstadkomma detta. För att göra utveckling och leverans av tjänster snabb och smidig arbetar man ofta med nå-gon sorts automatiserad pipeline. En pipeline ser huvudsakligen till att all kod som bidras till projektet håller god kvalitet och stämmer överens med de krav som företaget har specificerat. Detta gör att man med större säkerhet kontinuerligt kan leverera uppdateringar till kunder och samtidigt minimera risken att någonting går fel i sluttjänsten. Se fig. 2.1 för ett exempel på hur en pipeline kan se ut/fungera. Problemet med pipelines är ofta att det är mycket att konfigurera och sätta upp. Den består också av många olika oberoende delar som behöver extra ramverk för att kunna samarbeta på ett smidigt sätt.

Skira presenterade en idé om att bygga ett system som skulle göra just pipeline-processen enklare att sätta upp och enklare att jobba med. Målet är att en ny utvecklare ska kunna börja utveckla med endast ett kommando, med funktioner som hot reload, fjärrutveckling, auto-matisk testning och leverantörsagnotisk distribution. De ville även att det skulle göras med öppen källkod då de kände att det är funktioner de hade velat ha när de började. Alltså byggs systemet för att förhoppningsvis göra utveckling enklare för många molntjänst-utvecklare.

Figur 2.1: Hur en CI/CD pipeline kan se ut.

2.2

Tidigare erfarenheter

Projektgruppen som utförde detta består av sex tredjeårsstudenter på civilingenjörsprogram-met i datateknik och en i mjukvaruteknik. De viktigaste erfarenheterna under de tre åren är från kursen i programutvecklingsmetodik och de större projektkurserna konstruktion med mikrodatorer för datorteknikerna och ett AI-projekt för mjukvaruteknikern där man arbe-tade i grupper om sju respektive sex personer. Från dessa kunde vi ta erfarenheter för att sätta upp bra dokumentations- och kommunikationsstandarder tidigt. Det fanns också viss erfarenhet inom gruppen om agil utvecklingsmetodik vilket gjorde att vi kunde börja arbeta agilt snabbt och smidigt. Några gruppmedlemmar hade mer kunskap inom området för detta projekt vilket gjorde att vi kunde fråga varandra och komma igång snabbt med utvecklandet.

3

Teori

Nedan följer den teori som behövs som bas för att förstå arbetet.

3.1

Code-server

Code-server är ett öppen källkodsprojekt skapat av företaget Coder Technologies Inc [15]. Code-server är en vidareutveckling av Microsofts Visual Studio Code [63] som möjliggör användare att interagera med Visual Studio Code via en webbläsare.

3.2

Kontinuerlig integration

Kontinuerlig integration (CI) är en process som automatiserar en del av arbetsflödet genom att bygga systemet och testa det varje gång kodförändringar visas i versionshanteringen. Det-ta uppmuntrar utvecklare att dela med sig av kod och enhetstestning i den delade versions-hanteringen. En stor fördel är att CI låter utvecklare arbeta enskilt utan problem med integ-rationen av kod. Små integrationer sker hela tiden istället för att göra stora integrationer med långa mellanrum [44].

3.3

Kontinuerlig distribution

Kontinuerlig distribution (CD) är en praktik som anammas i allt högre grad av industriledare inom mjukvara. CD innebär att flera utvecklare av ett och samma system alla ska leverera kod så ofta som möjligt. Alla former av kodförändringar, till exempel nya funktioner och buggfixar ska autonomt kunna föras till produktion och användare på ett säkert, snabbt och hållbart sätt. Kod ska alltid vara distribuerbar [52].

3.4

Pipeline

En traditionell CI/CD pipeline startas genom en kodförändring i kodbasen. Detta kommer att bygga ihop kod och testa den med enhetstester och integrationstester. Sedan levereras den nya versionen av koden. I Bambi är pipelinen strukturerad lite annorlunda. Istället för

att bygga och testa kod genom pipelinen utförs de stadierna i utvecklingsmiljön och därefter levereras förändringarna till produktionsmiljö. [75].

3.5

Mikrotjänster i Kubernetes

Kubernetes är en plattform med öppen källkod för automatisk distribuering, skalning och hantering av behållare i ett kluster. Kubernetes används ofta med Docker, se 3.7. Mikrotjäns-ter strukturerar en applikation till flera självständiga tjänsMikrotjäns-ter. Fördelarna är modularitet, lätt-viktiga protokoll och att det är lättare att förstå, utveckla och testa. Bambi skapar inte själv Kubernetes-kluster men använder sig av redan skapade kluster som användare förser Bambi med [87].

3.6

Google Cloud Platform

Google Cloud Platform, även förkortat GCP, är en samling av molntjänster skapad av före-taget Google. Dessa tjänster består bland annat av lagring av diverse data, uppsättning och underhåll av Kuberneteskluster och körning av instanser av virtuella maskiner på Googles infrastruktur. Eftersom GCP är en samling molntjänster kan man dessutom välja var i världen man vill sätta upp sina resurser (Virtuella maskiner, Kuberneteskluster och så vidare) [39].

3.7

Docker

Docker är en typ av behållare som innehåller kod tillsammans med dess konfigurerade bero-enden i en separat miljö. Docker har öppen källkod och är världsledande inom sitt område. Det är ett lättviktigt, självständigt och exekverbart paket med programvara som innehåller allt nödvändigt för att köra en applikation. Det fungerar väldigt likt en virtuell maskin, en de-dikerad egen miljö som i praktiken är en egen dator. Den stora nyckelskillnaden är att Docker utnyttjar den lokala operativsystemkärnan istället för att ha ett eget operativsystem [27].

3.8

Telepresence

Telepresence är ett verktyg som hjälper till att avlasta lokala utvecklingsmiljöer genom att bara köra de tjänster som ska ändras lokalt. De andra tjänsterna körs på ett avlägset Kuberne-teskluster som de lokala tjänsterna kan kommunicera med och då beter sig som ett komplett kluster utan att behöva köra hela klustret lokalt [21].

3.9

Spinnaker

Spinnaker är ett verktyg för att distribuera tjänster till många olika moln. De ger också möjlig-heten till många olika bra strategier för hur tjänster ska distribueras, som till exempel canary distribuering, se 3.13 [88].

3.10

YAML

YAML är ett dataserialiseringsformat som är lättläst och bekvämt att använda. Det används ofta till konfigurationsfiler [100].

3.11

Git och Git hook

Git är ett versionshanteringsprogram. Det används för att kunna klona en kodbas från en ser-ver till en lokal miljö och dessutom kan lokal kod leser-vereras till serser-vern. När gitkommandon

3.12. Molntjänster

utförs kan man köra skript som reagerar på dessa kommandon. Dessa skript kallas för Git hooks och används för att utföra önskad logik [37].

3.12

Molntjänster

En molntjänst är en service tillhandahållen av en molntjänstleverantör och är tillgänglig för användare via internet och är ett alternativ till att en användare använder egna servrar. Moln-tjänster är lättanvända och skalar lätt, och både resurser och Moln-tjänster hanteras av molntjänstle-verantören. Det finns flera funktioner som onlinedatalagring och backupsystem. Användare betalar oftast för datakraften de använder vilket kan leda till stora skillnader i kostnader mellan lugna och hektiska perioder. Några stora leverantörer är Amazon Web Services och Google Cloud Platform [6].

3.13

Canary-distribuering

Canary-distribuering exponerar kodförändringar till en liten del av slutanvändarna för att riskminimera potentiella fel med nya förändringar. Då det endast sker till en liten andel av användarna har det därmed en relativt liten påverkan där förändringar snabbt kan återstäl-las vid fel. Tester för denna leverans är oftast automatiska och utförs vid avklarad testning. Denna typ av leverans tillåter utvecklingsteamet att snabbt evaluera resultatet av koden vare sig den nya koden gav de önskade resultaten eller inte [78].

3.14

Seleniumtestning

Selenium är ett verktyg som automatiserar webbläsare. Huvudsakligen används det för att automatisera webbapplikationer för teständamål. Testerna, som skapas av användaren, kan köras över olika webbläsare och plattformar som Windows, Linux och macOS. Selenium är kostnadsfritt och är tillgängligt som öppen källkod [45].

3.15

Google Cloud Registry

Google Cloud Registry (GCR) är en tjänst tillhandahållen av Google för att lagra ens Docker-containrar. [40] Används ofta i kombination med CI/CD för att ha ett samlat ställe att lagra och hantera sina mikrotjänser.

Nedan följer den metod som projektet har följt för att uppnå resultatet beskrivet i denna rapport.

4.1

Kravinsamling

Kraven för projektet samlades in från kunden Skira. Detta började med en projektgenomgång för vad projektet översiktligt skulle handla om. Efter det har två möten hållits med Skira för att mer specifikt samla in de krav som ställs på systemet. Speciellt under det andra mötet gav Skira en user story för att underlätta förståelsen för vem systemet var avsett för. Efter det skrevs en kravlista av alla gruppmedlemmarna i projektgruppen och sedan skickades denna in till kunden för bekräftelse att kraven stämde.

4.2

Scrum

Scrum är ett ramverk för att utveckla och underhålla komplexa produkter, och är mycket vanligt för programvaruutveckling. Det är en agil utvecklingsmetod som bygger på en ite-rativ arbetsprocess, där man delar in arbetet i korta perioder, så kallade sprintar. Gruppen valde att en sprint skulle vara ungefär två veckor lång. Inför varje sprint höll utvecklingsle-daren en planeringssession där gruppen bestämde vilka aktiviteter som skulle utföras under kommande sprint. Dessa aktiviteter samlades sedan i en lista som kallades backlog. Varje sprint avslutades med en återblick på vad som gick bra och vad som gick mindre bra under sprintens gång, och utifrån det infördes olika åtgärder inför nästa sprint.

Gruppen hade två statusmöten i veckan, ett på tisdagar och ett på fredagar. Under dessa möten berättade varje gruppmedlem vad de gjort sedan senaste mötet, vilka problem de hade stött på, vad de ska göra fram till nästa möte och vad som hindrar dem. Det var ett tillfälle för gruppen att inspektera hur långt de hade kommit i sprinten och om några åtgärder behövde tas. Mötena fick ta max 15 minuter.

Utvecklingsledaren agerade Scrum Master vars ansvar var att säkerställa att processen efterlevdes av projektgruppen, att synkronisera gruppmedlemmarna och avlägsna hinder för processen.

4.3. Utvecklingsmetod

4.3

Utvecklingsmetod

Projektet var uppdelat i två faser: förfasen där planering och kravverifiering framställdes och utvecklingsfasen då produkten skapades. Gruppen valde under utvecklingsfasen att arbeta efter Scrum-modellen. Nedan följer en beskrivning av Scrum och hur projektgruppen arbetat under förfasen och utvecklingsfasen.

4.3.1

Förfas

Förfasen började med att rollerna teamledare, kvalitetssamordnare, utvecklingsledare, test-ledare, dokumentansvarig, analysansvarig och arkitekt delades ut utifrån preferenser från gruppmedlemmarna. Rollerna hade dessa ansvar i förfasen:

• Arkitekten var ansvarig för att leverera en översiktlig bild av systemet så att sprint 1 kan påbörjas i utvecklingsstadiet. Där ska komponenter och gränssnitt vara identifierade. Detta arbete dokumenterades i en arkitekturbeskrivning.

• Analysansvarig är ansvarig för att få en klar kravbild från kunden så att planeringen som utförs i förfasen är i linje med vad kunden förväntar sig. Analysansvarig ska också vara en förhandlingspart mellan gruppen och kunden för att ta fram rimliga krav i avtalet som projektgruppen ska genomföra.

• Kvalitetssamordnaren har som ansvar att definiera ett mätbart kvalitetskrav på projek-tet som sedan kan användas för utvärdering under utvecklingsstadiet och i förstudien. • Konfigurationsansvarig har som ansvar att sätta upp en utvecklingsmiljö som är redo

när utvecklingsstadiet börjar. Det inkluderar saker som versionshantering i Git. • Testledaren har som ansvar att påbörja en testplan så att gruppen i utvecklingsstadiet

kan få tidig återkoppling på sin kod.

• Utvecklingsledaren har som uppgift att under förstadiet ta fram en utvecklingsmetodik och se till att den efterföljs av resterande gruppmedlemmar. Den har även sista ordet i val av utvecklingsmiljö och språk.

• Teamledaren ska se till att allt arbete utförs i förfasen.

Utöver det skapades en projektplan som beskrev hur arbetet skulle gå till och en kvalitets-plan som beskrev hur kvaliteten på projektet ska hållas. Även kravspcifikationen framställdes utifrån möten med kunden som beskriver vad produkten har för funktionella krav och de-signkrav.

4.3.2

Utvecklingsfas

I utvecklingsfasen valdes Scrum som utvecklingsmetod. Arbetet delades in i olika iterationer och alla roller fick då nya ansvarsområden.

• Teamledaren har fortsatt ansvar för att projektets processer följs och att gruppen har en bra arbetsmiljö. Teamledaren ska också agera coach i den mån som det behövs för att lyfta medlemmar eller gruppen vidare vid problem.

• Analysansvarig har fortsatt kundkontakt för att se till att projektets innehåll håller sig inom ramarna för vad kunden förväntar sig. Hen är också ansvarig för att besvara möj-liga frågor från gruppmedlemmar gällande kunden och dess förväntningar.

• Arkitekten ser till att en stabil arkitektur tas fram och implementeras och gör övergri-pande teknikval. Hen ska kontinuerligt dokumentera arkitekturval.

• Utvecklingsledaren har ansvar för den detaljerade implementationen av arkitekturen. Det innebär att leda och fördela utvecklingsarbetet mellan gruppens alla medlemmar och organisera utvecklarnas tester. Utvecklingsledaren har ansvar för att alla aktiviteter blir gjorda och att alla medlemmar alltid har något att göra.

• Testledaren tar beslut om systemets status och ser till att det sker verifieringar och va-lideringar i enlighet med testplanen. Resultatet av detta ska sedan sammanfattas i en testrapport.

• Kvalitetssamordnaren har yttersta ansvar för att planera och budgetera projektets resur-ser och därmed projektmedlemmarnas tid. I och med detta ska kvalitetssamordnaren se till att fånga upp de olika medlemmarnas kunskaper för att på effektivast möjliga sätt fördela arbetet mellan dem.

• Dokumentansvarig ska se till att potentiella förändringar av projektets krav eller andra parametrar som har dokumenterats uppdateras i enlighet med förändringen.

• Konfigurationsansvarig bestämmer vilka delar som ska versionshanteras och vad som ingår i en utgåva av projektet. Konfigurationsansvarig ser även till att versions- och konfigurationshantering underhålls och används av gruppens medlemmar enligt grup-pens överenskommelse.

4.4

Utbildning

Alla projektmedlemmar utbildades främst på två olika sätt - genom egen forskning inom det område hen arbetade på och under möten då alla utbildade varandra i sina områden. Utbildningen av varandra gjordes under återblicken av varje sprint där alla presenterade det arbete som gjorts, hur det fungerar samt vad de lärt sig. På detta sätt får alla en uppfattning om hur alla delar av projektet fungerar.

4.5

Erfarenhetsuppfångning

För att samla in information om alla gruppmedlemmarnas tidigare erfarenheter hölls ett in-formellt möte där alla pratade om relevanta erfarenheter och i vilka projekt de arbetat tidiga-re. Detta gjordes genom en gruppdiskusion där alla medlemmar fick berätta om vilka projekt de haft tidigare och vad de lärt sig utifrån dem. Denna information användes senare när ar-betsuppgifterna delades upp inför varje sprint. För att samla in erfarenheter under projektets gång hölls ett par scrummöten varje vecka. Under dessa möten kunde varje medlem dela med sig av sina erfarenheter om vad hen hade arbetat med och eventuella problem hen stött på till resten av gruppen. Efter varje sprint hölls även ett retrospektivt möte där gruppen identifierade vad som hade fungerat bra och mindre bra under sprinten. Detta gjorde så att gruppen kunde ta tillvara av de erfarenheter som samlats upp under den avklarade sprinten och förbättra utvecklingsprocessen till framtida sprintar. Gruppen såg även till att det fanns en öppen atmosfär där man lätt kunde fråga om hjälp från andra gruppmedlemmar. Detta gjorde bland annat att erfarenheter lättare kunde bytas ut mellan undergrupperna som var fokuserade inom olika områden.

5

Resultat

Här presenteras en översiktlig beskrivning av den arkitektur som projektgruppen har imple-menterat, hur den kan skapa värde för kunden samt gruppens gemensamma erfarenheter.

5.1

Systembeskrivning

Nedan presenteras en beskrivning av det systemet som har skapats under projektet.

5.1.1

Översiktlig beskrivning av systemet

Systemet abstraheras på en hög nivå till tre moduler. Dessa moduler representerar de tre om-rådena i utvecklingen av Kubernetesapplikationer som systemet har som syfte att förenkla. Kubernetesapplikationer karakteriseras av att vara en uppsättning av individuella, självstän-diga moduler som kommunicerar sinsemellan. De tre områdena är utveckling, testning och leverans. Systemet har även beroenden till yttre tjänster. Dessa är tjänster för versionshante-ring som Gitlab, Github och Bitbucket samt molnleverantörer som Google Cloud Platform, Microsoft Azure och Amazon Web Services. Dessa anses som förutsättningar för att systemet ska kunna användas. En överblick av detta fås i figur 5.1.

Arkitekturen är framtagen med målet att skapa ett modulärt system där individuella delar enkelt ska kunna bytas ut. Det var även viktigt att systemet var händelsedrivet så att de individuella modulerna inte behöver stå och vänta på varandra. En annan viktig faktor är att systemet ska kunna skala väl för att kunna möta ett behov av olika storlekar.

5.1.2

Lokal utveckling

Modulen för lokal utveckling består i huvudsak av två open-source-projekt som heter Code-server och Telepresence. Det kräver även att det finns en kopia av produktionsmiljön upp-satt, ett så kallat utvecklingskluster. Detta kluster kommer att användas för att en utvecklare ska ha möjlighet att se hur nya funktioner interagerar med det resterande systemet utan att själv behöva tillhandahålla produktionsmiljön lokalt på sin dator. Dessa två projekt ger oss möjligheten att erbjuda utvecklare hot reload och avlastar deras datorer genom att placera utvecklingsmiljöerna på en avlägsen server i utvecklingsklustret.

Figur 5.1: Översikt av systemet. Dev syftar på utvecklingsklustret; Prod syftar på produk-tionsmiljön.

För hot reload skapades därmed ett skript som finns tillgängligt att köra var som helst på Code-servern. Det tar en inparameter för den tjänst man vill utveckla och använder därefter Telepresence för att byta ut denna tjänst på utvecklingsklustret mot en lokal variant. Skrip-tet vidarutvecklades dessutom genom utökning med en flagga som avgör hur skripSkrip-tet ska exekveras. Det första alternativet är att köra utan flaggan. Detta medför att utvecklaren själv måste integrera någon form av omladdningsmodul i sin Dockerfil för den valda tjänsten. Ett exempel på detta kan vara Nodemon. Vid kodändring kommer därmed programmet som körs i Dockercontainern snabbt startas om med de nya ändringarna. Det andra alternativet är att köra skriptet med flaggan vilket medför att Dockercontainern både byggs och startas om varje gång det blir en kodändring. Detta tar ofta betydligt längre tid än det första alterna-tivet men fungerar utan att utvecklarna behöver installera något själva som vid körning utan flagga.

I bakgrunden av Code-server körs Ubuntu där de verktyg som utvecklarna behöver kan installeras och användas från webbläsaren. Utvecklingsmiljön är paketerad som en modifi-erbar Dockercontainer vilket gör att utvecklingsmiljön också kan förkonfigureras med den mjukvara som krävs för ett specifikt projekt.

5.1.2.1 Code-server

Att använda Code-server som utvecklingsmiljö var en lösning som passade vår bild av vad kontinuerlig integration innebär. Det innebär dessutom att varje utvecklare har full tillgång till sin utvecklingsmiljö från alla webbläsare. Inloggningsprocessen illustreras i figur 5.2. Att logiskt placera utvecklingsmiljön inom utvecklingsklustret ger en direkt närhet till systemet som utvecklas utan att kräva extra resurser från utvecklarens utvecklingsmiljö. Det ger även möjligheten att utföra integrationstester i en kontrollerad miljö utan att behöva bygga syste-met då de kan utföras direkt på utvecklingsklustret. Att slippa bygga systesyste-met vid leverans ger en direkt reducering av tiden det tar att leverera kod till kunder och för utvecklare att få återkoppling på leveransen.

Möjligheten att kunna fördefiniera vilken mjukvara som ska finnas i utvecklingsmiljön är även en funktion som för oss ett steg närmre den bild som målades upp av kunden - att en ny utvecklare ska kunna börja utveckla med så lite ansträngning som möjligt. En väldefinierad

5.1. Systembeskrivning

miljö gör att alla verktyg som behövs för att utveckla kommer förinstallerade för alla nya utvecklare.

Figur 5.2: Ett flödesschema över inloggningen till systemet.

För att få systemet att fungera i utvecklingsklustret krävdes det en strategi för att hantera flera samtida användare av systemet. Det gjordes genom att placera en extra nod i utveck-lingsklustret som ser till att tillräckligt med utvecklingsmiljöer finns tillgängliga. Den mjuk-varan är skriven i språket Python och använder sig av Kubernetes officiella Pythonklient [70] för att kommunicera med utvecklingsklustrets API. Vyn som presenteras för en utvecklare som ska använda sin utvecklingsmiljö visas i figur 5.4.

Figur 5.4: Inloggningsidan för en utvecklare på utvecklingsklustret. Här loggar man in och skickas vidare till sin personliga Code-server-instans.

Vi insåg också att alla användare kommer vilja installera egna bibliotek, ha egna konfigura-tioner och kunna skriva kod utan att den behöver levereras upp till Git. Vi löste detta genom att varje användare får en version av en basmiljö där hens egna ändringar och konfiguratio-ner automatiskt sparas.

Att placera utvecklingsmiljön i ett Kuberneteskluster i kombination med att använda till exempel Google Cloud Platform ger möjligheten att dynamiskt öka prestandan hos utveck-lingsmiljöns hårdvara för att klara av tunga eller tidskritiska beräkningar.

5.1.3

Testning

Denna modul har som ansvar att utföra enhets- och integrationstester av kubernetesappli-kationen. Då utvecklingsmiljön är placerad i utvecklingsklustret kan integrationstester kö-ras utan att hela systemet behöver byggas. Detta möjliggörs av Telepresence som skapar en koppling mellan de lokalt utvecklade funktionerna och det resterande systemet. Då testerna kommer att köras i utvecklarens miljö var utmaningen att kunna garantera att koden som lämnas in till kodbasen har klarat de tester som ställs som krav. Lösningen som togs fram var att förkonfigurera utvecklingsmiljön med Git hooks som ser till att testerna körs innan de kan levereras till kodbasen.

5.1.4

Leverans

Denna modul har som ansvar att leverera testad kod från versionsantering till en produk-tionsmiljö. Denna produktionsmiljö ska finnas hos en eller flera molnleverantörer, således

5.1. Systembeskrivning

var det viktigt att finna mjukvara med stöd för att leverera kod till olika molnleverantörer. Valet föll i första hand på Spinnaker som inte bara har stöd för att leverera kod till flera molnleverantörer utan också för att automatisera olika typer av leveranser som “canary“-och “A/B“-leverans. Spinnaker var dock överflödig i viss mängd då vi kunde lösa mycket av dess funktionalitet, som byggning och testning av containrar, på ett bättre sätt med hjälp av Code-server. Vi gjorde då också en egen enkel leveransmodul mer i linje med vår vision av kontinuerlig leverans. Detta gjorde vi mest för att se vad som är möjligt och för att visa vad man skulle kunna åstadkomma med Bambi vid vidare utveckling. I slutändan är det dock Spinnaker som uppfyller de krav vi har på arbetet.

5.1.5

Förkrav och konfiguration

För att sätta upp ett fungerande system krävs det viss konfiguration och förutsättningar för att få Bambi att fungera. Detta kommer att diskuteras i denna sektion.

5.1.5.1 Förkrav

Systemet är designat för att fungera i ett Kuberneteskluster i Google Cloud Platform [41]. Det krävs att det finns ett uppsatt utvecklingskluster med det system som ska utvecklas. Där kommer även Code-server instanserna att finnas. Förslagsvis bör det även finnas ett uppsatt produktionskluster som utvecklade förändringar av systemet ska levereras till. Det krävs även att Google Cloud Registry [40] är uppsatt och att vår version av Code-server finns lagrad där. Slutligen krävs det att Git används för versionshantering.

5.1.5.2 Konfiguration

När förkraven är uppfyllda krävs det en ifylld YAML-konfigurationsfil för att få systemet att fungera. Den information som behövs är de kluster som ska användas av systemet, de testfiler som ska köras vid testning av systemet, en fungerande URL till kodbasen och en specifiering av de delsystem som systemet innehåller vid uppsättning av systemet. För ett fungerande system med sex aktiva användare bör vyn av ens Kubernetes-“workloads“ se likt ut de “workloads“ placerade i “dev-cluster“ som visas i figur 5.5.

Figur 5.5: Överblick över ett kluster och ett par Code-server instanser som ligger och kör i utvecklingsklustret.

5.1.6

Systemanatomi

I förstadiet av projektet utformades en systemanatomi (se figur 5.6) för att få en översikt-lig vy av systemet och för att identifiera olika systembehov. Den ger en översiktöversikt-lig bild av funktionaliteten som systemet har.

5.2. Gemensamma erfarenheter

5.2

Gemensamma erfarenheter

Några viktiga erfarenheter från förfasen av projektet var bland annat kunskapen om hur man strukturerar ett projekt. Detta innebar till exempel att skapa värdefull dokumentation för pro-jektet. Dokumentationen bestod av allt från kravspecifikation till projektplanering. Några av dessa dokument krävde dock ett flertal uppdateringar under projektets gång då gruppen, vid vissa tillfällen, bytte riktning i hur produkten skulle tas fram. Detta gav gruppen erfa-renhet i att hålla projektdokumenten levande och synkroniserade med resten av projektet. I struktureringen av projektet skapades även ett gruppkontrakt där gruppens regler för projek-tet etablerades. Detta dokument inkluderade även en rollista för gruppmedlemmarna. Detta gjorde att gruppmedlemmarna fick erfarenhet av att ta ansvar för varsitt område i projektets utveckling. Förfasen gav även en möjlighet för gruppmedlemmarna att få insikt i och erfa-renhet av viktiga begrepp som CI/CD och nybörjarkunskap i programvara som Docker och Kubernetes.

Utvecklingsfasen gav gruppen erfarenhet av utvecklingsmetoden Scrum. Detta var dock en modifierad version av Scrum där dagliga möten byttes ut mot två möten per vecka. Utveck-lingsmetoden gjorde så att gruppen kunde se framsteg och eventuella problem och veta vad de andra medlemmarna gjorde. Detta gjordes genom att under de två mötena per vecka låta gruppmedlemmarna berätta om sina erfarenheter och problem som de stött på sedan senaste mötet. Eftersom dessa möten hölls relativt ofta så minimerades risken att arbetet saktade upp eller att någon fastnade utan tillgång till hjälp från resten av gruppen. Utvecklingsfasen gav även djupare kunskap om, och erfarenhet av, den programvara som behövdes i projektet. Ex-empel på de mest allmänt förekommande programmen som gruppen fick mycket erfarenhet av under projektet var Docker och Kubernetes tillsammans med plattformen GCP. Även om mycket program och ramverk som försökte integreras in i produkten inte kom med i slutver-sionen så gav dessa ändå erfarenhet i hur de skulle kunna användas i framtiden. Ett exempel på detta är ramverket Spinnaker som till slut valdes bort på grund av svårighet att integrera på ett generellt sätt tillsammans med tidsbrist. En annan viktig erfarenhet projektgruppen fick var att arbeta mot en extern kund i företaget Skira. Ett exempel på en sådan erfarenhet var bland annat att utforma en produkt efter kundens önskemål. Att det var en extern kund gav även en ökad press för projektet där många av medlemmarna ville se projektet lyckas för att göra kunden nöjd. Framförallt har projektgruppen erhållit en ökad erfarenhet i problem-lösning.

5.3

Värde för kunden

Projektet har gett värde för kunden genom att sänka barriären som krävs för en ny utvecklare att kunna leverera kod till kundens slutanvändare. Detta genom att ge kunden möjlighet att leverera en förkonfigurerad miljö till dess anställda där all mjukvara som behövs för utveck-lingen kan specificeras så att den görs tillgänglig för varje anställd. Det ger även möjlighet att automatisera tester utan att kräva extra byggtid vilket ger utvecklaren snabb återkoppling på nyutvecklad kod. Vidare skapar det värde för kunden att projektgruppen har undersökt hur man kan automatisera leveransen av koden till produktionsmiljön, oavsett om miljön hanteras av Googles, Amazons eller Microsofts molntjänster. Olika möjligheter för hur dessa processer och konfigurationer kan automatiseras har undersökts vilket ger kunden värde vid framtida undersökningar och implementationer då vi har gett underlag inom området.

Då det är ett generellt system som har utvecklats krävs en viss manuell konfiguration för att systemet ska kunna identifiera produktions- och utvecklingsklustret, konfigurera leve-ransprocessen och definiera vilken mjukvara som behövs i utvecklingsmiljöerna. Dessa delar är av varierande svårighetsgrad beroende på komplexiteten hos kundens individuella ut-vecklingsbehov. Då varje system och projekt är unikt kommer det att skilja sig mellan dem

beroende på hur och vart de vill leverera sin kod. Detta gör att varje projekt kommer behöva definiera sin egen leveransprocess.

5.4

Kvalitetskrav

Det kvalitetskrav vi arbetade mot blev uppfyllt. För att börja använda systemet behöver an-vändaren endast gå in på inloggningssidan, och skriva in sina Git inloggningsuppgifter. Se-dan loggar användaren in och kan börja bidra med kod till företaget. Detta uppfyller det krav att antal steg för en ny användare att börja använda systemet inte ska överstiga fem.

5.5

Översikt över individuella bidrag

Projektets medlemmar har under projekttitden utfört mindre undersökningar av specifika områden kopplade till projektet. Denna del ger en kort översikt av de undersökningarna.

5.5.1

Decentraliserade moln och molntjänster av Anton Andell

Mer och mer system idag läggs på molnen, och de flesta på Google Cloud Platform eller AWS. Detta gör att mycket av trafiken på internet går genom ett fåtal företag. Detta bidrag undersöker hur det är att istället använda ett decentraliserat moln i syftet att hålla internet decentraliserat.

5.5.2

Ger en microservice-arkitektur snabbare kodleverans till slutanvändare av

Eric Lilja

Detta bidrag undersöker systemarkitekturens påverkan på leveranstider. Den jämför en microservice-arkitektur med en monolitisk arkitektur och dess påverkan på leveranstider av kod till slutanvändare. Då projektet avser att automatisera leveransen av microservice-applikationer blev det av intresse att se om microservice-arkitekturen främjar kontinuerlig leverans.

5.5.3

En jämförelse mellan muterbar och icke-muterbar serverinfrastruktur av

Andreas Zeijlon

Frågan om muterbar eller icke-muterbar serverinfrastruktur är fundamental för serverhante-ring och underhåll. Därför ska den här studien undersöka och jämföra deras för- och nackde-lar för att komma fram till när man bör använda den ena framför den andra.

5.5.4

Datasäkerhet inom molntjänster - en literaturstudie av Nigel Cole

I dagens samhälle flyttar produkter alltmer till molnet. Det finns många fördelar men datasä-kerheten är inte tillräcklig. Med nya lösningar kommer alltid nya brister vilket kan utnyttjas av hackare. Denna undersökning har i syfte att ta reda på de åtgärder som kan göras för att skydda data vid användning av molntjänster och vad som är viktigt att veta vid val av distributionsmodell samt eventuella alternativ till molntjänster.

5.5.5

Metoder och kostnad för mjukvarukvalitet - en fallstudie av David

Thimren

Mjukvarukvalitet är en väldigt viktig och stor del av varje mjukvaruprojekt. Utan bra meto-der och verktyg kan kvalitetsarbete kosta mer än vad det behöver och därför kommer denna studie beskriva hur vi arbetade med vår mjukvarukvalitet och hur mycket det kostade.

5.5. Översikt över individuella bidrag

5.5.6

För- och nackdelar med Dockercontainrar jämfört med virtuella maskiner

av Wiktor Karlsson

Många nya former av virtualisering har på senaste tiden dykt upp i dagens samhälle varav en av dessa är containrar. Detta bidrag ger en översikt över för- och nackdelarna med Doc-kercontainrar, som har använts genomgående under projektet, jämfört med traditionella vir-tuella maskiner.

5.5.7

Klimatpåverkan av molntjänster av Diba Rezaie

Företag börjar gå allt mer mot en microservice-arkitektur i sin verksamhet vilket bidrar till att molntjänsterna växer sig allt större. Då mer data belastar molnen krävs det mer elektricitet som driver datacentrerna för att hålla molntjänsterna uppe. Denna undersökning kommer att jämföra de tre största molntjänsterna (GCP, Azure och AWS) och dess klimatpåverkan.

I detta kapitel presenteras diskussionen.

6.1

Resultat

Nedan följer diskussionen om resultatet.

6.1.1

Implementationsval

Vi fick av kunden en hel del krav på systemet men vi lämnades ändå med många valmöjlighe-ter samt lite fria händer att skapa något användbart. Med valet att implemenvalmöjlighe-tera Code-server tog vi bort många steg från den konventionella pipelinen och löste många av de problem vi ställdes inför i början av projektet. Under ett möte med kunden nämndes en önskan om att nya utvecklare ska kunna börja jobba med så lite uppsättning som möjligt och vi ansåg att Code-server skulle bidra mycket till detta. Med detta valet hade vi inte längre någon natur-lig plats för testverktyg som Jenkins, så vi bestämde oss för att köra på lokal testning. Lokal testning brukar inte var att föredra men eftersom vår lokala miljö ligger på molnet så und-kommer vi de flesta problemen med lokal testning. Vi kan nyttja faktumet att vi redan har en uppdaterad, färdigbyggd miljö och därifrån kan köra tester på systemet i helhet. En annan anledning att använda externa ramverk som Jenkins är att automatisera tester. För att lösa det valde vi att använda oss av enkla Git hooks då vi, eftersom vi har kontroll över miljön, kan tvinga på Git hooks och därigenom kontrollera alla leveranser.

För slutprodukten ansåg vi det viktigt att användaren skulle kunna se hur deras ändringar i koden påverkade och samspelade med klustret utan att behöva gå igenom hela leverans-procesen. För att implementera den funktionaliteten valde vi att använda programmet Tele-presence. Telepresence gav oss möjligheten att byta ut en mikrotjänst i klustret mot en lokal Dockercontainer. För automatisering av modulen bestämdes det att ett program skulle över-vaka kodändringar i de filer man arbetade med. Vid förändring skulle containern laddas om så att förändringarana kunde observeras i systemet.

För den övervakningen stod valet mellan att använda programmet Skaffold eller skapa en egen variant med hjälp av ett bashskript. Inledningsvis tänkte vi använda Skaffold men den

6.1. Resultat

planen byttes snabbt ut då programmet inte hade all funktionalitet vi behövde för modulen. Ett bashskript valdes därmed istället. I början låg fokus bara på att få skriptet att kunna bygga och starta om hela Dockerfilen men när detta väl fungerade implementerades en flagga för ett annat alternativ. Detta alternativ var att låta utvecklarna själva lägga till en omladdningsmo-dul i Dockerfilen så att omladdningen av programmet skedde inifrån. Det skriptet gjorde vid detta alternativ var att montera in mappen som tillhörde tjänsten som skulle utvecklas. Det-ta innebär att filändringar i mappen på värddatorn medför ändringar i conDet-tainrarnas mapp vilket då aktiverar den valda omladdningsmodulen. Dessa val implementerades för att ge framtida utvecklare mer frihet i att utveckla på det sätt som bäst passar dem. Skriptet har även möjlighet att vidareutvecklas i framtiden med lätt utökning av flera flaggor och alterna-tiv.

Något som var viktigt för kunden var att kunna distribuera applikationen till flera molnle-verantörer. Här valde vi mellan att skriva en egen lösning och att integrera ett redan existeran-de bibliotek för att göra existeran-det enklare att använda. Att skriva en egen lösning och implementera de behövda strategierna däri verkade vara en väldigt tung uppgift så vi valde att använda oss av biblioteket Spinnaker. Spinnaker visade sig vara svårt att sätta upp och krävde mycket specifik användarinfo som skulle levereras till spridda delar av systemet. Vi insåg då att vi inte hade tid att integrera Spinnaker med vårt system. Vi bestämde oss i slutändan för att i största möjliga mån låta systemet vara kompatibelt med en framtida utökning med Spinna-ker men implementerade istället en egen leveransmodul för att göra en smidig, enkel och integrerad leverans för att visa möjligheterna med, och vår vision för, projektet.

6.1.2

Vidareutveckling

Bambi skapades inte med intentionerna att vara en helt färdig produkt vid slutet av projektet utan kunden ville ha något som kunde utvecklas vidare. Nedan kommer våra tankar om framtida förbättringar och ändringar.

6.1.2.1 Hot-reload/utveckling

Här använder vi oss nu av Teleprecense i samarbete med en hot-reload-del för den Docker-container som körs. Teleprecense är skapat för utveckling på ett kuster från en lokal miljö. Vi är inte längre i en lokal miljö och Teleprecense är i viss mån lite överflödigt och en mer elegant lösning skulle kunna konstrueras. Teleprecense tillåter inte heller fler utvecklare på samma mikrotjänst och de tjänster som utvecklas kan störa varandra när flera utvecklar samtidigt. Här skulle det gynnas mycket av att en mer sofistikerad lösning som utnyttjar att utvecklings-miljön ligger lokalt i klustret används. En sådan lösning är ett krav om antalet utvecklare blir många.

6.1.2.2 Code-server

Code-servern är i ett tillräckligt fungerade skick och den har enligt oss inte någon hög prio-ritet att utvecklas vidare men även den har många saker som kan förbättras. Ett användar-gränssnitt för administratörer att installera nya bibliotek och konfigurera andra saker i det underliggande systemet hade varit användbart. Det hade varit bra att ha möjlighet till indi-viduella installationer, program som en enskild utvecklare vill ha, utan att behöva installera det för alla utvecklare. Den hade även behövt ett snyggare användargränssnitt för att logga in i och ett sätt att slippa logga in två gånger för att komma åt Code-servern. Det är just nu också en del säkerhetsrisker som skulle behövas förbättras för att göra den helt användbar: hur vi hanterar användares Git inloggning och GCP autentisering. Vi hade också ett krav på

att instansen som klustret körs på måste vara öppen för TCP-kommunikation. Detta imple-menterades utan större undersökning av vilka risker som det kan medföra.

6.1.2.3 Deployment

Den implementerade deployment-logiken är för tillfället något enkel men uppfyller kraven ställda på projektet. I en organisation som agerar i en större skala kan det finnas ytterligare önskvärda konfigurationer och funktioner att implementera i framtiden. Det finns till exem-pel ingen lagring av vilka kodversioner som har klarat av vilka tester, något som kan behövas för att kunna verifiera att den kod som levereras har uppfyllt alla tester. Dessutom kan den in-formationen vara önskvärd på ett organisationellt plan för att ge en överblick av mjukvarans effektivitet.

Den leveranslogik (Spinnaker) som först planerades att användas uppfyller dessa krav och mer, men blev för svårt att på ett generellt vis integreras in i systemet. Tills vidare blir re-kommendationen att i en större skala använda Spinnaker och försöka integrera in det i vårt system om man vill ha en lösning som tar vara på att ett utvecklingskluster redan finns. Det skulle dock ta för mycket tid att specialisera sig på och konfigurera Spinnaker så att det kan integreras smidigare då detta har uppfattats som icke-trivialt.

6.1.3

Andra projekt/konkurrenter

Det finns många som arbetar med att göra utvecklingspipelines smidigare och enklare. Vi kan inte säga att vi har förbättrat något från tidigare projekt men vi kan säga att vi gjort något lite annorlunda. Konkurrensen inom detta området är hård så vi valde att nischa oss lite och göra lösningen enklare än de flesta andra. Detta genom att ta bort lokal utveckling och därmed också kravet på externa ramverk för testing. Som det är nu är dock vår lösning låst till GCP och den passar inte för stora utvecklingsteam men båda dessa egenskaper kan ändras om utvecklingen fortsätter.

6.1.4

Lärdomar

Vi började projektet med planen att sätta upp en mer traditionell pipeline men märkte efter ett tag att det var väldigt svårt att förenkla och gör smidigare. Alltså tog det ett tag innan vi kom in på den vägen vi är på nu. Utöver att studera ämnet i förstudien borde vi också undersökt konkurrenter och problem de har vid utvecklingen av liknande projekt. Detta hade kunnat göra att vi hade lagt mindre tid på sådant vi inte använde i slutändan. Vår iterativa arbetsprocess gjorde dock att vi efter ett tag kunde justera projektets riktning och inte fastna i den planering som först etablerades. Detta belyste fördelarna med ett iterativt arbetssätt för oss.

Vi insåg också under projektets gång vikten av en bra aktivitets-/uppgiftsplanerning. Små isolerade deluppgifter gör det mycket enklare för många utvecklare att vara effektiva. En dålig planering och uppdelning gör att man ofta kan stå tomhänt utan något att göra. Vi har också sett vikten av att specialisera sig inom ett område. Det hade förmodligen hjälpt mycket om vi tidigt bestämt vem som skulle ha hand om vad i projektet så hade man sluppit upplärningstiden som kommer så fort man byter område. Eftersom det är ett studiearbete och alla vill lära sig så mycket som möjligt har vi dock ej gjort detta.

6.2

Metod

6.2. Metod

6.2.1

Informationsinsamling

Erfarenhetsuppfångningen hjälpte till med att ge en uppfattning om gruppens kompetens. Det fanns moment som att till exempel sätta upp en server vilket endast en gruppmedlem hade gjort tidigare. I stort var de flesta områdena nya för gruppen och därför kunde inte arbetsuppgifter fördelas på ett effektivt sätt, istället arbetade alla med det de ville göra. Ska-padet av kravlistan var lite problematiskt då projektet och området var abstrakt och nytt för projektgruppen. Dessutom var många av projektets krav i prioritet 2 för att ge projektgrup-pen en frihet att välja ut forskningsområde. Projektgrupprojektgrup-pen fick välja vilka krav de helst ville uppfylla vilket ledde till en del diskussioner då projektgruppen saknade kompetensen att förstå vilka krav som skulle vara bäst att följa. Senare under projektet, när projektgruppmed-lemmarna fått mer erfarenhet, kunde ordentliga beslut tas angående vilka krav vi ville följa. Innan uppsättningen av krav borde projektgruppen utforskat fler olika projekt inom områ-det och försökt fastställa en bild på hur vi ville att Bambi skulle se ut för att bäst uppfylla kundens krav. Under första iterationen följde Bambi en traditionell CI/CD-pipeline-struktur medan under andra iterationen användes en mer unik lösning istället för att endast använ-da reanvän-dan skapade program. Det hade varit fördelaktigt att från första början ha gjort Bambi till en egenskapad variant av en CI/CD-pipeline men det är en lärdom vi tar med oss till framtiden.

6.2.2

Scrum

Scrum har fungerat bra för projektgruppen. Den stora välgörande faktorn har varit att grup-pen hållits uppdaterad om projektets olika delar där problem och bedrifter lyfts fram. En märkbart bristande faktor var att planeringen för varje sprint inte följdes ordentligt. Pro-blemet kunde vara att aktiviteter tog längre tid än planerat utan att åtgärder infördes eller att förhinder av andra slag uppkommit. Deadlines hölls inte alltid ordentligt och uppgiften som skulle väljas av varje gruppmedlem vid Scrummötet lyckades inte alltid uppfyllas. Detta ledde successivt till att Scrummötets “till nästa gång“-punkt förlorade sin betydelse då inga framsteg hade gjorts sedan föregående möte. Detta var svårt att rätta till då det inte går att förutspå problem. Det som hjälpte en del var att omfördela resurserna sådan att arbetet inte stannade upp på en och samma aktivtet utan arbete kunde påbörjas inom andra områden.

Det finns flera olika typer av utvecklingsmetoder som en mer traditionell vattenfallsmodel men för projektgruppen fungerade Scrum bra och var av störst intresse utifrån de kunskaper vi fått från tidigare kurser. De problem som togs upp utgör en liten nackdel jämfört med de fördelar som upplevdes. Dessutom var problemen ett resultat av att gruppen inte följde planeringen ordentligt och hade gett problem oavsett vilken utvecklingsmetod som följts. En bättre tidsuppskattning med en tidsbuffert på varje aktivitet hade nog också hjälpt en del. Generellt underskattades svårigheten hos och tidsåtgången för en del aktivteter.

6.2.3

Utvecklingsfas och utbildning

Alla medlemmar har haft en specifik roll med ett visst ansvarsområde. Detta har fungerat bra och projektets medlemmar har sett till att deadlines, dokumentation och inlämningar följts där respektive ansvarig person påmint gruppen om dessa händelser. Alla har även hjälpt till att påminna varandra om större deadlines och andra viktiga evenemang som seminarier. Sprintarna utfördes med bra planering men problem som uppstod gjorde att aktivteter inte alltid var klara i tid. Antingen borde sprintsen innehållit färre funktioner alternativt skulle gruppen ha försökt tidsuppskatta arbetet bättre och fördela resurser på ett bättre sätt. Som nämnts tidigare är sådana problem inte specifika för de metoder som valts av projektgrup-pen.

Då alla medlemmar i projektgruppen utbildat sig själva har det varit svårt att lösa problem eftersom det inte funnits utomstående att få svar från bortsett från hemsidor på internet. Dessutom har det inte funnits tillräckligt med tid för att kunna utbilda alla medlemmar inom alla områden av projektet. Medlemmarna kan sina respektive delar och förstår resterande delar översiktligt men inte i varje detalj. Anledningen är att de olika områdena av Bambi oftast innehåller flera komplicerade program som samarbetar vilket är för tidskrävande att förklara i detalj. Viktigt att understryka är att alla medlemmar har tillräckligt med kunskap för att förstå hela Bambi men att medlemmarna inte kan varje kodrad.

6.2.4

Källkritik

Mycket av vår information kommer från dokumentationen för de öppna källkodernas kod-bas, alternativt deras hemsidor. En del av informationen kommer även från från vanliga webbsidor, forum och bloggar vilket i de sammanhangen är uppfattades som tillräckligt gilti-ga att använda då en del av programvaran och koncepten som används är så pass nya att det finns begränsat med information. För generell information om begrepp exempelvis vad en pi-peline eller CI/CD är överensstämmer informationen från olika hemsidor. För programvara har främst dess egen dokumentation och webbsidor använts som källor.

6.3

Arbetet i ett vidare sammanhang

Detta kapitel tar upp olika aspekter i ett vidare sammanhang i arbetet.

6.3.1

Samhälleliga aspekter

Bambi är utvecklat med öppen källkod för att göra systemet tillgängligt för användning och vidareutveckling för allihopa. Systemet är utvecklat för både privatpersoner och företag för att underlätta att komma igång med en omgivningskonfiguration som blir likartad för alla utvecklare. Bambi kommer också att vara tillgängligt på alla tekniska enheter med en inter-netuppkoppling och en webbläsare. Detta bidrar till att en utvecklare själv kan välja vilken dator eller enhet hen skulle vilja utveckla på.

6.3.2

Miljöaspekter

Utifrån ett miljöperspektiv är strömförbrukningen av den tekniska enheten man använder sig av en faktor. Sverige är, jämfört med andra länder, generellt duktigt på att använda sig av grön energi (exempelvis vind eller vatten), däremot kan systemet användas där energin kommer från smutsig energi (som kolkraftverk). [32] Detta kan likväl sägas om de datacenter som utvecklarnas tjänster körs av antingen använder datacentrerna sig av grön eller smutsig energi. Detta är tyvärr väldigt svårt för utvecklarna att styra över. Besluten ligger mer på en statlig nivå eller på företagen vars tjänster man använder sig av.

Bambi förskjuter tunga beräkningar och därmed energikonsumptionen från lokala datorer till stora serverhallar. Detta kan också skapa förändringar i konsumentbeteenden då behovet att ha en uppdaterad lokal dator med mycket processorkraft minskar. För mer information kring datacentrernas energikonsumption och deras påverkan se kapitel G.

6.3.3

Etiska aspekter

Beroende på vilka projekt som är tänkt att köras på Bambi är det viktigt att köra Bambi från säkra enheter så att inte känslig information som finns i projektet kan läcka ut. Det är även viktigt att tänka på vilka trådlösa nätverk som utvecklarnas enhet är uppkopplad i då även det kan leda till att obehöriga kan komma åt projektet. Även om Bambi kan användas av

6.3. Arbetet i ett vidare sammanhang

privatpersoner är systemet främst utvecklat för företag. Det åligger då företaget att testa sy-stemet efter säkerhetsrisker då inte projektgruppen kan hållas till svars ifall ett dataintrång skulle ske.

I de följande styckena presenteras de slutsatser som arbetet har gett genom att besvara rap-portens frågeställningar.

1. Hur kan Bambi implementeras för att skapa värde för kunden?

För att använda produkten måste företaget i förväg sätta upp och konfigurera Bambi och det-ta görs genom att koppla produkten till sitt utvecklings- och produktionskluster i GCP. När man gjort detta ger Bambi främst en sänkt kostnad för att ta in nya utvecklare till ett befintligt system på ett företag. Bambi ger även möjligheten att lägga till CI/CD till sin arbetsprocess.

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet som

kan vara intressanta för framtida projekt?

De erfarenheter vi har lärt oss och kan ta vidare till framtida projekt är främst hur svårt och mycket arbete det är att sätta upp CI/CD-pipelines. Det är ett väldigt stort och komplicerat område som är svårt att få generaliserat. Med andra ord är det en viktig kunskap att ha i framtida projekt att det ej är rimligt att ta för givet att sådant går snabbt och är enkelt att sätta upp utan det kommer ta längre tid än man tror. Vi har också fått mycket erfarenheter inom agil utveckling och har provat på några olika metoder och mallar för hur utvecklingsmetoder kan följas.

3. Vilket stöd kan man få genom att skapa och följa upp en

systemanatomi?

Systemanatomin gav gruppen en första översiktlig bild av hur systemets olika delar skulle interagera med varandra och gav också en bra bild över vad som behövde göras. Systemana-tomin visade vilka delar som berodde av andra och då kunde man se vilka delar som kunde arbetas med parallellt. Den ger en möjligheten att enklare dela upp och effektivisera arbetet.

4. Hur mycket av CI/CD pipelines uppsättningen kan automatiseras?

Det visade sig att installationen av en CI/CD-pipeline är väldigt svår att på ett generellt sätt automatisera på grund av att konfigurationen kommer se olika ut för alla projekt. Alla moln-leverantörer kräver egna uppsättningar och kommunicerar med olika API:er. Varje projekt kommer att vilja köra sina egna tester och också bestämma hur de ska köras. Vi kunde få till en standardiserad programinstallation men användarna kommer troligen att vilja modifiera den till sina egna projekt. En lösning vi hade för att slippa en del konfiguration var att flytta den lokala utvecklingen till utvecklingsklustret uppe i molnet. Slutsatsen är att en CI/CD-pipeline bara kan automatiseras till en viss punkt, sedan krävs att användaren skräddarsyr den för sitt eget ändamål. Det vi kan göra är att abstrahera större delen av uppsättningen för att underlätta för olika projekt.

A

Decentraliserade moln och

molntjänster av Anton Andell

A.1

Inledning

Idag ligger de flesta av de tjänster vi använder på molnet, där molnet ofta är stora system ägda av stora företag som Google och Amazon[4]. Det har den senaste tiden blivit väl-digt populärt med blockchain och internet of things. Detta har även startat drömmen om att decentralisera molnet ett tillitslöst system med många noder som hjälps åt med berkä-ningskraft och lagring till ett lägre pris med privat datahantering och alltid är tillgängligt[12].

A.1.1

Syfte

I den här rapporten vill jag jämföra att ha tjänster på ett decentraliserat moln med att använda de moln som används nu, ur både utvecklar- och användarsynvinkel.

A.1.2

Frågeställningar

1. Vilka sorts applikationer/tjänster skulle gynnas av ett decentraliserad tillitslöst moln istället för ett centraliserat?

2. Behöver användare anpassa sig för att använda ett system på ett decentraliserat och tillitslöst moln jämfört med ett centraliserat?

3. Hur behöver utvecklare anpassa sig för att utveckla mot ett decentraliserat och tillitslöst moln jämfört med ett centraliserat?

A.1.3

Begränsningar

Blockchain och decentralisering handlar ofta mycket om att eliminera mellanhänder och att ha makten över sin egen data. Denna rapport kommer att inte fokusera på dessa aspekter. Det kommer inte heller vara någon djupare förklaring av bakomliggande tekniker. Rapporten kommer däremot bara ta upp lösningar som är tillitslösa.

A.2. Bakgrund

A.2

Bakgrund

Termen cloud gjordes först känd av dåvarande chefen på Google Eric Schmidt 2008 och har därefter använts mer och mer. Idag används molnlösningar av många, av företag för att smidigt och billigt lägga upp olika tjänster och privatpersoner för att spara datorkraft och få mer lagringsplats. När folk tänker på molntjänster kommer ofta tjänster som Google cloud, Aws och Azure upp då de är de störst inom molnlösningar.[4]

Under internets tidiga år var de vanligt att ett företag utvecklade en tjänst, satte upp hård-varan och tillhandahöll den själva. Detta gjorde att de behövde ha anställda som skötte dessa system och ha lokaler för dem med mera. Idag har de flesta företag sina tjänster på ett moln och betalar ofta en summa beroende på hur mycket lagring och kraft de konsumerar vilket ofta gör det billigare och smidigare att utveckla olika produkter. I och med detta har inter-net blivit mer och mer centraliserat och den mesta trafiken går till samma punkter. Många, inklusive jag, tycker att internet borde vara ett fritt internationellt medium ägt av ingen. Just därför är det väldigt intressant att undersöka fördelar med decentralisering som inte har just med nämda begränsningar (se A.1.3) att göra.

A.3

Teori

A.3.1

Blockchain och decentraliserade applikationer(smart-kontrakt)

A.3.1.1 Blockchain

Alla projekt som presenteras i denna artikeln är baserade och byggda på en slags blockchain. Blockchain är en distribuerad databas där alla data är uppdelade i olika block, som ligger som i en kedja, i tidsordning, där alla block har godkänts av en majoritet av alla noder i nätverket. Denna kedja är också helt deterministisk och kan därför verifieras av vem som helst för att se att alla regler följs.[19] Det är just detta som bidrar till den tillitslösa decentraliserad miljön.

A.3.1.2 Smart-kontrakt

Smart-kontrakt är en benämning på applikationer som kan köras på ett tillitslöst nätverk, oftast en blockchain. Det kan allstå exekveras utan att någon har särskild auktoritet över ge-nomförandet. Detta gör att man tillexempel skulle kunna implementera röstning eller bevisa ägarskap utan någon mellanhand. [23]

A.3.2

Molntjänster

Denna del beskriver de tjänster som brukar erbjudas den som vill använda molnet[4]

A.3.2.1 Platform as a Service (PaaS)

PaaS är en modell där användaren jobbar med ett system där den kan installera egen mjukva-ra och kömjukva-ra den. Levemjukva-rantören håller all hårdvamjukva-ra och den icke användarintalemjukva-rade mjukvamjukva-ran som operativsystem osv, de erbjuder också mjukvara för testning och databashantering.

A.3.2.2 Infrastructure as a Service (IaaS)

IaaS är en modell där användaren har kontroll över mjukvara och lagring. Här kan man installera eget operativsystem med mera. Leverantören har då kontroll över nätverkstraffik och den underliggande hårdvaran