KONTINUERLIGE LEVERANSER OG DEVOPS

Software 2013Sveinung Dalatun og Stein Inge Morisbak

13/02/13

Hva gir det av verdi?

- Hva er kontinuerlige leveranser og hva er DevOps?

- Hva gir det av verdi?

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?

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.

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.

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!

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

HVA ER KONTINUERLIGE LEVERANSER?

Det er her Kontinuerlige leveranser som metodikk kommer inn. Så hva er egentlig kontinuerlige leveranser?

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.

HVORDAN?

Hvordan får vi til det?

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.

10.000deployments i timen

11,6 sek.mellom deployments

.001%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.

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.

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.

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.

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.

- 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.

LAAAANG TID

MANGE LINJER KODE

- 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

KONTINUERLIGE LEVERANSER

FÅ ENDRINGER

- 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.

http://www.flickr.com/photos/55432818@N02/5500963965/

Ikkje problemlaust:

- Testing

- Produksjonssetting

- 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.

- 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.

- 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

- 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.

Test

Utv

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.

HVA MED DRIFT?

Til nå har vi snakket veldig mye om utvikling. Hvordan passer drift inn i dette her.

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?

DriftUtvikling

Jeg vil ha stabilitet

Jeg vil ha endring

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.

Dev

Vi vil skape verdi

OpsDev 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.

HVA ENDRER SEG?

Hva endrer seg?

DevOps handler om 3 ting:

1. Automatisering

2. Smidighet

3. Kultur

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.

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.

LeveranseVi 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.

- ...

http://www.flickr.com/photos/nasahqphoto/6196524554/

DriftUtvikling

- 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.

AVSLUTTENDE ORD

"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.

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.

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.

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.

TAKK FOR OSS!

Stein Inge MorisbakFagleder Kontinuerlige Leveranser og DevOps

stein.inge.morisbak@BEKK.no@steinim

Sveinung DalatunKonsulent

sveinung.dalatun@BEKK.no@sdalatun

http://open.bekk.no/

http://www.meetup.com/DevOps-Norway/

DevOps Norway

DevOps Norway + Q & A