Sammanfattning

  • 3 minuter

I den här modulen definierade du ett distributionsmönster som ett automatiserat sätt att smidigt distribuera nya programfunktioner till dina användare. Ett bra distributionsmönster kan hjälpa dig att minimera stilleståndstiden. Det kan också göra det möjligt för dig att distribuera nya funktioner progressivt till dina användare.

Du kan välja mellan flera distributionsmönster. Vilket distributionsmönster du väljer beror på orsaken till distributionen och dina resurser. Har du kanarietestare på plats? Kommer du att använda en mörk uppskjutning och välja testare som inte vet att de är testare? Om du har en betrodd uppsättning testare som gradvis ökar från en liten uppsättning till en större uppsättning kan du välja en distribution med progressiv exponering. Om du vill veta om en version presterar bättre än en annan version kan du välja A/B-testning.

Tailspin-teamet valde att implementera det blågröna distributionsmönstret med hjälp av distributionsfack i Azure App Service. Distributionsfack är liveappar som har egna värdnamn. Teamet kan växla två distributionsplatser. Genom att byta kan de höja upp ändringar i produktionen direkt. Även om teamet inte är redo att släppa sin webbplats till allmänheten har de bevisat att de kan få nya funktioner till sina användare utan att orsaka avbrott.

Som en bonus har du i den här modulen också lärt dig hur du rullar vidare en oavsiktlig ändring genom att återställa en Git-incheckning och sedan push-överföra den återställda ändringen via pipelinen.

Hur går det för teamet?

I modulen Utvärdera din befintliga programutvecklingsprocess gjorde Mara en värdeströmsmappningsövning. Övningen hjälpte teamet att analysera den aktuella processen för lanseringscykeln.

Kom ihåg att aktivitetsförhållandet, eller effektiviteten, är processtid dividerat med total ledtid:

$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$

Tailspin-webbteamet använde ursprungligen det här måttet för att fastställa att de var 23 procent effektiva.

Teamet minskade först vissa ineffektiviteter när de implementerade kontinuerlig integrering (CI). Genom att tillämpa kontinuerlig leverans (CD) har de nu minskat ineffektiviteten ytterligare.

I tidigare utbildningsvägar minskade teamet:

  • Den tid det tar att konfigurera källkontroll för nya funktioner. Den tid som krävdes gick från tre dagar till noll dagar.

    Teamet uppnådde den här förbättringen genom att gå från centraliserad källkontroll till Git, en form av distribuerad källkontroll. Genom att använda distribuerad källkontroll behöver de inte vänta på att filer ska låsas upp.

  • Den tid det tar att leverera kod till Amita, testaren. Den tid som krävdes gick från två dagar till noll dagar.

    Teamet uppnådde den här förbättringen genom att flytta sin byggprocess till Azure Pipelines. Azure Pipelines meddelar automatiskt Amita när en version är tillgänglig. Utvecklare behöver inte längre uppdatera Amitas kalkylblad för att meddela henne.

  • Den tid det tar för Amita att testa nya funktioner. Den tid som krävdes gick från tre dagar till en dag.

    Teamet uppnådde den här förbättringen genom att enhetstesta sin kod. De kör enhetstester varje gång en ändring flyttas genom bygg-pipelinen, så färre buggar och regressioner når Amita. Den minskade arbetsbelastningen innebär att Amita kan slutföra varje manuellt test snabbare.

Den versionspipeline som du och teamet skapade i den här utbildningsvägen minskade:

  • Den tid det tar att få in bygget i testfasen . Den tid som krävdes gick från tre dagar till en dag.

    Teamet uppnådde detta genom att använda en schemalagd utlösare för att distribuera till Test varje dag klockan 03:00.

  • Den tid det tar att få den testade versionen till Mellanlagring. Den tid som krävdes gick från två dagar till noll dagar.

    Teamet uppnådde denna förbättring genom att lägga till Selenium UI-tester, en form av funktionell testning, i testfasen . Dessa automatiserade tester är mycket snabbare än de manuella versionerna.

  • Den tid det tar att hämta den godkända versionen från mellanlagring till live. Den tid som krävdes gick från en dag till mindre än en dag.

    Teamet uppnådde den här förbättringen genom att lägga till manuella godkännandekontroller i pipelinen. När hantering signeras kan Tim släppa ändringarna från Mellanlagring till live.

Dessa ändringar minskar den totala ledtiden från 22 dagar till 10 dagar. När vi ersätter dessa tal i ekvationen:

$${Activity\ ratio\ =\ }{\dfrac{5\ days}{10\ days}}{ = 0.50}$$

Multiplicera resultatet med 100 procent så får vi en minskning på 50 procent .

Även om det alltid finns utrymme för förbättringar är den här förändringen en vinst för laget. Inte bara får kunderna värde snabbare, Tailspin-teamet ägnar nu mindre tid åt att vänta och mer tid på att göra det de tycker mest om: leverera funktioner som de vet att deras kunder kommer att älska.

Läs mer

Använd dessa ytterligare resurser för att lära dig mer om App Service, distributionsplatser och återställning av ändringar: