Den kontinuerlige udrulningsmodel til levering

Du har lært om de mange ulemper ved "epic deployment" som softwareleveringsmodel, men at vide, hvad der ikke fungerer godt, er kun halvdelen af kampen. I denne enhed lærer du om alternativet til den monolitiske metode, og hvordan den kan fremme dit mål om forbedret pålidelighed.

Det er også værd at skelne mellem to beslægtede begreber, som nogle gange bruges i flæng:

• Kontinuerlig levering: hver ændring, der består automatiserede tests, er klar til at blive udrullet til produktion, men selve udgivelsen til produktion er begrænset af en manuel godkendelse.
• Kontinuerlig implementering: hver ændring, der består automatiserede tests, frigives automatisk til produktion uden manuel gate.

Begge afhænger af de samme fundamenter (hyppig integration, automatiserede tests, gentagelige pipelines). Dette modul fokuserer på disse fælles fundamenter.

Hvad er kontinuerlig levering?

Kontinuerlig levering er en metode, hvor enhver ændring i din kodebase holdes tilgængelig på en hurtigere, mindre stressende, mindre risikabel og mere reproducerbar måde. I stedet for at gøre hver softwareimplementering eller opdatering til en episk begivenhed, gør kontinuerlig levering det til en hurtig, rutinemæssig og forudsigelig oplevelse, der sker på efterspørgslen.

• udrulningshyppighed: Med en kontinuerlig leveringsmodel sker udrulninger ofte. Rytmen kan være månedlig, ugentlig, daglig eller endda timelønnet. Det vigtigste er, at du installerer mindre, mere fokuserede ændringer, oftere.

• Udløst af kodecommit: I stedet for at vente på et release-vindue planlagt langt i forvejen, starter leveringspipelinen, når koden er committet. Denne kode kan være software, infrastruktur eller endda ting som softwarekonfigurationer. Hver ændring bygges, testes og holdes klar til udgivelse. Afhængigt af din organisations kontrol kan forfremmelse til produktion stadig ske senere, efter godkendelse.

• Automatiseret test: Du kan ikke kun bruge integreret automatiseret test til at teste koden, men også give hurtig feedback om resultaterne af disse test. Det er denne hurtige feedback, der giver dig mulighed for hurtigt at gentage og gendanne efter mislykkede test.

  Når din kode er blevet testet, kan du teste udrulningen fra ende til anden i en række faselagrede miljøer, f.eks. test, kvalitetskontrol osv. Hvis du ruller dine udrulninger gennem disse miljøer, bliver det en integreret del af udrulningsoplevelsen.

• historiske poster: Du vil ikke kun have en oversigt over udrulningsaktiviteter, men du vil også kunne afstemme dit produktionsmiljø når som helst. Du vil gerne vide, hvilken udrulning der har oprettet dit aktuelle produktionsmiljø. Med denne viden kan du spore f.eks. konfigurationer, testresultater og selve koden helt tilbage til den individuelle pullanmodning, der udløste udrulningen.

Udrulningsmål

Nu hvor du ved, hvordan kontinuerlig levering fungerer, kan du overveje de mål, som kontinuerlig levering og andre DevOps-praksisser hjælper dig med at opnå, når du implementerer softwareløsninger.

Mål 1: Reducer stressen i forbindelse med udrulning af tjenester, samtidig med at pålideligheden af disse tjenester øges

At reducere stresset ved software- og infrastrukturimplementering forbedrer den daglige oplevelse for de ingeniører, der driver dem. Den resulterende stigning i pålidelighed gavner også slutbrugerne, som oplever færre nedbrud og forstyrrelser.

Mål 2: Reducer tiden mellem, hvornår du ved, at en ændring er påkrævet, og hvornår ændringen udrulles til produktion

For eksempel, hvis du har identificeret en kodefejl, der påvirker omsætningen, og du ved præcis, hvordan du skal rette den. Med modne DevOps-praksisser er vejen fra commit til produktion kort og forudsigelig. Ændringen bygges, testes automatisk på tværs af de relevante miljøer og forberedes til udgivelse inden for få minutter. Når den nødvendige godkendelse er givet, kan den forfremmes til produktion i stedet for at blive holdt tilbage til et fremtidigt udgivelsesvindue.

Mål 3: Reducer tiden mellem at have en idé og levering af brugbar software

Dette mål ligner det forrige, men det fokuserer på innovation frem for løsninger. Hvor lang tid tager det dig at handle på en ny idé? Med denne implementeringsmodel kan du integrere et nyt koncept i et produktionssystem med sikkerhed for, at tilføjelsen ikke vil ødelægge eller hindre det nuværende system. Den selvtillid gør det muligt for dig hurtigt at levere nye funktioner.

Installationsresultater

De mål, der diskuteres i denne enhed, er ikke blot teoretiske ambitioner, de kan måles. Siden 2014 har DevOps Research and Assessment (DORA)-teamet udgivet årligt State of DevOps-forskning om softwareleveringspræstationer. I de senere år er dette arbejde blevet udgivet som Accelerate State of DevOps Report. Den nuværende DORA-model følger fem leveringsmålinger:

• Udrulningsfrekvens
• Ændringsleveringstid
• Ændringsfejlrate
• Mislykket udsendelsesgenopretning
• Omarbejdsrate for udrulning

År efter år viser forskningen, at bedre præsterende teams leverer ændringer oftere, går hurtigere fra commit til produktion, kommer sig hurtigere efter fejlslagne udrulninger og bruger mindre tid på at rette udrulningsrelaterede problemer. For den nyeste forskning og definitioner af måleparametre, se DORAs softwareleveringsmålinger.

Disse resultater bekræfter idéen om, at implementeringspraksis betyder noget.