Det er mye buzz rundt kontinuerlige leveranser og DevOps blant utviklere for tiden. Men hvorfor er dette også interessant for forretning? Hva gir det av verdi?

1. KONTINUERLIGE LEVERANSER OG DEVOPS
Hva gir det av verdi?
Software 2013
Sveinung Dalatun og Stein Inge Morisbak
13/02/13
- Hva er kontinuerlige leveranser og hva er DevOps?
- Hva gir det av verdi?

2. Når vi lager programvare for brukere så forventer vi å tjene penger på det. Eller vi gjør det kun for brukernes skyld (eks. offentlig).
Uansett; det vi forsøker å oppnå er å skape verdi. Prøv å sett dere inn i situasjonen til den som sitter med lommeboka og skal betale
for programvaren som lages: Er du interessert i å betale for estimering, planlegging, testing, godkjenning, drift osv. osv.? Egentlig
ikke. Er du interessert i å betale for programvare som skaper verdi for brukerne og deg sjøl? Ja. Det er i grunnen det eneste du som
sitter med lommeboka EGENTLIG har lyst til å betale for. Det andre vil du ha minst mulig av. Og: vil du helst ha ti nye ting om en
måned, eller vil du ha en ny ting hver dag? Vil du vente til alt er ferdig, eller har du lyst til å si fra underveis om dette er systemet du
ser for deg?

3. Betyr det at du som kunde driter i:
- om vi tester og kvalitetssikrer?
- ikke planlegger?
- ikke måler fremdrift?
- At vi bare turer på?
Selvsagt ikke.

4. Brukerne er heller ikke interessert i planene våre, testing, godkjenninger og drift.
Så, hvordan ivaretar vi at dette blir høykvalitets programvare som er akkurat det brukerne ønsker seg likevel?
Brukerne er selvsagt interessert i at programvaren skal ha høy kvalitet, at den skal bli ferdig raskt, og gjøre akkurat det
de vil den skal gjøre.
Brukerne er utålmodige. Brukerne er også som regel fornøyd med å få noe som virker lovende, og så leveres det nye
ting som perler på en snor. Google er et kroneksempel på det. Eks. Gmail. Starter med enkel epostleser - utvider
kontinuerlig.

5. UTFORDRINGEN:
1. Kunden vil bare betale for levert programvare som gir verdi.
2. Programvaren skal ha høy kvalitet og være testet.
3. Det som lages skal være det brukerne behøver.
Utfordringen er altså:
1. Kunden vil bare betale for fungerende programvare, og ikke alt det andre "vi må gjøre".
2. Programvaren skal ikke ha masse feil, være utilgjengelig, eller være dårlig laga rett og slett.
3. Programvaren skal løse et eller annet behov som brukerne har.
Og det skal gjøres raskt!

6. Javel? Alle ønsker seg jo det. Men er det så enkelt?

7. HVA ER KONTINUERLIGE LEVERANSER?
Det er her Kontinuerlige leveranser som metodikk kommer inn. Så hva er egentlig kontinuerlige leveranser?

8. DET ER Å:
• Levere verdi så fort som mulig.
• Ikke bruke tid på ting som ikke gir verdi.
• Vite at det vi lager er verdifullt for brukerne så fort som mulig.
• Kunne reagere på endringer av forutsetninger raskest mulig.
• Kunne tilfredsstille brukerne med ny funksjonalitet og endringer kontinuerlig.
Levere programvare som gir verdi så fort som mulig.
Ikke bruke tid på ting som ikke gir verdi.
Teste ut at det vi lager er verdifullt for brukerne så fort som mulig.
Kunne reagere på endringer av forutsetninger raskest mulig ved å utsette beslutninger til i siste liten.
Kunne tilfredsstille brukerne med ny funksjonalitet og endringer kontinuerlig.

9. HVORDAN?
Hvordan får vi til det?

10. VED Å:
• Produksjonssette hyppig.
• Jobbe på en ting om gangen.
• Produksjonssette straks en oppgave er ferdig.
Produksjonssette hyppig.
Jobbe på en ting om gangen.
Produksjonssette straks en oppgave er ferdig.

