Continuous Delivery

Continuous Delivery är programvaruutvecklingsprocessen att få kodändringar till produktion snabbt, säkert och med högre kvalitet.

Vad är Continuous Delivery?

Continuous Delivery (CD) är programvaruutvecklingsprocessen att få kodändringar till produktion snabbt, säkert och med högre kvalitet, vanligtvis med hjälp av verktyg för att automatisera driftsättningarna. Engineering-team gör ändringar i sin programvara i korta cykler, så att den kan testas och släppas oftare. Det här tillvägagångssättet möjliggör inkrementella ändringar med både lägre kostnader och risk. Tillvägagångssättet populariserades först av Jez Humble och David Farley i deras bok, Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation.

Hur fungerar Continuous Delivery?

Här är en genomgång av Continuous Delivery-processen:

  • Continuous Integration (CI): Team integrerar kodändringar i ett delat repository ofta. Automatiserade tester körs på dessa ändringar för att säkerställa att kodbasen förblir funktionell.
  • Automatiserade byggen: När ny kod committas startar en automatiserad byggprocess som kompilerar kod och skapar körbara artefakter.
  • Automatiserad testning: Automatiserade tester (enhetstester, integrationstester osv.) validerar kodens funktionalitet. Om testerna godkänns går koden vidare.
  • Driftsättningspipeline: Kod som har passerat testerna rör sig genom en driftsättningspipeline. Denna pipeline består av stadier som staging, testning och produktion.
  • Automatiserad driftsättning: Om kodändringar passerar alla stadier driftsätts de automatiskt till produktion eller en produktionsliknande miljö.

Varför du behöver både Continuous Delivery och A/B-testning

Continuous Delivery säkerställer effektiv programvarudriftsättning, medan A/B-testning validerar ändringar och säkerställer att de möter användarnas behov. Att integrera bägge möjliggör högkvalitativ programvara driven av användarfeedback och datainsikter.

  1. Kvalitetssäkring

    CD levererar uppdateringar snabbt, medan A/B-testning validerar ändringar med verkliga användardata och säkerställer effektiva driftsättningar som förbättrar användarupplevelsen. Uppdateringar anländer inte bara snabbt utan är också optimerade.
  2. Förbättring

    A/B-testning låter team förfina CD-driftsatta funktioner inkrementellt baserat på användarfeedback, vilket leder till bättre presterande produkter.
  3. Datadrivna beslut

    Att integrera A/B-testning i CD samlar tidiga insikter och vägleder beslut om funktionsprioritering och driftsättning.

Fördelar med Continuous Delivery

Nedan finns de primära fördelarna med en Continuous Delivery-pipeline i molnet.

  1. Snabbhet till marknaden

    Marknadsförhållanden är i ett evigt tillstånd av konstant förändring allteftersom konsumentbeteendet skiftar. Produkter kan plötsligt ta fart eller, lika plötsligt, avta. Samtidigt kan teknologiska framsteg också påverka behovet av att släppa ändringar snabbare till dina slutanvändare. För att svara på oförutsägbara marknads- och teknikförändringar är det snabbare för ingenjörer att släppa programvara med Continuous Delivery.
  2. Lägre risk

    När inkrementella ändringar släpps oftare kan fel upptäckas och korrigeras tidigare i utvecklingsprocessen. Det är också lättare att rulla tillbaka mindre ändringar när det behövs och hjälper till att förhindra oavsiktliga ändringar från att komma in i produktionsmiljön genom versionskontroll och användning av en staging-miljö. Att utnyttja automatiserad testning samt att dela upp tester i mindre enhetstester är andra DevOps-bästa praxis som minskar driftstopp.
  3. Koordination och kommunikation mellan team

    Med Continuous Delivery delar team ansvaret för programvaruleverans. Detta bryter ner siloerna mellan grupper eller avdelningar och tar bort oförutsägbarheten och stressen från programvaruutgivning. Att driftsätta fler frekventa releaser är en process som får teamet att arbeta i en regelbunden, förutsägbar takt.
  4. Snabbare inlärningscykel

    Att lansera nya funktioner snabbare till marknaden innebär mer snabb feedback från dina kunder. Den här utgivningsprocessen låter dig lära dig av dina kunder genom att få fungerande programvara i deras händer tidigare, inkorporera deras feedback och göra justeringar av din produkt för att förbättra den.

Continuous Delivery-exempel

