Artikelserie: DevOps del 1 av 3

DevOps - samarbete, helhetsansvar och ständiga förbättringar 

DevOps – sammanslagningen av Development och Operations är ett populärt ämne just nu men har funnits som begrepp i över 10 år. Det agila manifestet kom 2001 och termen DevOps 2009, så förändring tar tid även om det är hyperpopulära begrepp. Men vad innebär DevOps? Nedan ett citat som är en ganska kort och bra beskrivning i ord: 

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."- Donovan Brown, Microsoft 

Att få utvecklare och driftspersoner att samarbeta har inte alltid varit självklart. I många år var det utvecklingsteamet som firade på fredag eftermiddag att de var klara med releasen och önskade driftgänget lycka till med produktionssättningen under helgen! 

Kärnan i DevOps är att vi måste samarbeta mer och till och med jobba i samma team för att leverera värde till våra kunder (s.k. korsfunktionella team). Dessa team kategoriseras ofta som produktteam där teamet jobbar med en eller flera funktioner eller produkter över tid. Detta till skillnad från projektteam som har en kortare livslängd och ofta lämnar över resultatet, klart eller inte, till en förvaltningsorganisation. En annan skillnad är att produktteam är ansvariga end-to-end, från inhämtande av krav och feedback från kunden till leverans av värde tillbaka till kunden. De sitter närmast informationen och har den kunskap som krävs för att ta rätt beslut.

”DevOps team är ansvariga för att designa, bygga, leverera och supporta den kod de skriver.”

“You build it, You run it” 

Begreppet ”You build it, You run it” kommer ursprungligen från Amazon där produktteamen fick driftsansvar för sina produkter. Det ledde till bättre kvalitet för kunderna och även stabilare leverans av tekniken. ”You build it, You run it” ger teamet daglig kontakt med kunden där den snabba kundfeedbacken ökar kvaliteten. Det ger även direkt kontroll över hur teamets produkt fungerar i produktion.

Enligt DevOps är det teamet som känner sin produkt bäst som också borde vara ansvariga för supporten av sin produkt. Att team tar supportansvar för sin produkt 24/7 kommer resultera i stabilare och säkrare applikationer då alla vet att de som "drabbas" är teamet själva. Att ha jour för sin produkt borde inte vara konstigt och målsättningen för teamet borde vara att jourveckan ska vara ett sätt att tjäna extra pengar som belöning för att de byggt en stabil och säker produkt (då det inte kommer vara några incidenter på nätterna 😊).

Inspiration från Lean och Continuous Delivery 

DevOps har tagit mycket inspiration från Lean där flöde, feedback, och kontinuerligt experimenterande och lärande samt värdeströmmar är viktiga principer. I boken ”The Phoenix Project” lanseras de tre principerna som ligger bakom många av de beteenden som skapar väl fungerande DevOps team: 

Den första principen – Flöde; snabba upp flödet från utveckling via drift till kunden. För att uppnå detta jobbar teamet med att synliggöra arbetet, minska storleken och korta intervallerna på utfört arbete samt öka kvaliteten på det som levereras.  

Den andra principen – Feedback; skapa kortare feedbackloopar i alla steg i värdeströmmen. Den handlar om att upptäcka fel och brister så tidigt som möjligt och jobba med kontinuerliga förbättringar. 

Den tredje principen – Kontinuerligt experimenterande och lärande; skapa en miljö där teamet jobbar med experiment och där lärande från både framgångar och misslyckanden, är också ett viktigt inslag.  

Continuous Delivery rörelsen har också inspirerat DevOps med sin ”deployment pipeline” där kod och infrastruktur alltid befinner sig i ett releasebart tillstånd. 

DevOps-inspirerad utvecklingslivscykel 

Ofta används DevOps-loopen för att beskriva det eviga kretsloppet från planering till produktion:

Om du googlar på ”devops loop” är de flesta träffar en variant av ovan bild där ”Release” kommer före ”Deploy” men det är inte helt korrekt då Deploy kanske görs till en produktionsmiljö men den nya versionen är först tillgänglig för kunden vid ett senare tillfälle, “release on demand”.

Det finns ett blogginlägg om den korrekta ordningen på ”Deploy” och ”Release” samt en introduktion till termen “release on demand” som du hittar här https://omegapoint.academy/amplitude/devops-loopen-och-release-on-demand. 

Optimera arbetsflödet från planering till produktion 

DevOps-loopen beskriver ett evigt kretslopp med åtta delområden där teamet kontinuerligt jobbar med att optimera sitt arbetsflöde. Det får effekten att de tar sig runt loopen på kortare och kortare tid. Att optimera arbetsflödet betyder inte att de hoppar över viktiga kvalitetsaspekter som t.ex. stabilitet och säkerhet, utan att teamet jobbar med att automatisera och effektivisera. I början kan det ta månader att komma från planering till produktion. Med kontinuerlig optimering kan det sedan minska till en månad, två veckor, en vecka och slutligen kanske bara en dag. Då har teamet kommit så långt i sin mognadsresa att de jobbar med sann Continuous Deployment. Varje gång de checkar in kod så skapas en ny release i produktion. 

CI/CD – Continuous Integration/Continuous Delivery 

Även om People och Process är minst lika viktiga som Products så får ofta en automatiserad CI/CD pipeline mycket fokus när man pratar om DevOps. Förmodligen för att det uppfattas som enklare och mer konkret att prata om vilka verktyg och vilken teknologi vi måste börja använda för att kunna bli ”DevOps”. 

Att välja en modern och välfungerande CI/CD miljö är dock viktigt för att möjliggöra kontinuerlig leverans. Men vad menas med CI/CD? 

Continuous Integration – all kod som en utvecklare skriver ska integreras med de andra teammedlemmarnas kod så ofta som möjligt. I detta sammanhang är ”ofta” varje dag eller åtminstone varannan dag. 

Continuous Delivery - idén och synsättet att varje bygge skulle kunna vara en potentiell release. 

Continuous Delivery vs Continuous Deployment 

Förkortningen CD i CI/CD skulle kunna betyda både Continuous Delivery eller Continuous Deployment (där det vanligaste är Continuous Delivery). Nedan bild är ett sätt att förklara skillnaden mellan Delivery och Deployment:  

Continuous Delivery – här är resultatet av er pipeline något som kan sättas i produktion om ni bestämmer er för det. Beslutet tas baserat på automatiserade tester eller manuella tester men det är fortfarande ett manuellt steg att gå till produktion.   

Continuous Deployment – här sker produktionssättningen automatisk varje gång, baserat på att alla tidigare tester i pipeline har gått bra och gett självförtroendet att våga gå live utan manuella steg. 

Säkerhet som en naturlig del i DevOps 

Att integrera DevOps med aktiviteter kopplade till säkerhet kallas ibland för DevSecOps, men för oss på Omegapoint är säkerhet en naturlig del i DevOps.   

Vi anser att aktiviteter kopplade till säkerhet borde vara en lika naturlig del av arbetet som testning. För att ta ett helhetsansvar för sin produkt end-to-end så ingår testning, säkerhet, drift och 24/7 support för produkten.    

Det här innebär att de som traditionellt haft ansvar för säkerheten delvis får nya uppgifter. När arbetssättet förändras kommer de bland annat få ansvar för att hjälpa produktteamen att identifiera vilka aktiviteter som bidrar med tillräcklig säkerhet utan att bromsa tempot.