Kontinuerlig levering

Hva er kontinuerlig levering?

Kontinuerlig levering (Continuous Delivery, CD) er en programvareutviklingsprosess som går ut på å få kodeendringer ut i produksjon raskt, sikkert og med høyere kvalitet, vanligvis ved hjelp av verktøy for å automatisere utplasseringene. Ingeniørteam gjør endringer i programvaren i korte sykluser, slik at den kan testes og slippes oftere. Denne tilnærmingen muliggjør inkrementelle endringer med både lavere kostnader og risiko. Tilnærmingen ble først popularisert av Jez Humble og David Farley i boken Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.

Hvordan fungerer kontinuerlig levering?

Her er en oversikt over prosessen for kontinuerlig levering:

• Kontinuerlig integrasjon (CI): Teamene integrerer kodeendringer i et felles repository med jevne mellomrom. Automatiserte tester kjøres på disse endringene for å sikre at kodebasen forblir funksjonell.
• Automatiserte builds: Hver gang ny kode legges inn, starter en automatisert byggeprosess som kompilerer koden og lager kjørbare artefakter.
• Automatiserte tester: Automatiserte tester (enhetstester, integrasjonstester osv.) validerer kodens funksjonalitet. Hvis testene består, går koden videre.
• Pipeline for distribusjon: Kode som har bestått testene, flyttes gjennom en distribusjonspipeline. Denne pipelinen består av stadier som staging, test og produksjon.
• Automatisert distribusjon: Hvis kodeendringene består alle stadier, blir de automatisk distribuert til produksjon eller et produksjonslignende miljø.

Hvorfor du trenger både kontinuerlig levering og A/B-testing

Kontinuerlig levering sikrer effektiv distribusjon av programvare, mens A/B-testing validerer endringer og sikrer at de oppfyller brukernes behov. Ved å integrere begge deler får du programvare av høy kvalitet som er drevet av tilbakemeldinger fra brukerne og datainnsikt.

1. Kvalitetssikring
   

   CD leverer oppdateringer raskt, mens A/B-testing validerer endringer med reelle brukerdata, noe som sikrer effektive distribusjoner som forbedrer brukeropplevelsen. Oppdateringer kommer ikke bare raskt, men er også optimalisert.

2. Forbedring
   

   Med A/B-testing kan teamene forbedre CD-distribuerte funksjoner trinnvis basert på tilbakemeldinger fra brukerne, noe som fører til produkter med bedre ytelse.

3. Datadrevne beslutninger
   

   Ved å integrere A/B-testing i CD får du tidlig innsikt som kan brukes som grunnlag for prioritering av funksjoner og beslutninger om distribusjon.

Fordeler med kontinuerlig levering

Nedenfor er de viktigste fordelene med en pipeline for kontinuerlig levering i skyen.

1. Hastighet til markedet
   

   Markedsforholdene er i stadig endring i takt med at forbrukeratferden endrer seg. Produkter kan plutselig slå an, eller like plutselig gå tilbake. Samtidig kan teknologiske fremskritt også påvirke behovet for å lansere endringer raskere til sluttbrukerne. For å kunne reagere på uforutsigbare markeds- og teknologiendringer er det raskere for ingeniører å lansere programvare ved hjelp av kontinuerlig levering.

2. Lavere risiko
   

   Når inkrementelle endringer lanseres hyppigere, kan feil oppdages og korrigeres tidligere i utviklingsprosessen. Det er også enklere å rulle tilbake mindre endringer når det er nødvendig, og det bidrar til å forhindre at utilsiktede endringer kommer inn i produksjonsmiljøet ved hjelp av versjonskontroll og bruk av et staging-miljø. Utnyttelse av automatiserte tester samt oppdeling av tester i mindre enhetstester er andre DevOps-beste praksiser som reduserer nedetid.

3. Koordinering og kommunikasjon mellom teamene
   

   Med kontinuerlig levering deler teamene ansvaret for programvarelevering. Dette bryter ned siloene mellom grupper eller avdelinger, og fjerner uforutsigbarheten og stresset knyttet til programvareleveranser. Hyppigere utgivelser er en prosess som får teamet til å jobbe i et regelmessig og forutsigbart tempo.

4. Raskere læringssyklus
   

   Når du lanserer nye funksjoner raskere på markedet, får du raskere tilbakemeldinger fra kundene dine. Denne utgivelsesprosessen gjør at du kan lære av kundene dine ved å gi dem fungerende programvare raskere, innlemme tilbakemeldingene deres og gjøre justeringer i produktet for å forbedre det.

Eksempel på kontinuerlig levering

Tenk deg en e-handelsplattform som ønsker å eksperimentere med en ny kasseflyt for å forbedre konverteringsraten.

