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?
Foredrag av Sveinung Dalatun og Stein Inge Morisbak.
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?
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.
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!
• 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.
om gangen. • Produksjonssette straks en oppgave er ferdig. Produksjonssette hyppig. Jobbe på en ting om gangen. Produksjonssette straks en oppgave er ferdig.
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.
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.
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.
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.
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.
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.
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
- 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.
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.
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.
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
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.
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.
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?
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.
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.
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.
å 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.
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. - ...
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.
-- 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.
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.
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.
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.
steinim
datarian
hanacchi
yanaemon
yoshikiiida
yudai00
shuta13
genkiogasawara
sioncojp
nrryuya
yamato_sorariku
nabeliwo
o11yfes2023
lynnandtonic
tmm1
shpigford
chriscoyier
addyosmani
michaelherold
nonsquared
kevinliebholz
tenderlove
rmw
lara
