Hva er Continuous Delivery?
Continuous Delivery (CD) er programvareutviklingsprosessen med å få kodeendringer inn i produksjon raskt, trygt og med høyere kvalitet, vanligvis ved hjelp av verktøy for å automatisere deployments. Engineering-team gjør endringer i programvaren sin i korte sykluser, slik at den kan testes og slippes hyppigere. 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 deres, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.
Hvordan fungerer Continuous Delivery?
Her er en oversikt over Continuous Delivery-prosessen:
- Continuous Integration (CI): Team integrerer kodeendringer i et delt repository hyppig. Automatiserte tester kjøres på disse endringene for å sikre at kodebasen forblir funksjonell.
- Automatiserte bygg: Når ny kode er committet, starter en automatisert byggprosess som kompilerer kode og oppretter kjørbare artefakter.
- Automatisert testing: Automatiserte tester (enhetstester, integrasjonstester osv.) validerer funksjonaliteten til koden. Hvis testene passerer, går koden videre.
- Deployment-pipeline: Kode som har bestått testene beveger seg gjennom en deployment-pipeline. Denne pipelinen består av stadier som staging, testing og produksjon.
- Automatisert deployment: Hvis kodeendringer passerer alle stadier, blir de automatisk deployet til produksjon eller et produksjonslignende miljø.
Hvorfor du trenger både Continuous Delivery og A/B-testing
Continuous Delivery sikrer effektiv programvarelevering, mens A/B-testing validerer endringer og sikrer at de møter brukernes behov. Å integrere begge muliggjør høykvalitets programvare drevet av brukerfeedback og datainnsikt.
-
Kvalitetssikring
CD leverer oppdateringer raskt, mens A/B-testing validerer endringer med ekte brukerdata og sikrer effektive deployments som forbedrer brukeropplevelsen. Oppdateringer ankommer ikke bare raskt, men er også optimalisert. -
Forbedring
A/B-testing lar team forbedre CD-deployede funksjoner inkrementelt basert på brukerfeedback, noe som fører til bedre ytende produkter. -
Datadrevne beslutninger
Å integrere A/B-testing i CD samler tidlig innsikt og veileder beslutninger om feature-prioritering og deployment.
Fordeler med Continuous Delivery
Nedenfor er de primære fordelene med en Continuous Delivery-pipeline i skyen.
-
Raskere time-to-market
Markedsforhold er i en evig tilstand av konstant endring etter hvert som forbrukeratferden skifter. Produkter kan plutselig slå an eller, like plutselig, avta. Samtidig kan teknologiske fremskritt også påvirke behovet for å frigjøre endringer raskere til sluttbrukerne. For å svare på uforutsigbare markeds- og teknologiendringer er det raskere for engineers å frigjøre programvare ved hjelp av Continuous Delivery. -
Lavere risiko
Når inkrementelle endringer frigis hyppigere, kan feil oppdages og korrigeres tidligere i utviklingsprosessen. Det er også enklere å rulle tilbake mindre endringer ved behov og bidrar til å forhindre utilsiktede endringer i produksjonsmiljøet gjennom versjonskontroll og bruk av et staging-miljø. Bruk av automatiserte tester samt oppdeling av tester i mindre enhetstester er andre DevOps-beste praksiser som reduserer nedetid. -
Koordinasjon og kommunikasjon mellom team
Med Continuous Delivery deler team ansvaret for programvarelevering. Dette bryter ned siloene mellom grupper eller avdelinger, og fjerner uforutsigbarheten og stresset ved programvareutgivelse. Å deploye hyppigere utgivelser er en prosess som får teamet til å jobbe i en jevn, forutsigbar rytme. -
Raskere læringssyklus
Å frigjøre nye funksjoner raskere til markedet betyr mer rettidig tilbakemelding fra kundene dine. Denne utgivelsesprosessen lar deg lære av kundene dine ved å levere fungerende programvare til dem tidligere, innlemme tilbakemeldingene deres og gjøre justeringer i produktet for å forbedre det.
Eksempel på Continuous Delivery
Tenk deg en e-handelsplattform som vil eksperimentere med et nytt checkout-forløp for å forbedre konverteringsraten.
- Ideegenerering: Identifisere behovet for et nytt checkout-forløp for å forbedre konverteringer.
- Utvikling: Opprette to checkout-versjoner. A (nåværende forløp) og B (nytt optimalisert forløp)
- CI og deployment: Teste begge versjonene i et staging-miljø via Continuous Integration.
- A/B-testing: Bruke feature toggles til å dirigere brukere tilfeldig til versjon A eller B.
- Datainnsamling: Spore brukermetrikker (konverteringsrater, avbrudd) i begge versjonene.
- Analyse: Sammenligne ytelsesmetrikker for å bestemme det bedre ytende checkout-forløpet.
- Deployment: Hvis versjon B utmerker seg, deploy den plattformbredt via CD.
- Overvåking: Overvåke og forbedre det nye forløpet kontinuerlig basert på brukerfeedback og data.
Continuous Delivery & DevOps
Begrepet ‘DevOps’ er en kombinasjon av ‘development’ og ‘operations’ og betegner samarbeidet mellom de to. DevOps deler felles mål og egenskaper med Continuous Delivery. Begge leverer små endringer, stoler på samarbeid og koordinasjon mellom team og deler et felles mål om raskere time-to-market.
For å tydeliggjøre forskjellen mellom de to: DevOps er metodikken for å hjelpe selskaper med å bygge og frigjøre programvare. Det er praksisen som vektlegger samarbeid og koordinasjon mellom programvareutviklerne og andre avdelinger i selskapet. DevOps skaper et miljø der programvare kan utvikles, testes og frigis raskt og pålitelig.
Du kan tenke på DevOps som den større kraften og filosofien bak tjenesten, mens Continuous Delivery er prosessen som leverer den i skyen.
Continuous Delivery vs. Continuous Integration
I tradisjonell programvareutvikling skjer integrasjonsprosessen på slutten av et prosjekt etter at hver person har fullført arbeidet sitt. Denne prosessen kan ta lang tid og være frustrerende for alle involverte.
Continuous Integration er en programvareutviklingspraksis som flytter integrasjonsfasen frem i utviklingssyklusen, slik at utvikling, testing og integrering av kode skjer med større hyppighet. Utviklingsteamet fletter kodeendringer inn i et delt, sentralt repository flere ganger om dagen for å frigjøre en produktversjon når som helst. Dette krever en integrasjonsprosess som er reproduserbar og automatisert.
Continuous Delivery vs. Continuous Deployment
I praksisen med Continuous Deployment går alle programvareendringer som passerer testing automatisk til produksjon. For å opprette en Continuous Deployment-pipeline må selskapet ditt først nå Continuous Delivery.
Continuous Deployment kan betraktes som en utvidelse av Continuous Integration, med mål om å minimere tidsgapet mellom skriving av ny kode og at den nye koden brukes i produksjonskodenbasen.
For å oppnå Continuous Deployment stoler utviklingsteamet på en grundig prosess som automatiserer de ulike trinnene frem til deployment. Etter at hver integrasjon møter utgivelseskriteria, oppdateres den live-applikasjonen med ny kode og et produksjons-deployment kan skje.
Smidig utvikling og Continuous Delivery
Smidig programvareutvikling har et sett med verdier og prinsipper der krav og løsninger utvikler seg gjennom teamsamarbeid. Den omfatter adaptiv planlegging, tidlig levering, kontinuerlig forbedring og fleksibel respons på endring. I smidig utvikling er det ingen fast tidsramme for hvert release, men ideen er at de skjer hyppig: kanskje hvert par uker eller hvert par måneder, med preferanse for det korteste av de to.
I utviklingen av prosesser for programvarelevering gikk smidig utvikling forut for Continuous Delivery.
Continuous Delivery er en undergruppe av smidig utvikling der teamet holder programvaren klar for utgivelse til enhver tid under utviklingen. Det handler mer om å utvikle på en måte som gjør at programvaren alltid er klar for utgivelse – kontinuerlig.
Continuous Delivery og A/B-testing
Eksperimentering og feature management må fungere hånd i hånd. Eksperimentering er en viktig måte for bedriften din å validere ideer på før nye produkter, funksjoner og opplevelser lanseres for alle besøkende. Med utviklingsteam som bruker Continuous Integration og Continuous Delivery-prosessen, kan feature flags som kontrollerer utrullingen av nye opplevelser redusere risikoen ved å lansere noe ubeprøvd for alle samtidig.
For å hjelpe med å holde A/B-testing som en sentral del av organisasjonens deployment-prosess, integrerer Optimizely server-side-eksperimentering feature flags, rollouts og variabler med eksperimentering, slik at du kan styre hele produktutviklingslivssyklusen på ett sted. Ved å først kjøre en A/B-test for 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 til hele kundebasen din for å redusere risikoen for tekniske problemer med utgivelsesprosessen.