11. 10.000
deployments i timen
.001%
11,6 sek. deployments
mellom deployments
som forårsaker
nedetid
Hvor ofte er hyppig? Det vil variere. En uke, en dag, flere ganger hver dag. Hver andre uke er for sjeldent. Noe firmaer
produksjonssetter tusenvis av ganger om dagen, som Amazon -> gå gjennom tall. Store firmaer med hundrevis av utviklere. For et
team på 4 eller 8 utviklere er det ikke realistisk å produksjonssette så ofte. Det tar tross alt litt tid å utvikle noe. På Digipost har vi
levert hver uke, men i det siste så har vi levert to ganger i uka. Og vi jobber med å få ned tiden. Poenget er at du må jobbe knallhardt
for å finne en måte å gjøre det enkelt å produksjonssette sånn at du kan prodsette når du vil og så ofte som mulig.

12. Hva betyr det å jobbe på en oppgave om gangen? Det betyr at vi alltid gjør den høyest prioriterete oppgaven og ikke flere i parallell.
Ikke lang backlogg planlagt for månedsvis siden. Levende backlogg -> Endrer seg hele tiden. Lett å omprioritere og legge til nye ting
basert på endringer i forutsetninger -> Eks. brukerbehov eller konkurranse. Vi har altså ETT team som fokuserer på EN oppgave.
Ikke mange team med forskjellige ansvarsområder. -> Vanskelig å synkronisere (avhengige av hverandres leveranser) = Lang tid å få
ting ut.

13. Hva betyr det å levere straks en oppgave er ferdig? Det betyr at straks oppgaven er ferdig, så produksjonssetter vi den.
En oppgave er ikke ferdig før den er i produksjon. Det er vår definisjon av ferdig. Og oppgavene du løser gir verdi
umiddelbart. Akkurat som at en bil ikke er ferdig før den er solgt. Den har ingen verdi for brukeren og den tjener ikke
penger for fabrikanten. Det er veldig lett å måle fremdrift fordi vi får feedback på det vi har levert og feedback på hva
som fremdeles mangler. Hva er det viktigste for brukerne å få raskest mulig akkurat nå? Det er enkelt å skifte retning
eller eventuelt avbryte før du har brukt opp alle pengene.

14. KLAR UTVIKLING FERDIG!
For å få til dette så må vi ha en pull-basert prosess. Vi kan ikke drive med masse planlegging i forkant, ikke bruke masse tid på å
estimere, ikke utvikle oppgaver i parallell, ikke ha sprinter eller timebokser - nei, vi må fokusere på den oppgaven som kunden har
prioritert å jobbe med akkurat nå, og trekke den så fort og sikkert som mulig helt ut i produksjon.

15. ER IKKE DETTE RISIKABELT?
- Er ikkje dette veldig risikabelt då?
- Endring i seg sjølv er jo knytt til ein del risiko
-> Og jo oftare me prodsetter, vil me ikkje då introdusera desto høgare risiko?
- Produksjonssettinga kan sjølv gå gale -> applikasjonen går ned.
- Prodsetter halvferdige ting — Får me eit dårlig rykte?
- Kva med sikkerheit?
- Spørsmålet er med andre ord: Hvordan redusere risiko ved KL?
- Tingen er at dette er å sette saken på hovudet.
- Risikoen du tek ved å ikkje levere kontinuerlig er høgare enn desse til saman.

16. - Skal lage ein applikasjon
- Må levere eit minimum antal gongar ...
- Tradisjonelt sett har det å levere blitt sett på som fylt med risiko, då me går vekk ifrå noko som me veit fungerer, og ruller ut noko
uprøvd.

17. MANGE LINJER
KODE
LAAAANG TID
- Fordi det ofte blir sett på som risikofylt å levere, leverer me sjeldan.
- 1 gong i månaden eller mindre.
- Samle opp. Levere mange ting samstundes.
- Motsatt effekt. Som sagt, leverer me sjeldan:
- Mister masse feedback. Er på feil kurs?
- Prodsetter masse på ein gong -> meir kan gale

18. FÅ ENDRINGER
KONTINUERLIGE
LEVERANSER
- Logisk konklusjon -> levere oftere.
- Ruller ofte, og lite i gongen -> mindre kan gå gale.
- Lettere å lokalisere feil.
- Får raskere verifisere at det me lager faktisk er riktig ved å teste på reelle brukere
- Skifte kurs.

19. http://www.flickr.com/photos/55432818@N02/5500963965/
Ikkje problemlaust:
- Testing
- Produksjonssetting

20. - Infrastrukturen må vera automatisert.
- Du kan ikkje bruke 1 time på manuelle utrullingar om du leverer 1 gong daglig.
- Nyttig sjølv utan KL
-> bruker mindre tid på ting som ikkje gjer verdi
-> mindre tid på repetative oppgåver.
-> får jamnt over meir tid til verdiskapande oppgåver.