• Idégenerering: Identifiser behovet for en ny kasseflyt for å forbedre konverteringsraten.
• Utvikling: Opprett to versjoner av kassen. A (nåværende flyt) og B (ny, optimalisert flyt)
• CI og distribusjon: Test begge versjonene i et staging-miljø via Continuous Integration.
• A/B-testing: Bruk funksjonsknapper for å lede brukerne tilfeldig til versjon A eller B.
• Datainnsamling: Spor brukermålinger (konverteringsfrekvenser, frafall) i begge versjonene.
• Analyse: Sammenlign ytelsesberegninger for å finne ut hvilken kassestrøm som gir best resultater.
• Distribusjon: Hvis versjon B utmerker seg, distribuerer du den på hele plattformen via CD.
• Overvåking: Overvåk og finpuss den nye flyten kontinuerlig basert på tilbakemeldinger og data fra brukerne.

Kontinuerlig levering og DevOps

DevOps er en kombinasjon av "development" og "operations", og betegner samarbeidet mellom disse to. DevOps har felles mål og trekk med kontinuerlig levering. Begge leverer små endringer, er avhengige av samarbeid og koordinering mellom teamene og har et felles mål om å komme raskere ut på markedet.

For å tydeliggjøre forskjellen mellom de to, er DevOps en metodikk som hjelper bedrifter med å bygge og lansere programvare. Det er en praksis som legger vekt på samarbeid og koordinering mellom programvareutviklere og andre avdelinger i selskapet. DevOps skaper et miljø der programvare kan utvikles, testes og lanseres raskt og pålitelig.

Du kan tenke på DevOps som den større kraften og filosofien bak tjenesten, mens kontinuerlig levering er prosessen som leverer den i skyen.

Kontinuerlig levering vs. kontinuerlig integrasjon

I tradisjonell programvareutvikling skjer integrasjonsprosessen på slutten av et prosjekt, etter at hver enkelt person er ferdig med sitt arbeid. Denne prosessen kan ta lang tid og være frustrerende for alle involverte.

Kontinuerlig integrasjon er en praksis for programvareutvikling som flytter integrasjonsfasen opp i utviklingssyklusen, slik at utvikling, test og integrering av kode skjer med større hyppighet. Utviklingsteamet fusjonerer kodeendringer inn i et felles, sentralt repository flere ganger om dagen for å kunne lansere en produktversjon når som helst. Dette krever en integrasjonsprosess som er reproduserbar og automatisert.

Kontinuerlig levering vs. kontinuerlig distribusjon

Kontinuerlig distribusjon innebærer at alle programvareendringer som består testene, automatisk går til produksjon. For å opprette en pipeline for kontinuerlig distribusjon må bedriften først gå over til kontinuerlig levering.

Kontinuerlig distribusjon kan betraktes som en forlengelse av kontinuerlig integrasjon, med et mål om å minimere tidsforløpet mellom det å skrive ny kode og det at den nye koden tas i bruk i produksjonskodebasen.

For å oppnå kontinuerlig distribusjon er utviklingsteamet avhengig av en streng prosess som automatiserer de ulike trinnene som leder frem til distribusjon. Etter at hver integrasjon oppfyller utgivelseskriteriene, oppdateres live-applikasjonen med ny kode, og en produksjonsdistribusjon kan finne sted.

Smidig utvikling og kontinuerlig levering

Smidig programvareutvikling bygger på et sett med verdier og prinsipper som innebærer at krav og løsninger utvikles gjennom teamsamarbeid. Det omfatter adaptiv planlegging, tidlig levering, kontinuerlig forbedring og fleksibel respons på endringer. I smidig programvareutvikling er det ingen fast tidsramme for hver utgivelse, men tanken er at de skal skje ofte: kanskje med noen ukers mellomrom eller med noen måneders mellomrom, med en preferanse for den korteste av de to.

I utviklingen av prosesser for programvarelevering gikk smidig utvikling forut for kontinuerlig levering.

Kontinuerlig levering er en delmengde av smidig utvikling der teamet holder programvaren klar for lansering til enhver tid under utviklingen. Det handler mer om å utvikle på en slik måte at programvaren alltid er klar for lansering - kontinuerlig.

Kontinuerlig levering og A/B-testing

Eksperimentering og feature management må gå hånd i hånd. Eksperimentering er en viktig måte for bedriften å validere ideer på før nye produkter, funksjoner og opplevelser lanseres for alle besøkende. Med utviklingsteam som bruker kontinuerlig integrasjon og kontinuerlige leveranseprosesser, kan funksjonsflagg som styrer utrullingen av nye opplevelser, redusere risikoen for å lansere noe uprøvd til alle på samme tid.

For å bidra til at A/B-testing forblir en viktig del av organisasjonens distribusjonsprosess, integrerer Optimizely serversideeksperimentering funksjonsflagg, utrullinger og variabler med eksperimentering, slik at du kan kontrollere hele livssyklusen for produktutvikling på ett og samme sted. Ved først å kjøre en A/B-test på en del av trafikken, kan teamet ditt teste og gradvis optimalisere en ny funksjon. Når du har den beste brukeropplevelsen, kan den rulles ut på en kontrollert måte på tvers av hele kundebasen for å redusere risikoen for tekniske problemer i lanseringsprosessen.