DevOps – tar dere ut potensialet?
Det er nå over 12 år siden DevOps ble introdusert og tankesettet har siden den gang påvirket de fleste organisasjoner som driver systemutvikling. Mange har kommet i gang med automatisering av noen prosesser, og med for eksempel automatiserte bygg og skriptet infrastruktur opplever man tidlig økt effektivitet med raskere utvikling, nedgang i feilsituasjoner og hyppigere utrullinger. Ofte utføres likevel fremdeles deler av utviklingsprosessen i siloer, og man får ikke tatt ut hele potensialet som ligger i DevOps.
Kjernen i DevOps er å bryte ned de tradisjonelle siloene for å samarbeide bedre på tvers og fjerne flaskehalser. Hvilke siloer og flaskehalser man har vil være ulikt i alle organisasjoner. De vil også forandre seg over tid. Noen har for eksempel store utfordringer med forsinkelser knyttet til infrastruktur mens andre sliter med at utviklerne må jobbe med brannslukking i stedet for å prioritere de oppgavene som gir mest forretningsverdi. Organisasjoner må altså starte med å kartlegge sine egne utfordringer for så å definere hva man ønsker å oppnå med DevOps. De aller fleste opplever at markedet rundt seg endres stadig raskere, og ønsker med DevOps å oppnå en utviklingsprosess som reduserer tid fra idé til verdiskapning i produksjon. Fokus på konkret verdiskapning vil ofte føre til ønske om målbare krav til hva som regnes som verdi og kontinuerlig tilbakemelding fra kunder, som igjen kan lede til kontinuerlig forbedring basert på reel kunnskap i stedet for magefølelse. For å ta ut mer av potensialet i sin DevOps-satsning må en i tillegg til automatisering ha på plass eller bygge:De virkelig store verdiene oppnår man ikke før hele organisasjonen forstår at DevOps er mer enn utviklere, driftere og skript
Teamet i et Devops-miljø skal bestå av kompetanse og kapasitet som gjør at man har minst mulig avhengigheter til andre. Dette for å unngå flaskehalser ved f.eks. overleveringer eller behov fra andre team eller personer. Poenget er ikke bare å sette sammen utviklere og drift i et team, men å tenke på hele systemutviklingsprosessen som en kontinuerlig prosess fra idé til produksjon og vedlikehold. Teamene skal altså, så langt det er mulig, jobbe autonomt og ta ansvar for all funksjonalitet som utvikles hele veien fra start til produksjon. For å lykkes med dette må teamet ha alle roller som man tradisjonelt har i smidige team: I et DevOps-team har man også ansvaret for koden i produksjon og dermed vil utviklerne ha en større bevissthet rundt hva som kreves av koden for å sikre stabil drift. Det vil også gå raskere med retting av feilsituasjoner da utrullingen til produksjon er hyppige, men små, og teamet gjør fortløpende justeringer basert på erfaringer fra produksjon og tilbakemelding fra brukerne.Kultur
“DevOps er en kultur, en kultur for at alle i teamet samarbeider om ansvaret for koden, fra den planlegges til den er i produksjon.”
For å øke hastigheten og redusere feilsituasjoner er det ønskelig å automatisere så mye som mulig av prosessen fra utvikleren har sjekket inn koden til den er ute i produksjonsmiljøet. Vi ønsker for eksempel å unngå avhengigheter til andre team eller en knapp ressurs, og vi ønsker å redusere feilsituasjoner ved å teste tidligere. Kontinuerlig integrasjon (CI) og kontinuerlige leveranser (CD) er eksempler på essensielle deler for å få til denne automatiseringen, og viktige verktøy er CI-servere og en plattform for automatisert deploy. Eksempler på verktøy for dette kan være Azure DevOps, Github Actions og Team City. Automatisert testing og oppsett av infrastruktur kan være en del av denne prosessen. Hvilke teknologier som fungerer best til automatiseringen avhenger av kompetansen i teamet, størrelsen på teamet, behov for kontroll og mye annet. På samme måte som bygg, deploy og testing skriptes for å sikre reproduserbare resultater, så er det ønskelig at infrastruktur som applikasjonen kjører på skal være scriptet i størst mulig grad. Her finnes det flere gode alternativer og noen eksempler er Azure CLI, Terraform og Pulumi.Automatisering
I et Devops-miljø får man ut endringer i produksjon oftere, og da må man også teste endringene hyppigere. For at dette skal fungere og flyte godt, bør en automatisere så mulig som mulig av testene Testaktivitetene blir et felles ansvar i teamet. Vi snakker om automatiske enhets-, funksjonelle- og regresjonstester – og slutter med systemtester og akseptansetester. Teamet har sammen ansvar for testing og forbedring gjennom kontinuerlig overvåkning av stabilitet, sikkerhet og ytelse. Arkitektur, Kultur, automatisering og kontinuerlig testing vil forbedre en systemutviklingsprosess, men arkitekturen i bunn vil også være en viktig premissgiver for hvor stor effekt disse elementene vil ha.Test og overvåkning
Hvis systemet ikke er designet for å bli testet og rullet ut raskt, enkelt og ofte, vil du ende opp med en flaskehals som ikke lar teamet jobbe så raskt som de ønsker. Derfor er det viktig å også fokusere på viktige ikke-funksjonelle krav knyttet til målene du vil oppnå, som modularitet, testbarhet og smidighet. Det er viktig å tenke på at applikasjonen for eksempel skal kunne kjøre enhetstester og hver komponent skal kunne testes så snart den er utviklet. Systemet bør være designet i komponenter som kan testes og distribueres uavhengig (dvs. tjenester, køer osv.) Man kan oppnå DevOps med ulike arkitekturer som for eksempel mikrotjenester, serviceorientert eller hendelsesdrevet arkitektur. Utfordringen er å velge den som passer best til dine behov og eksisterende infrastruktur.Arkitektur
Det finnes ingen fasit på hvordan DevOps implementeres, men det er viktig å erkjenne at det er en kontinuerlig reise hvor en hele tiden må etterstrebe å jobbe mer effektivt. Mange bruker KPI-er som måletall for å evaluere sin DevOps måloppnåelse. DevOps KPI-ene er med å hjelpe oss å sikre at vi jobber bedre og bedre. Fire eksempler på KPI-er for å måle fremgang vi har sett brukt:Måle fremgang
Vi i Novanet har vært med på både det å innføre DevOps-verktøy og befeste DevOps-kultur i organisasjoner. Trenger du hjelp til å ta ut mer potensiale av din DevOps-satsning?
Ta kontakt med Lars Alexander for en prat om DevOps