21. - Det viktigaste: Deployprosessen
- Alltid risikabelt
- Jo fleire manuelle steg i prosessen -> jo meir kan gå gale.
- Bør reduserast til eitt steg -> ergo: må automatiserast
- Automatisert -> tillit til prosessen
-> lågare terskel.

22. - Har me automatisert produksjonssettinga
- Tek vare på den forrige versjonen -> automatisert tilbakerulling.
- Eit alternativ til tilbakerulling når me utvikler utrygge ting
- Styre med konfigurasjons
- Går gale -> skru av.
- Teste ny funksjonalitet på et sub-set av brukerane

23. - Sjølv om me leverer kontinuerlig bør me ha samme forhold til kvalitet.
-> må testa.
-> men om det tek 3 dagar å teste applikasjonen og me prodsetter kvar dag ...
- Leverer hyppig -> treng ikkje teste alt.
- Få endringer, lite å teste per leveranse.
- Meir oversikt, mindre regresjonstesting.
- Testing gjer ikkje verdi, test kun det nødvendige.
- Fokuserer på de testene som vi vet at vi må gjøre ofte
og automatiser.

24. Utv
Test
Nå me jobbar på denne måten kan me heller ikkje ha ei eiga testavdeling. Me kan ikkje overlevere det me lagar til ei anna avdeling
og vente på at dei vert ferdige med testinga.
Få heller testarar inn på teamet, eller test sjølve.

25. HVA MED DRIFT?
Til nå har vi snakket veldig mye om utvikling. Hvordan passer drift inn i dette her.

26. Som nevnt så er ikke drift noe brukerne eller de som sitter med lommeboka er interessert i. De har kun lyst til å betale for ting de ser
gir verdi. De bryr seg ingenting om hva som foregår bak produktet. At det funker og er stabilt er en selvfølge. Det er kanskje så
innprenta i folk at de MÅ betale for drift. At det er et nødvendig onde, men etter min mening så burde de - og kreve - at drift skal
synliggjøre hvilken verdi de tilfører. Hvordan kan vi vite at de ikke sitter og gjør en masse unødvendige ting som ikke gir verdi i det
hele tatt, men som koster skjorta? Så hvordan kan også drift tilføre verdi?

27. Jeg vil ha Jeg vil ha
endring stabilitet
Utvikling Drift
Nå er vi inne på DevOps. DevOps er et uttrykk satt sammen av Dev og Ops. Altså Utvikling og Drift.
Tradisjonelt er dette to separate deler av organisasjonen. To ulike avdelinger. Det klassiske skillet er at utvikling ønsker å endre så
mye og så fort som mulig og å se endringene sine i produksjon. Mens drift ønsker å ha et så stabilt miljø som mulig. De måles på
forskjellige ting. Utvikling på endring og drift på stabilitet.

28. Vi vil skape
verdi
Dev Dev Ops Ops
Så hva er det nye? Det nye er ikke vanskeligere enn at drift og utvikling jobber sammen med ett mål for øye; å skape verdi. For verdi
er jo det eneste brukerne og forretning bryr seg om. De har behov for ny programvare som løser et behov raskt og som fungerer OG
programvaren må være tilgjengelig og stabil. Derfor må utviklere og drift jobbe sammen. DevOps er ikke en jobbtittel, men en
endring i organisasjonen, prosesser og måte å tenke på. Det handler om å løse oppgaver sammen, og ikke hver for seg.

29. HVA ENDRER SEG?
Hva endrer seg?

30. DevOps handler om 3 ting:
1. Automatisering
2. Smidighet
3. Kultur

31. Driftarens kvardag kan automatiserast ved hjelp av bl.a. provisjoneringsrammeverk. På denne måten kan ein programmatisk
provisjonera opp infrastrukturen sin, og nytta teknikkar og verktøy kjente frå programmerarane si verd: Kjeldekontroll, testdreven
utvikling, o.l. Har me infrastrukturen vår som kode, og i versjonskontroll, så kan me lett redda ein havarert infrastruktur ved å
sjekka ut siste fungerande versjon frå versjonskontroll.
- Når infrastrukturen er automatisert og alt går til helvete kan du veldig raskt kom deg opp igjen
- og du kan lett utvide serverparken din ved å enkelt trykke på ein knapp.
- Take-awayen er at infrastrukturen rundt applikasjonen er akkurat like viktig som applikasjonskoden i seg sjølv, og bør, og kan,
behandlast på samme måte.

