Modellen för kontinuerlig leverans/distribution

Du har lärt dig om de många nackdelarna med den "episka distributionen" som en modell för programvaruleverans, men att veta vad som inte fungerar bra är bara halva striden. I den här lektionen får du lära dig mer om alternativet till den monolitiska metoden och hur det kan främja ditt mål om förbättrad tillförlitlighet.

Det är också värt att särskilja två relaterade termer som ibland används omväxlande:

• Kontinuerlig leverans: varje ändring som klarar automatiserade tester är redo att distribueras till produktion, men den faktiska lanseringen till produktion styrs av ett manuellt godkännande.
• Kontinuerlig distribution: varje ändring som klarar automatiserade tester släpps automatiskt till produktion, utan manuell grind.

Båda är beroende av samma grund (frekvent integrering, automatiserade tester, repeterbara pipelines). Den här modulen fokuserar på de delade grunderna.

Vad är kontinuerlig leverans?

Kontinuerlig leverans är en metod som gör att varje ändring av din kodbas hålls frisläsbar på ett snabbare, mindre stressigt, mindre riskfyllt och mer reproducerbart sätt. I stället för att göra varje programdistribution eller uppdatering till en episk händelse, förvandlar kontinuerlig leverans det till en snabb, rutinmässig, förutsägbar upplevelse som sker på begäran.

• Distributionsfrekvens: Med en modell för kontinuerlig leverans sker distributioner ofta. Kadens kan vara månadsvis, veckovis, dagligen eller till och med varje timme. Nyckeln är att du distribuerar mindre, mer fokuserade ändringar oftare.

• Utlöses av kodinlämning: I stället för att vänta på ett releasefönster som schemalagts långt i förväg startar leveranspipelinen när koden lämnas in. Koden kan vara programvara, infrastruktur eller till och med saker såsom programvarukonfigurationer. Varje ändring skapas, testas och hålls redo för lansering. Beroende på organisationens kontroller kan uppflyttning till produktion fortfarande ske senare, efter ett godkännande.

• Automatiserad testning: Du kan använda integrerad automatiserad testning inte bara för att testa koden, utan även för att ge snabb feedback om resultatet av dessa tester. Det är den här snabba feedbacken som gör att du snabbt kan iterera och återställa från misslyckade tester.

  När koden har testats kan du testa distributionen från början till slut i en serie stegvisa miljöer såsom test, QA och så vidare. Lanseringen av dina distributioner via dessa miljöer blir en integrerad del av distributionsupplevelsen.

• Historiska loggar: Du vill inte bara ha en historisk logg över distributionsaktiviteter, du vill också kunna stämma av produktionsmiljön när som helst. Du vill veta vilken utplacering som skapade din aktuella produktionsmiljö. Med den här kunskapen kan du spåra sådant som konfigurationer, testresultat och själva koden hela vägen tillbaka till den enskilda pull-begäran som utlöste distributionen.

Distributionsmål

Nu när du vet hur kontinuerlig leverans fungerar bör du överväga målen för kontinuerlig leverans och andra DevOps-metoder som hjälper dig att uppnå när du distribuerar programvarulösningar.

Mål 1: Minska stressen med att distribuera tjänster och samtidigt öka tillförlitligheten för dessa tjänster

Att minska belastningen på programvaru- och infrastrukturdistributioner förbättrar den dagliga upplevelsen för de tekniker som kör dem. Den resulterande ökningen av tillförlitligheten gynnar också slutanvändare som ser färre avbrott och avbrott.

Mål 2: Minska tiden mellan när du vet att en ändring krävs och när ändringen distribueras till produktion

Anta till exempel att du har identifierat ett kodfel som påverkar intäkterna och du vet exakt hur du åtgärdar det. Med mogna DevOps-metoder är vägen från incheckning till produktion kort och förutsägbar. Ändringen skapas, testas automatiskt i relevanta miljöer och förbereds för lansering inom några minuter. När det nödvändiga godkännandet har getts kan det befordras till produktion i stället för att hållas för ett framtida lanseringsfönster.

Mål 3: Minska tiden mellan att ha en idé och att leverera användbar programvara

Det här målet liknar det tidigare, men det fokuserar på innovation snarare än korrigeringar. Hur lång tid tar det att agera på en ny idé? Med den här distributionsmodellen kan du integrera ett nytt koncept i ett produktionssystem med förtroende för att tillägget inte bryter eller hindrar det aktuella systemet. Med det förtroendet kan du snabbt leverera nya funktioner.

Distributionsresultat

Målen som diskuteras i den här lektionen är inte bara teoretiska ambitioner, de är mätbara. Sedan 2014 har Teamet för DevOps Research and Assessment (DORA) publicerat årlig State of DevOps-forskning om prestanda för programvaruleverans. Under de senaste åren har detta arbete publicerats som Accelerate State of DevOps Report. Den aktuella DORA-modellen spårar fem leveransmått:

• Distributionsfrekvens
• Ändra ledtid
• Ändra felprocent
• Återställningstid för misslyckad implementation
• Omarbetningshastighet för distribution

År efter år visar forskningen att högpresterande team levererar ändringar oftare, går från incheckning till produktion snabbare, återställer från misslyckade distributioner tidigare och ägnar mindre tid åt att åtgärda distributionsrelaterade problem. De senaste forsknings- och måttdefinitionerna finns i DORA:s mått för programvaruleverans.

Dessa resultat validerar tanken att distributionsmetoder spelar roll.