Your SlideShare is downloading. ×
  • Like
Verdien av kontinuerlige leveranser
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Verdien av kontinuerlige leveranser

  • 456 views
Published

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?

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?

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
456
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 betalefor programvaren som lages: Er du interessert i å betale for estimering, planlegging, testing, godkjenning, drift osv. osv.? Egentligikke. Er du interessert i å betale for programvare som skaper verdi for brukerne og deg sjøl? Ja. Det er i grunnen det eneste du somsitter 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 enmå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 duser 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 detde 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 nyeting som perler på en snor. Google er et kroneksempel på det. Eks. Gmail. Starter med enkel epostleser - utviderkontinuerlig.
  • 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 nedetidHvor ofte er hyppig? Det vil variere. En uke, en dag, flere ganger hver dag. Hver andre uke er for sjeldent. Noe firmaerproduksjonssetter tusenvis av ganger om dagen, som Amazon -> gå gjennom tall. Store firmaer med hundrevis av utviklere. For etteam på 4 eller 8 utviklere er det ikke realistisk å produksjonssette så ofte. Det tar tross alt litt tid å utvikle noe. På Digipost har vilevert 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 knallhardtfor å 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 tingbasert 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 verdiumiddelbart. Akkurat som at en bil ikke er ferdig før den er solgt. Den har ingen verdi for brukeren og den tjener ikkepenger for fabrikanten. Det er veldig lett å måle fremdrift fordi vi får feedback på det vi har levert og feedback på hvasom fremdeles mangler. Hva er det viktigste for brukerne å få raskest mulig akkurat nå? Det er enkelt å skifte retningeller 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 harprioritert å 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 nokouprø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 TestNå me jobbar på denne måten kan me heller ikkje ha ei eiga testavdeling. Me kan ikkje overlevere det me lagar til ei anna avdelingog 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 sergir 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 skalsynliggjø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 dethele tatt, men som koster skjorta? Så hvordan kan også drift tilføre verdi?
  • 27. Jeg vil ha Jeg vil ha endring stabilitet Utvikling DriftNå 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 OpsSå 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 verdier jo det eneste brukerne og forretning bryr seg om. De har behov for ny programvare som løser et behov raskt og som fungerer OGprogramvaren må være tilgjengelig og stabil. Derfor må utviklere og drift jobbe sammen. DevOps er ikke en jobbtittel, men enendring 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 programmatiskprovisjonera opp infrastrukturen sin, og nytta teknikkar og verktøy kjente frå programmerarane si verd: Kjeldekontroll, testdrevenutvikling, 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.pngMed 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 einorganisasjon ...- ... 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 ogdrift 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 ogprosesser 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 annerledesenn alle andre”, “vår applikasjon er for komplisert eller har for strenge krav” er bare tull. I en konkurransesituasjon vil det, etter vårmening, 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 nyeprosesser og verktøy, så kan drifting av applikasjoner forenkles dramatisk. NoOps er også et begrep. I NoOps så erdriftere overflødige. Netflix har for eksempel kun utviklere i sin organisasjon. De har automatisert bort drift. Egentlig erNoOps bare en radikal avart av DevOps. Teamet skal kunne gjøre alt, både drifte, teste og utvikle. Det beste som kanskje, 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 utviklereblir 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 dettefantastiske samarbeidet mellom drift og utvikling kalt DevOps. Det var heller ikke meningen. Det vi har forsøkt å formidle er hvilkenverdi 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å enhverutfordring. 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 ogtilpasse organisasjonen sånn at de kan samarbeide. Ikke jobbe mot hverandre.
  • 40. TAKK FOR OSS!Stein Inge Morisbak Sveinung DalatunFagleder Kontinuerlige Leveranser og DevOps Konsulentstein.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