32. http://commons.wikimedia.org/wiki/File:Simple_Feedback_02.png
Med ein DevOps-tankegang blir du meir smidig:
- Ved å automatisera infrastrukturen, og ved å automatisera utrullingsprosessen (frå utvikling til produksjon) blir det lettare å få
- ... jevnlig feedback på prosessen. For når den er automatisert og standardisert gjennom kode blir det lettare ...
- ... å forbedra den kontinuerlig. På denne måten blir det lettare for oss å fokusera på det som verkeleg betyr noko i ein
organisasjon ...
- ... nemling å levera verdi til brukarane våre.

33. Leveranse
Vi vil skape
verdi
- Men, det viktigaste er kultur.
- DevOps handlar om at utviklingsoppgaver og driftsoppgaver løses av samme team.
- Vi kan ikke ha siloer hvor leveranser kastes over veggen til neste silo.
- Det handlar om å rive ned siloane, og samarbeide for å levera verdi.
- ...

34. Utvikling Drift
http://www.flickr.com/photos/nasahqphoto/6196524554/
- For når ein organisasjon har det som mål å levera verdi til kundane sine, så seier det seg sjølv at andre prosessar som utvikling og
drift har som sitt primære mål å støtta opp under dette.
- I mange organisasjonar blir utvikling målt på ny funksjonalitet levert til produksjon, medan drift blir målt på oppetid og stabilitet.
- Desse to målingane er essensielt motstridande
- Det er ulogisk at to som begge har samme mål, skal bli målt på motstridande ting.
- Derfor må dei målast på det samme, som er realisert verdi.

35. AVSLUTTENDE ORD

36. "It is not necessary to change.
Survival is not mandatory."
-- W. Edwards Deming
Å levere kontinuerlig er ikke en fremtidsvisjon. Mange gjør dette allerede eller planlegger å gjøre det. Ved hjelp av nye verktøy og
prosesser dytter virksomheter idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Og dette får de til uten å
kompromisse på kvalitet. Og det er ingen grunn til at ikke alle kan gjøre dette her. Å si “dette passer ikke for oss”, “vi er annerledes
enn alle andre”, “vår applikasjon er for komplisert eller har for strenge krav” er bare tull. I en konkurransesituasjon vil det, etter vår
mening, være de som får til dette som overlever, og de som ikke får det til, vil forsvinne.

37. Ops?
Når det gjelder måten drift og utvikling samarbeider på, så må ting skje. Med DevOps-bevegelsen og deres nye
prosesser og verktøy, så kan drifting av applikasjoner forenkles dramatisk. NoOps er også et begrep. I NoOps så er
driftere overflødige. Netflix har for eksempel kun utviklere i sin organisasjon. De har automatisert bort drift. Egentlig er
NoOps bare en radikal avart av DevOps. Teamet skal kunne gjøre alt, både drifte, teste og utvikle. Det beste som kan
skje, mener vi, er at driftere og utviklere blir plassert på samme team, samarbeider, lærer av hverandre og blir målt på
det samme. Det er ikke noen grunn til at de ikke kan løse opgaver om hverandre. Skillet mellom driftere og utviklere
blir utvannet. På den måten ivaretar vi det beste fra to verdener.

38. Det er kanskje noen som synes at dette foredraget ikke forklarer HVORDAN man skal få til å levere kontinuerlig og å få til dette
fantastiske samarbeidet mellom drift og utvikling kalt DevOps. Det var heller ikke meningen. Det vi har forsøkt å formidle er hvilken
verdi kontinuerlige leveranser og DevOps kan gi. Hvordan det skal gjøres får dere spørre utviklerne og drifterne om.

39. Utviklere og driftere er vant til å løse utfordringer dagen lang. Det er det som er jobben deres. De finner ut løsninger på enhver
utfordring. Og jo mer ansvar de får, jo mer kreative blir de. Jo mer prosess, krav, rammeverk, osv. som blir dytta nedover hodene på
dem, jo mindre kreative blir de.
Stol på utviklerne og drifterne. De klarer å fikse det tekniske som gjør dette her mulig. Det handler bare om å gi de friheten og
tilpasse organisasjonen sånn at de kan samarbeide. Ikke jobbe mot hverandre.

40. TAKK FOR OSS!
Stein Inge Morisbak Sveinung Dalatun
Fagleder Kontinuerlige Leveranser og DevOps Konsulent
stein.inge.morisbak@BEKK.no sveinung.dalatun@BEKK.no
@steinim @sdalatun
http://open.bekk.no/

41. y
DevO ps Norwa
http://www.meetup.com/DevOps-Norway/
DevOps Norway + Q & A