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.
Vad är kontinuerlig leverans?
Kontinuerlig leverans är en metod som du kan använda för att göra programvaruändringar tillgängliga för användning på ett snabbare, mindre stressigt, mindre riskabelt och mer reproducerbart sätt. I stället för att göra varje programvarudistribution eller uppdatering till en episk händelse strävar kontinuerlig leverans efter att göra den 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. Detta kan ofta vara månadsvis, veckovis, dagligen, till och med varje timme. Nyckeln är att du distribuerar mindre, mer fokuserade ändringar oftare.
Initierad av kodincheckning: I stället för att schemaläggas långt i förväg sker distributioner när kod checkas in. Koden kan vara programvara, infrastruktur eller till och med saker såsom programvarukonfigurationer.
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 distributionens slutpunkt för att sluta i en serie mellanlagrade miljöer som test, QA och så vidare. Lanseringen av dina distributioner via dessa miljöer blir en integrerad del av distributionsupplevelsen.
Historiska poster: Du vill inte bara ha en historisk post med distributionsaktiviteter, du vill också kunna stämma av produktionsmiljön vid en viss tidpunkt. Du vill veta vilken distribution 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 tänka på vilka mål du kan uppnå genom att använda DevOps-metoder som denna för att distribuera programvarulösningar.
Mål 1: Minska stressen med att distribuera tjänster och samtidigt öka tillförlitligheten för dessa tjänster
Detta är en win-win; Du ökar inte bara arbetsnöjdheten genom att minska stressen med programvaru- och infrastrukturdistributioner, du ökar också både nöjdheten och slutanvändarnas tillfredsställelse genom att göra dina system mer tillförlitliga. Med tanke på denna positiva inverkan på kundupplevelsen är detta tekniskt sett en win-win-win.
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. Du vet exakt vad problemet är och hur du ska koda korrigeringen. Hur lång tid tar det för dig att föra koden till produktion? Hur många strängar behöver du hämta? Hur testar du? Med DevOps-metoder kan du checka in kod, gå på lunch och få en avisering om att problemet har lösts innan du är tillbaka vid skrivbordet.
Mål 3: Minska tiden mellan att ha en idé och leverera användbar programvara
Detta liknar det tidigare målet, men i stället för att genomföra ändringar talar vi om ren innovation. Hur lång tid tar det för dig att agera utefter innovation? Med den här distributionsmodellen kan du integrera ett nytt koncept i ett produktionssystem och ha förtroende för att den nya innovationen inte på något sätt kommer att hindra det nuvarande systemet. Med detta förtroende kan du snabbt leverera den nya funktionen.
Distributionsresultat
Målen som diskuteras i den här lektionen är inte bara teoretiska ambitioner, de kan uppnås. Här följer statistik från 2019 års Accelerate State of DevOps Report från DevOps Research and Assessment (DORA) och Google Cloud DevOps & SRE. I den har de upptäckt att "högpresterande" DevOps-företag:
- Ha 208 gånger så många distributioner.
- Är 106 gånger snabbare från incheckning till distribution.
- Ha en 7x lägre ändringsfelfrekvens.
- Ha en 2 604 gånger snabbare incidentåterställningstid.
Allt detta leder till ökade intäkter och snabbare tid till marknaden.
De här siffrorna validerar tanken om att distributionsmetoder spelar roll.