Kontinuerlige Leveranser og DevOps er praksiser som lar virksomheter dytte idéer ut til sine kunder før andre er ferdige med sin første iterasjon. Kvaliteten på det som leveres øker i takt med hyppigheten på leveransene. Tettere samarbeid mellom drift og utvikling bidrar til at alle trekker i samme retning. Det er forretning som bestemmer når noe skal ut i produksjon, ikke IT. Vi er vitne til et av de største paradigmeskiftene innen IT i vår tid. De som ikke transformerer sine IT-organisasjoner risikerer å bli etterlatt for å dø. Stein Inge vil i dette foredraget forklare hva DevOps og Kontinuerlige Leveranser innebærer og hvorfor det er så viktig å ikke bli sittende på gjerdet. Han vil også presentere egne erfaringer med å levere kontinuerlig.

1. DevOps eller dø!

2. – Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014
“Enterprise DevOps Adoption Isn’t Mandatory
— but Neither Is Survival.”

3. – Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014
“Those not transforming their IT organizations
risk being left behind, missing out on one of the
most disruptive and innovative periods in
technology.”

4. - Gene Kim
“IT is the factory floor of this century, and not
just for manufacturing companies. IT is
increasingly how all businesses acquire
customers and deliver value to them.”
IT er ikke lenger en tjeneste som støtter opp under forretning.
IT er ansvarlige for hele virksomhetens suksess.

5. Hva er DevOps?

7. DevOps er ikke en stillingsbeskrivelse.

9. DevOps er ikke verktøy.

10. DevOps er …

11. - Barton George, Dell
“…it is getting developers and operations folk to
work closely together to benefit the business.”

12. Drift Utvikling
Jeg vil ha
stabilitet
Jeg vil ha
endring

13. Leveranse

14. Dev
Vi vil
skape
verdi
OpsDev Ops

15. , men så er det litt de andre tingene også…

16. - WhatIs.com
“DevOps is the blending of tasks performed by a
company's application development and
systems operations teams.”
Kryssfunksjonelle team betyr ikke at alle skal kunne gjøre alt.
Drift krever en helt egen spisskompetanse. På samme måte som utvikling.
Oppgavene flyter over i hverandre og alle er på samme team. Ingen overleveringer.

17. - Gene Kim
“…the practices that enable fast flow of features
into production, while preserving world-class
availability, stability, security, etc.”
Praksiser, verktøy og flinke folk som kan sørge for en taktfast og rask flyt av verdifull programvare til produksjon. Uten at det går ut over tilgjengelighet,
stabilitet, sikkerhet osv. Da trenger du eksperter - Devopser. Og du trenger nye verktøy.

18. Hva er
Kontinuerlige Leveranser?
DevOps gjør det mulig å virkelig kunne levere kontinuerlig.

19. Vår høyeste prioritet er å tilfredsstille kunden
gjennom tidlige og kontinuerlige leveranser
av programvare som har verdi.
Første prinsippet i Smidigmanifestet. Hvorfor? Ikke bruke tid på ting som ikke gir. Vite at det vi lager er verdifullt for brukerne så fort som mulig. Kunne reagere på
endringer i forutsetninger raskest mulig. Kunne tilfredsstille brukerne med ny funksjonalitet og endringer kontinuerlig.
DevOps-bevegelsen, i tillegg til å levere kontinuerlig, skal opprettholde tilgjengelighet, stabilitet, sikkerhet, ytelse osv. i verdensklasse. Utvider fra å se på
applikasjonene - til å se på hele systemet inkludert infrastruktur.

