Vad är distributionsmönster?

Ett distributionsmönster är ett automatiserat sätt att smidigt distribuera nya programfunktioner till dina användare. Ett lämpligt distributionsmönster hjälper dig att minimera stilleståndstiden. Vissa mönster gör det också möjligt att distribuera nya funktioner progressivt. På så sätt kan du verifiera nya funktioner med utvalda användare innan du gör dessa funktioner tillgängliga för alla.

I det här avsnittet får du lära dig om några vanliga distributionsmönster. Du får också lära dig hur Azure App Service hjälper dig att implementera det mönster som Tailspin-teamet väljer.

Morgonmöte

Tailspin-teamet mår bra. Deras pipeline har påskyndat processen. Teamet har en utvecklingsmiljö där de kan integrera webbappen med en databas. Både Tim och Amita är glada över att ha automatiserade tester som förenklar deras jobb. I allmänhet ser de färre förseningar och färre buggar.

Men det finns som alltid ett problem. Låt oss titta in på lagmötet, där Tim pratar.

Tim: Det är så svårt att hålla alla lyckliga. Irwin tycker att det tar för lång tid att släppa nya funktioner. Jag kan inte göra något förrän ledningen godkänner lanseringen och just nu finns det inget smidigt sätt att distribuera funktionerna efter att de ger OK. Processen är inte bara lång utan rörig. Det är manuellt, och det finns stilleståndstid. Hela processen kan ta fem dagar. Jag vet att det är för långt, men vad ska jag göra? Om jag dricker mer kaffe kanske lösningen kommer till mig.

Andy: Kaffe är viktigt för effektiv problemlösning, utan tvekan.

Jag tror att lösningen vi behöver är ett bra distributionsmönster. Ett implementeringsmönster är ett automatiserat sätt att utföra övergången. Det är så vi flyttar programvaran från den sista förproduktionsfasen till liveproduktion.

Att välja rätt mönster skulle definitivt hjälpa dig, till exempel genom att minimera stilleståndstiden. En annan fördel med ett distributionsmönster är att det ger oss en chans att köra tester som verkligen bör ske i produktion.

Andy börjar skriva på whiteboarden.

Här är de möjligheter vi bör tänka på:

• Blågrön distribution
• Kanarieversioner
• Funktionsväxlingar
• Tysta lanseringar
• A/B-testning
• Gradvis utrullning av exponering

Låt oss kortfattat diskutera varje mönster.

Blågröna utplaceringar

En blågrön distribution minskar risken och stilleståndstiden genom att köra två identiska miljöer. Dessa miljöer kallas blå och gröna. Vid varje tillfälle är endast en av miljöerna aktiv. En blågrön distribution omfattar vanligtvis en router eller lastbalanserare som hjälper till att styra trafikflödet.

Låt oss säga att blått är live. När vi förbereder en ny version gör vi våra sista tester i den gröna miljön. När programvaran fungerar i den gröna miljön växlar vi bara routern så att alla inkommande begäranden går till den gröna miljön.

Blågrön driftsättning ger oss också ett snabbt sätt att göra en återställning. Om något går fel i den gröna miljön växlar vi bara routern tillbaka till den blå miljön.

Kanarieversioner

En kanarieversion är ett sätt att identifiera potentiella problem tidigt utan att utsätta alla användare för problemet. Tanken är att vi exponerar en ny funktion för endast en liten delmängd användare innan vi gör den tillgänglig för alla.

I en kanarieversion övervakar vi vad som händer när vi släpper funktionen. Om versionen har problem tillämpar vi en korrigering. När kanarieversionen är känd för att vara stabil flyttar vi den till den faktiska produktionsmiljön.

Funktionsväxlingar

Använd funktionsväxlingsknappar för att "vända en växel" vid körning. Vi kan distribuera ny programvara utan att exponera några andra nya eller ändrade funktioner för våra användare.

I det här distributionsmönstret lägger Mara och jag till nya funktioner bakom en brytare. När en version lanseras är funktionen avstängd så att den inte påverkar produktionsprogramvaran. Beroende på hur vi konfigurerar växlingsknappen kan vi växla till "på" och exponera funktionen som vi vill.

Vi kan till exempel exponera funktionen först för några användare för att se hur de reagerar. Det slumpmässiga urvalet av användare ser funktionen. Eller så kan vi bara låta funktionen gå live till alla.

Men det här distributionsmönstret kan gynna Mara och mig mer än någon annan. En stor fördel med funktionsväxlingsmönstret är att det hjälper oss att undvika för mycket förgrening. Att slå samman grenar kan vara smärtsamt.

Tysta lanseringar

En mörk start liknar en kanarieversion eller växlar en funktionsväxling. I stället för att exponera en ny funktion för alla släpper vi i en mörk start funktionen till en liten uppsättning användare.

