DevOps-loopen och "Release on Demand"
DevOps-loopen
Om du skulle googla på "devops loop" skulle du förmodligen få mängder av träffar med varianter av följande bild:
Loopen försöker beskriva tanken med ett evigt kretslopp i utvecklingslivscykeln från planering till produktion via feedback tillbaka till planering och så vidare. Du kanske inte reflekterar över varje enskilt steg i loopen utan tänker att de beskrivna stegen och dess ordning verkar rimliga.
Jag som jobbar med att sprida budskapet kring säker utveckling och vikten av att lägga in aktiviteter kopplade till säkerhet i utvecklingslivscykeln har använt DevOps-loopen som ett pedagogiskt verktyg för att illustrera exempel på säkerhetsaktiviteter och dess plats i loopen:
I “Plan” jobbar vi med C-I-A och Privacy-krav samt hotmodellering.
I “Code” jobbar vi med pull-request/peer-review.
I “Build” jobbar vi med statisk kodanalys (SAST) och skanning efter användning av sårbara externa komponenter (SCA) i vår build-pipeline.
I “Test” jobbar vi med säkerhetsrelaterade tester, kanske skapade utifrån resultatet av en penetrationstest med ansatsen "hur kan vi säkerställa att detta inte händer igen".
Ni fattar tanken. Men när man kommer till “Release” och “Deploy” så blir det lite problematiskt. Kanske inte med att mappa aktiviteterna i sig men med frågeställningen, kommer verkligen “Release”-steget innan “Deploy” i en modern utvecklingslivscykel?
Release on demand
Av ren nyfikenhet på SAFe så gick jag en "Leading SAFe"-utbildning under våren och där pratade vi "Release on Demand" i avsnittet där man beskriver "Build a Continuous Delivery Pipeline with DevOps". Tanken är att du ska separera "deploy to production" från "release" så att värdet av det du gör görs tillgängligt när det behövs.
“Release on Demand - Making value available when it's needed”
I den DevOps-loop som används i deras material har man bytt plats på “Release”- och “Deploy”-stegen:
och då försvinner plötsligt problemet jag började med att beskriva kring ordningen på “Release”- och “Deploy”-stegen.
I “Deploy” sätter vi ny funktionalitet i produktionsmiljön men den görs inte tillgänglig för kunden direkt utan nya funktioner kanske döljs bakom feature flags eller så använder vi canary-releases för att testa ny funktionalitet på en begränsad mängd användare till en början.
I “Release” gör vi ny funktionalitet tillgänglig för alla kunder när det passar. Kanske direkt eller vid ett strategiskt valt tillfälle.
Den nya ordningen på stegen i DevOps-loopen känns helt rätt.
Så för att avsluta visar jag den alternativa (korrekta) versionen av DevOps-loopen med mina exempelaktiviteter kring säkerhet utmappade:
Den nya DevOps-loopen med exempel på säkerhetsaktiviteter i respektive steg
/Mats Persson - Säkerhetskonsult på Omegapoint, Mats LinkedIn-profil - 2020-09-08