Föreställ dig en e-handelsplattform som vill experimentera med ett nytt checkout-flöde för att förbättra konverteringsgraden. 

  • Ideegenerering: Identifiera behovet av ett nytt checkout-flöde för att förbättra konverteringar.
  • Utveckling: Skapa två checkout-versioner. A (nuvarande flöde) och B (nytt optimerat flöde)
  • CI och driftsättning: Testa båda versionerna i en staging-miljö via Continuous Integration.
  • A/B-testning: Använd feature toggles för att dirigera användare slumpmässigt till version A eller B.
  • Datainsamling: Spåra användarmätvärden (konverteringsgrader, avhopp) i båda versionerna.
  • Analys: Jämför prestationsmätvärden för att fastställa det bättre presterande checkout-flödet.
  • Driftsättning: Om version B utmärker sig, driftsätt den plattformsövergripande via CD.
  • Övervakning: Övervaka och förfina kontinuerligt det nya flödet baserat på användarfeedback och data.

Continuous Delivery & DevOps

Termen ‘DevOps’ är en kombination av ‘development’ och ‘operations’ och betecknar samarbetet mellan de två. DevOps delar gemensamma mål och egenskaper med Continuous Delivery. Bägge levererar små ändringar, förlitar sig på samarbete och koordination mellan team och delar ett gemensamt mål om snabbare time-to-market.

För att förtydliga skillnaden mellan de två: DevOps är metodiken för att hjälpa företag att bygga och släppa programvara. Det är praxisen som betonar samarbete och koordination mellan programvaruutvecklarna och andra avdelningar i företaget. DevOps skapar en miljö där programvara kan utvecklas, testas och släppas snabbt och tillförlitligt.

Du kan tänka på DevOps som den större kraften och filosofin bakom tjänsten, medan Continuous Delivery är processen som levererar den i molnet.

Continuous Delivery vs. Continuous Integration

I traditionell programvaruutveckling sker integrationsprocessen i slutet av ett projekt efter att varje person har avslutat sitt arbete. Denna process kan ta lång tid och vara frustrerande för alla inblandade.

Continuous Integration är en programvaruutvecklingspraxis som flyttar integrationsfasen upp i utvecklingscykeln så att utveckling, testning och integrering av kod sker med större frekvens. Utvecklingsteamet slår ihop kodändringar i ett delat, centralt repository flera gånger om dagen för att kunna släppa en produktversion när som helst. Detta kräver en integrationsprocess som är reproducerbar och automatiserad.

Continuous Delivery vs. Continuous Deployment

I praxisen med Continuous Deployment går alla programvaruändringar som passerar testning automatiskt till produktion. För att skapa en Continuous Deployment-pipeline behöver ditt företag först nå Continuous Delivery.

Continuous Deployment kan betraktas som en utökning av Continuous Integration, med målet att minimera tidsgapet mellan att skriva ny kod och att den nya koden används i produktionskodsbasen.

För att uppnå Continuous Deployment förlitar sig utvecklingsteamet på en rigorös process som automatiserar de olika stegen fram till driftsättning. Efter att varje integration uppfyller utgivningskriterierna uppdateras liveapplikationen med ny kod och en produktionsdriftsättning kan ske.

Agil utveckling och Continuous Delivery

Agil programvaruutveckling håller ett antal värderingar och principer där krav och lösningar utvecklas genom teamsamarbete. Den omfattar adaptiv planering, tidig leverans, kontinuerlig förbättring och flexibelt svar på förändring. I agil finns det ingen fastställd tidsram för varje release, men idén är att de sker ofta: kanske var några veckor eller var några månader, med preferens för det kortare av de två.

I utvecklingen av processer för programvaruleverans föregick agil utveckling Continuous Delivery.

Continuous Delivery är en delmängd av agil där teamet håller sin programvara redo för release hela tiden under utvecklingen. Det handlar mer om att utveckla på ett sådant sätt att programvaran alltid är redo för release – kontinuerligt.

Continuous Delivery och A/B-testning

Experimentering och feature management behöver fungera hand i hand. Experimentering är ett viktigt sätt för ditt företag att validera idéer innan nya produkter, funktioner och upplevelser lanseras för alla besökare. Med utvecklingsteam som använder Continuous Integration och Continuous Delivery-processen kan feature flags som kontrollerar utrullningen av nya upplevelser minska risken med att lansera något oprövat för alla samtidigt.

För att hjälpa till att hålla A/B-testning som en central del av din organisations driftsättningsprocess integrerar Optimizely server-side-experimentering feature flags, rollouts och variabler med experimentering, vilket låter dig kontrollera hela produktutvecklingslivscykeln på ett ställe. Genom att först köra ett A/B-test för en del av trafiken kan ditt team testa och gradvis optimera en ny funktion. När du har den bästa användarupplevelsen kan den rullas ut på ett kontrollerat sätt över hela din kundbas för att minska risken för tekniska problem med utgivningsprocessen.