Dessa användare vet inte att de testar funktionen åt oss. Vi markerar inte ens den nya funktionen för dem. Det är därför det kallas en mörk lansering. Programvaran släpps gradvis eller diskret till användarna så att vi kan få feedback och testa prestanda.

A/B-testning

A/B-testning jämför två versioner av en webbsida eller app för att avgöra vilken som presterar bättre. A/B-testning är som ett klassiskt experiment.

I A/B-testning visar vi slumpmässigt användare två eller flera varianter av en sida. Sedan använder vi statistisk analys för att avgöra vilken variation som presterar bättre för våra mål.

Gradvis utrullning av exponering

Distribution med progressiv exponering kallas ibland för ringbaserad distribution. Det är ett annat sätt att begränsa hur ändringar påverkar användarna samtidigt som du ser till att ändringarna är giltiga i en produktionsmiljö.

Ringar är i princip en förlängning av kanariesteget. Själva canary-versionen släpps till en fas för att mäta effekten. Att lägga till en annan ring är i stort sett samma idé.

I en ringbaserad distribution distribuerar vi först ändringar till risktoleranta kunder. Sedan distribuerar vi successivt till en större uppsättning kunder.

Implementera den blågröna utplaceringen

Andy tittar på Tim.

Andy: Det är mycket, jag vet. Vill du ta dig tid att tänka på det? Eller så kan du och jag...

Tim: Blågrön.

Alla i rummet skrattar.

Mara: Är det kaffet som pratar?

Tim: Funktionsväxlingar innebär en ändring i hur du och Andy arbetar. Vi gör en sak i taget. De metoder som gradvis exponerar en funktion kräver statistisk analys eller funktionsväxlingar.

En blågrön distribution är något jag kan styra. Det är enkelt att byta router. Det är enkelt och låter säkert. Och i en blågrön distribution har ledningen en miljö att utvärdera. När de ger OK kan vi enkelt växla. Vi börjar där.

Så frågan är hur vi implementerar en blågrön distribution i vår pipeline?

Vad är distributionsplatser?

Andy: Eftersom vi använder Azure App Service kan vi dra nytta av distributionsplatser. Distributionsplatser kör appar som har egna värdnamn.

Jag vet att vi ännu inte är redo att distribuera Space Game-webbplatsen till produktion som en del av den automatiserade pipelinen. Men som ett test kan vi lägga till ett distributionsfack i vår mellanlagringsmiljö .

I stället för att konfigurera en lastbalanserare eller en router kan vi bara lägga till en andra slot i App Service-instansen som vi använder i vår befintliga staging-miljö. Vi kan kalla det primära facket blått och det sekundära facket grönt.

På så sätt kan vi distribuera nya funktioner utan avbrott. Vi växlar ett program och dess konfiguration mellan de två distributionsplatserna. I grund och botten byter vi IP-adresserna för de två platserna.

Tim: Jag gillar det! Du kan kalla den här varianten av en blågrön distribution för en distribution utan avbrott.

Andy: Bra! Tim och jag ska arbeta med att implementera det här distributionsmönstret. Vi kan alla träffas senare för att se resultatet.

Rekommendationer för att använda funktionsflaggor

Funktionsflaggor var en av de lanseringsmetoder som teamet övervägde. Teamet bestämde sig för att inte använda funktionsflaggor, men många har funnit dem användbara. Det här avsnittet innehåller mer information om funktionsflaggor.

Med funktionsflaggor, som ibland kallas funktionsväxlingar, kan du ändra hur ett system fungerar utan att ändra koden. Med de här flaggorna kan du skicka ny kod till din centrala utvecklingsgren och få koden distribuerad men inte nödvändigtvis funktionell. Flaggorna implementeras ofta som värdet för variabler som styr villkorslogik.

Anta att ditt team arbetar i den centrala utvecklingsgrenen i ett bankprogram. Du bestämde dig för att utföra allt arbete i huvudgrenen för att undvika röriga sammanslagningsåtgärder senare. Men du står inför ett problem. Du ändrar ränteberäkningarna avsevärt och folk är beroende av den koden varje dag. Värre är att ändringarna kommer att ta dig veckor att slutföra. Du kan inte lämna huvudkoden trasig så länge.

I det här scenariot kan en funktionsflagga vara en bra lösning. Du kan ändra koden så att användare som inte har funktionsflaggan angivna kan fortsätta använda den ursprungliga ränteberäkningskoden. Under tiden har ditt team funktionsflaggan inställd, så att de kan se koden som de ändrar.

En annan typ av funktionsflagga är en versionsflagga. Tänk dig att när du har slutfört arbetet med ränteberäkningskoden vill du prova den innan du släpper den offentligt. Du har en grupp användare som är väl positionerade för att hantera ny kod och eventuella problem. Du låter dem prova funktionen först. Du ändrar konfigurationen så att de även har funktionsflaggan inställd och kan testa den nya koden. Om det uppstår problem kan du snabbt inaktivera flaggan.