20. - Martin Fowler
(http://martinfowler.com/bliki/ContinuousDelivery.html)
“Continuous Delivery is a software development
discipline where you build software in such a way
that the software can be released to
production at any time.”
Forretning skal kunne si at koden, akkurat slik den er nå, skal deployes til produksjon på et blunk - og ingen skal lee et øyelokk. Ingen panikk. Dagligdags.
Gir også høyere kvalitet. Den eneste realistiske testingen skjer i produksjon.

21. Prodsettinger har vært ansett som risikable.

22. MANGE
LINJER KODE
LAAAAANG TID
Fordi prodsetting er så risikofyllt gjør man det sjeldent og bruker masse tid på testing. Når det treffer produksjon skjer det som regel et eller annet, og
det er vanskelig å finne ut av hva som er feilen. Når det er mye som er endret er det mye som kan gå galt.

23. KONTINUERLIGE
LEVERANSER
FÅ ENDRINGER
Logisk konklusjon; lever oftere. Rulle ofte, og lite om gangen; mindre som kan gå galt. Lettere å lokalisere feil. Lett å rulle tilbake - eller frem som er å
foretrekke (fiks, deploy på nytt). Får raskere verifisert at det vi lager faktisk er riktig ved å teste på reelle brukere. Lett å skifte kurs.

24. For tregt. For mye “greier”. Alt for mange “sikkerhetsmekanismer”. Sikrer ikke bedre enn å virkelig levere kontinuerlig.

25. Test
Utv
Kan ikke ha en egen testavdeling. Kan ikke overlevere det vi lagar til en annen avdeling og vente på at de skal bli ferdige med testinga. Test sjøl og på
reeelle brukere. Myte at det ikke bør være de samme som har laget noe som skal teste dette noe. Du må vite hvordan noe er implementert for å teste det
skikkelig.

26. “Developers carry beepers”
Definition of DevOps
Utvikleren prodsetter selv det han lager. Tar dermed større ansvar. Sørger for tilstrekkelig testing og at prodsetting vil fungere. Har ingen andre å skylde
på.

27. Krav
Konsept
Analyse
Design
Test
Drift
Realisering
Eksempel på prosjektmetodikk som er utbredt i bransjen. Prince II. Smidig er en liten del av gjennomføringsfasen. Gevinster realiseres ikke før etter at prosjektet er
levert.

28. Kunde
Brukere
The holy trinity
is not
is not
is not
is
TEAM
is
is
DevOps-team
Den moderne IT-organisasjonen er lettvekts.
Brukerne skal bruke softwaren. Gi verdi for de. Men det er ikke de som skal tjene penger.
Det er det kunden som skal. Bør være det viktigste i hele verden, så han deltar tett sammen med teamet.
DevOps-teamet skal lage den fysiske softwaren. De skal ikke finne ut av hva som skal lages. Det er det brukerne som skal.
Skal sikre at kunden tjener penger. Lynraske iterasjoner. Lage noe — teste på brukerne — bygge ut i bredden eller forkaste.
Skalerer i store organisasjoner. Satelitter med autonome team.

29. «The State of DevOps Report», juni 2014. Det største og mest omfattende vitenskapelige DevOps-studiet så langt.

30. Demografi
9200+
Respondenter fra
110 land,
på tvers av bransjer
9,200+ respondener fra 110 land, på tvers av alle bransjer.

31. Størrelse på bedriftene
27%
av respondentene er
fra virksomheter med
500 til 9999 ansatte
Virksomheter i alle størrelser.
- 27 % med 500 til 9,999 ansatte
- Ikke bare de store WebOps sjappene som: Google, Amazon, Etsy, etc.

32. Størrelse på infrastrukturen
51%
av respondentene
sa de hadde
< 500 Servers
- Majoriteten har færre enn 500 servere. Største prosentandel har under 100.
- Kun 13 % har mer enn 5,000 servere
- DevOps er ikke bare for store websjapper.
- Kombinert med bransjedekning sier det mye om hvilken ekspansjon dette har hatt.

33. Avdelinger
16%
identifiserte seg som
DevOps Avdeling
- 30% av respondentene var fra drift.
- 29% var fra utvikling.
- 16% av respondentene var i en DevOps-avdeling(!).

34. Fjorårets rapport
Mer smidige og robuste:
• deployer kode 30 ganger
oftere.
• med 50 prosent færre
feil.

35. Årets rapport
Ting som betyr noe for businessen:
• Lønnsomhet
• Markedsandeler
• Produktivitet
Sammenhengen mellom:
• Organisatorisk ytelse,
• IT-ytelse og
• DevOps-praksiser.

36. DevOps er Smidigere
30x 8000x
hyppigere
deployments
raskere ledetid enn
konkurrenten

37. DevOps er mer robust
2x 12x
suksessrate
ved endringer
raskere mean time to
recover (MTTR)

38. vekst i
markedsverdi i
løpet av 3 år
2x
DevOps vinner
større
sannsynlighet for
å overgå
lønnsomhet,
markedsandel og
produktivitetsmål
50%
Foreløpige funn tilsier at de har fått et 50% forsprang på konkurrentene over 3 år - basert på de virksomhetene som oppga navn på virksomheten og som var
børsnotert. Færre enn 400 virksomheter av de 9200. Dette er noe de vil se nærmere på i neste års undersøkelse.

39. Toppindikatorer for IT
Performance
• Peer-review av produksjonsendringer
(versus ekstern endringsakseptanse).
• Versjonskontroll av alle produksjonsartefakter.
• Proativ monitorering av produksjonsmiljøet.
• Kultur med høy grad av tillit, og klima for læring.
• Vinn-vinn-vinn mellom Dev, Ops og Sikkerhet.
• Høy jobbtilfredshet.

40. Jobbtilfredshet er #1
forklaring på hvor bra en
organisasjon gjør det!

41. Overaskende (?) funn
• Versjonskontroll av miljøet er viktigere enn versjonskontroll av
koden.
• Å kunne statistikk har aldri vært så viktig.
• Om du har en integrasjons- eller stabiliseringsfase har null
påvirkning på IT performance.
• Peer review er mer effektivt enn CAB.
• DevOps-praksiser påvirker virksomhetens suksess.
• Feilrate påvirker ikke IT performance lenger (!).
• Å lage DevOps team og å gi folk DevOps-titler gir suksess i praksis.
Versjonskontroll av miljøet er viktigere enn versjonskontroll av koden! Hypotese; flere konfigurerbare deler i plattformen.
Statistikk på alt som skjer. Feedback på systemet som et hele.
Peer review vil garantert øke throughput, men man kunne trodd at det ville forringe stabilitet. Not so.
DevOps-praksiser og IT-performance påvirker hvordan hele organisasjonen yter. DevOps er ikke bare IT. Det er IT-praksis.
Blir lagt merke til utenfor DevOps-communitien. Kan ikke risikere å ignorere det lenger.
Feilrate påvirker ikke IT performance lenger. Teori; dagens infrastruktur er bygd for å holde seg oppe.
Automatiserer tester og bruker chaos monkeys i produksjon. Hot-fikser teller ikke som ordentlige feil lenger?
Å lage DevOps team og å gi folk DevOps-titler gir suksess i praksis.

42. DevOps i Norge - attention
600+ medlemmer
50/50 driftere og utviklere
DevOps-track
I tillegg veldig godt representert på andre konferanser.
Oslo Puppet Meetup
Docker Oslo
Elasticsearch Oslo
(Redpill Linpro)
(Redhat Norway)

43. DevOps i Norge - utbredelse?
?

44. One-click deploy.
Helt team. PO, Salg, Brukerdialog, Utvikling, drift.
Utviklere har tilgang til produksjon.
Verdi for forretningen viktigst.
Kunden er involvert i det daglige arbeidet. Det viktigste kunden kan foreta seg.

45. • ≈ 11 utviklere fra BEKK
• ≈ 10 salg, produkt, marked fra
Posten
• “Startup-ish”
• Helt team
• Selvorganisert og kryssfunksjonelt.
• Har “kuttet alt smidig”
• Pull not push
• Prodsetter kontinuerlig (one click)
• Nedetidsfri deploy
• Automatiserer “alt”
• Prodsetter uferdig funksjonalitet
• Feature toggles
• Velger teknologi selv
• Open Source
• “Løs arkitektur” (REST)
• DevOps
• Monitorering
• Utviklere har beredskap
• Infrastruktur som kode
• Alt i versjonskontroll
• Kontinuerlig integrasjon
• Synlighet og transparens
Er vi fremdeles Smidig? Ikke retrospekter. Ikke “tradisjonell Kanban” (ikke wip). “Ikke planlegging”. Ingen “story points”. Ingen timebokser. Ingen
releaseplan. Ingen burndown. Ingen måling av “velocity” “Ingen” frister. Ingen Scrum Master. Tillater spesialisering. “Avslappede” brukerhistorier.
Kontinuerlig forbedring! (Vite hva det betyr! Kan ikke lese deg til det.)

46. Modenhetsmodellen:
http://bekkopen.github.io/maturity-model/
http://www.ndcmagazine.com/a-maturity-model-for-continuous-delivery
http://open.bekk.no/a-maturity-model-for-continuous-delivery

47. “Enterprise DevOps Adoption Isn’t Mandatory
— but Neither Is Survival.”
– Gene Kim, The Wall Street Journal, CIO Journal, 22. mai, 2014

48. TAKK FOR MEG!
Stein Inge Morisbak
Fagleder Kontinuerlige Leveranser og DevOps
stein.inge.morisbak@BEKK.no
@steinim
http://open.bekk.no/