Zero-day delivery: nästa steg för DevOps?

Känslan av att få en bra idé är svårslagen, men för många företag är det som kommer härnäst den svåra delen. Hur skulle det kännas att se din idé bli verklighet samma dag som du kom på den?

Enligt mig är detta nästa gräns för DevOps, och det kallas zero-day delivery.

Zero-day delivery gränsar till Continuous Delivery

Continuous Delivery producerar mjukvara i korta cykler, vilket ökar hastigheten och frekvensen samtidigt som antalet fel minskar. Continuous Delivery innebär att du kan driftsätta din kod och göra den tillgänglig för användning, men det sista steget – att kunderna faktiskt upplever förändringarna i din produkt – är en manuell process. När även denna sista fas är automatiserad kallas det continuous deployment.

Continuous Delivery är ett viktigt steg bort från traditionella metoder som bygger på organisatoriska silor. Men de flesta ledande användarna av Continuous Delivery utnyttjar inte dess fulla potential. De använder fortfarande traditionella metoder när de går från affärsidé till design, från design till utveckling eller från en färdig funktion till en lanserad produkt.

När organisationen står i vägen för sig själv

Continuous Delivery kräver en viss typ av organisationskultur och att vissa arbetssätt finns på plats för att kunna leverera kontinuerligt. Trots det kan organisatoriska silor innebära att leveransen inte kan starta direkt, utan först måste vänta på flera steg.

Företag som har kommit långt på sin DevOps-resa – en resa som ofta innebär organisatoriska förändringar – har möjlighet att påskynda hela processen, från idé till release av din uppdatering.

Men i stället för att använda den här potentialen startar många i maklig takt genom att bara använda Continuous Delivery halvvägs på resan från idé till produkt: antingen under utvecklingen eller i produktionsmiljön, men inte hela vägen.

Continuous Delivery behöver släppas fritt för att nå sin fulla potential. Den potentialen kallar jag zero-day delivery.

Zero-day delivery drivs av DevOps ur ett helhetsperspektiv

Föreställ dig detta: När du startar ett mjukvaruprojekt – eller ännu hellre när du beslutar att starta ett eller bara överväger det – skulle det kunna köras i produktionsmiljön redan samma dag.

Till skillnad från idén du nyss hade är detta inte bara fantasi. Det är en pipeline för Continuous Delivery – men varför inte även continuous deployment? – med verktyg och projektmallar som till exempel omfattar:

• kopplingar till kravhantering och versionshantering

• ett designsystem och dess UI-komponenter

• automatiserade testmallar och infrastrukturer

• releaseautomatisering.

Du kan skicka din idé genom pipelinen, och på andra sidan kommer mjukvara ut. Bara 10–20 % av koden är själva produkten. Resten består av delade komponenter, mallar och arbetssätt som stödjer DevOps när det är som bäst.

Projektmallarna är startpunkten för en ny idé. De är kopplade till verktygskedjan, så när du klonar den första delen av koden – även om den bara utgör 10–20 % av den ursprungliga mallen – har du redan en nyckel till produktionsmiljön i mallen.

Fördelarna med zero-day delivery är enorma

1. Zero-day delivery ger dig omedelbar återkoppling på din idé, vilket är ovärderligt. Du behöver inte längre vänta i veckor för att få veta hur din nya funktion fungerar eller om användarna gillar den. Inga fler demos: du ser din idé direkt i produktionsmiljön.

2. Zero-day delivery förändrar hur du ser på de första stegen i en ny idé, en ny funktion eller en förändring i din mjukvara. Du börjar inte med att vänta – du börjar med att leverera. Och ur teamets perspektiv är det ganska enkelt. Du har redan etablerat pipelinen, och arbetet har gjorts på ett skalbart sätt. Du kan också föra det vidare till andra team i organisationen.

3. Zero-day delivery förkortar din time to market med veckor. Det avgörande är inte när du får information om att något är fel eller att något händer. Det avgörande är när verksamheten reagerar på det.

4. Zero-day delivery uppmuntrar också till att misslyckas snabbt. Du kan omedelbart avslöja dåliga idéer för vad de är – något som kanske inte märks när du tar fram konceptet.

Leverera inte det som är klart – leverera det som fungerar

Zero-day delivery är skiftet från att leverera det som är klart till att leverera det som fungerar.

Det innebär att ni satsar på minsta möjliga leveranser, vilket i praktiken betyder att ni gör mindre misstag. Det möjliggör också canary testing: att släppa nya funktioner till endast utvalda kunder och använda den informationen för att färdigställa eller vidareutveckla funktionen.

Och delivery är inte samma sak som release

Bara för att du lägger något i produktion eller i en produktionsliknande miljö betyder det inte att du måste publicera det för dina kunder samma dag. Slutanvändaren behöver inte se det förrän du slår på funktionen.

Det viktiga paradigmskiftet är att zero-day delivery inte handlar om att endast släppa färdiga funktioner, utan om att släppa mjukvara som fungerar. Det löser många problem med integration och testautomatisering jämfört med att bara slå ihop och släppa funktioner som anses vara ”klara”. Dessutom kan du testa en ny funktion med pilotkunder i produktion innan du publicerar den för alla.

Zero-day delivery är inget språng ut i det okända. Det är DevOps

Att delivery inte är samma sak som release bör minska mycket av oron. Men poängen jag vill betona är att företag inte har något att förlora. Tekniken finns för att göra zero-day delivery till verklighet, och vi har sett det fungera i praktiken.

Vi lever redan i en värld där delivery-cyklerna är så snabba att de sker samma dag som en idé föds. Det handlar inte om vilka konkurrensfördelar du skapar genom att följa dessa arbetssätt, utan om alternativkostnaden om du inte gör det.

Du bygger inte längre en klocka under ett år. Du skapar ett kontinuerligt växande värde för dina kunder och reagerar på en komplex omvärld genom att skapa förutsättningar i verksamheten där nya idéer kan förverkligas snabbt.