Vi får frågan ofta — i upphandlingar, på intervjuer och i kafferaster: ”Är inte Delivery Engineering bara ett nytt namn på DevOps?” Korta svaret är nej. Längre svaret är värt fem minuter.
DevOps är ett arbetssätt
DevOps växte fram som en motreaktion på den klassiska väggen mellan utvecklare som skriver koden och operations som driftar den. Idén är enkel: samma team som bygger funktionen ska också ansvara för att den funkar i produktion. ”You build it, you run it.” Det är inte en roll — det är ett sätt att organisera ansvar.
Praktiskt innebär det att utvecklingsteam äger automation, observabilityObservabilityObservability är förmågan att förstå vad som händer inuti ett system utifrån det som går att observera — metrics, loggar, traces och events — så att frågor kan besvaras som ingen förutsåg när systemet byggdes.Läs mer i ordlistan →, on-call och infrastrukturen kring sin egen tjänst. Inte hela molnplattformen — bara sin del av den. Och fördelningen mellan ”sin del” och ”någon annans del” är ett av de viktigaste designbesluten en organisation gör.
Delivery Engineering är en disciplin
Delivery Engineering handlar om vägen från commit till produktion. Pipelines, byggsystem, artefakt-hantering, release-strategier, feature flagsFeature flagsFeature flags (feature toggles) är brytare i koden som gör att funktionalitet kan slås på och av utan ny deploy — vilket frikopplar deployment från lansering och ger kontroll över timing, målgrupper och risk.Läs mer i ordlistan →, progressive deliveryProgressive deliveryProgressive delivery innebär att förändringar rullas ut stegvis — till exempel via canary releases eller procentbaserad utrullning — mäts i produktion och skalas upp först när signalerna är rätt.Läs mer i ordlistan →. Det är inte en filosofi — det är ett hantverk. Och det är ofta ett eget team som bygger plattformen som låter alla andra team leverera snabbt och säkert.
Tänk på det så här: om DevOps säger ”team X äger sin tjänst hela vägen ut”, så säger Delivery Engineering ”här är spåret som tar dig dit utan att du behöver uppfinna det själv”.
Var överlappar de?
I praktiken: CI/CDCI/CDCI/CD står för continuous integration och continuous delivery/deployment: automatiserade flöden där kod byggs, testas och levereras till produktion i små, täta steg i stället för stora, riskfyllda releaser.Läs mer i ordlistan →. Båda disciplinerna investerar tungt i pipelines, men av olika skäl. Ett DevOps-team bygger pipelines för sin egen tjänst. Ett Delivery Engineering-team bygger pipelines som plattform — så att 50 andra team inte behöver bygga sin egen variant.
Det är där förvirringen kommer ifrån. Verktygen är samma. Syftet är olika.
När behöver man vad?
Liten organisation, ett fåtal team — då räcker DevOps-tankesättet. Varje team äger sin grej från ände till ände och bygger precis så mycket pipeline som de själva behöver.
När ni växer och hamnar med 10+ team som alla löser samma deployment-problem på 10 olika sätt, då börjar Delivery Engineering bli en investering som betalar sig snabbt. Inte för att teamen inte klarar sig själva — utan för att det är slöseri att alla uppfinner samma hjul, och för att en gemensam plattform gör att de tjatigaste delarna av leveransen blir någon annans problem.
Vårt korta svar
DevOps berättar hur ni delar ansvar. Delivery Engineering berättar hur ni delar verktygen. Båda behövs — men inte alltid lika mycket samtidigt.
Om någon påstår att det är samma sak — fråga vad de menar med båda. Ofta menar de bara CI/CD.