Använda säkra distributionsmetoder
|
---|
Under utvecklingscykeln går arbetsbelastningsartefakter igenom många ändringar när de implementeras och testas och när buggar åtgärdas.
Distributionsprocessen måste följa en standardprocedur. Alla ändringar måste distribueras med samma stränghetsnivå. Den här principen gäller även för kod, konfiguration och alla relaterade artefakter. Nyckeln är att tillämpa säkra metoder så tidigt som möjligt så att du får förutsägbarhet i produktionen. Även om felen når kunderna bör du kunna distribuera återställningsändringar så snart som möjligt.
Exempelscenario
Contoso Air har utvecklat en webbapp som gör att kunden kan boka flyg direkt via appen. Appen har körts i produktion i över ett år.
Appen är helt distribuerad i Azure och bygger på Azure App Service, Azure Cosmos DB, Azure Functions, Azure Logic Apps och Azure Service Bus.
Kodifiera standarder för automatiserad distribution
Standardisera processen för att distribuera alla ändringar med hjälp av automatiserade distributionsprocesser, till exempel pipelines. Alla miljöer måste använda pipelines. Klassificera tillgångar och versioner per miljö så att de enkelt kan spåras och identifieras.
Konsekventa distributionsmetoder minskar problem som orsakas av processfel och varians och gör att du kan fokusera på arbetsbelastningsproblemen.
Standardisering säkerställer att distributionen slutförs på ett säkert, tillförlitligt och repeterbarhetsfritt sätt.
Klassificering gör det enkelt att visa loggar för tidigare distributioner och problem som har inträffat. Du kanske kan använda den informationen för att påskynda återställnings- och återställningsåtgärder.
Contosos utmaning
- Contoso Air-arbetsbelastningsteamet använder automatiserade bygg- och distributionspipelines, men distributioner kräver normalt manuella åtgärder under hela åtgärden för att ändra och validera olika konfigurationsinställningar.
- På grund av manuella åtgärder finns det ofta fel i distributionen, vilket gör varje version till en mycket stressig och störande händelse för hela teamet. Den manuella åtgärden gör det också svårt att återställa när en distribution misslyckas.
Tillämpa metoden och resultaten
- Teamet allokerar tid för att automatisera konfigurationsändringarna som en del av distributionen och integrera de tillagda funktionerna i de befintliga distributionspipelines.
- Konfigurationsinställningarna som är associerade med varje miljö externaliseras till respektive JSON-filer som sparas i källkontrollen för ytterligare spårning. Inställningar som anses vara hemligheter sparas i hemliga valvlager, som även allokeras till varje miljö.
- Alla ändringar loggas nu under distributionen, vilket ger fullständig spårningsbarhet för att hjälpa till med felsökningsinsatser och granskningar. Teamet lägger också till automatiserade tester för att verifiera konfigurationsändringarna i pipelinen.
- Därefter kommer teamet att arbeta med att helt automatisera återställningar för att ytterligare optimera processer.
- Som ett resultat av den nya automatiseringen har distributionerna varit mer tillförlitliga och förutsägbara, och teammorsmoren har också ökat.
Distribuera ofta
Distribuera små inkrementella uppdateringar med jämna mellanrum.
Med den här metoden kan du hålla användarberättelser och arbetsobjekt hanterbara från projekthanteringssynpunkt och minska risken för storskaliga problem när distributioner misslyckas.
Contosos utmaning
- Teamets distributionsprocesser har tidigare varit att göra större versioner var tredje till fjärde månad. Den här metoden gör det svårt att verifiera versionen. Teamet har också haft svårt att felsöka problem med så många rörliga delar.
- Problematiska versioner som kräver snabbkorrigeringar i mitten av versionen eller som måste återställas och överges har inträffat flera gånger.
- Utgåvor är mycket stressande och har behandlats som "alla händer på däck"-situationer, vilket har påverkat lagets moral negativt.
Tillämpa metoden och resultaten
- Efter den senaste problematiska versionen bad intressenterna teamet att komma fram till en bättre metod för distributioner. Teamet bestämde sig för att ändra sina metoder för att gynna frekventa, små förändringar. De begränsar omfånget för varje version till en eller (högst) några relaterade ändringar som testas noggrant när bygget höjs upp i de lägre miljöerna.
- Därför har utgåvorna blivit mycket mer effektiva och kvaliteten har ökat. Versionerna är enklare att verifiera och problem är enklare att felsöka.
- Att ha en regelbunden takt av förutsägbara utgåvor har bidragit till att återställa teamets självförtroende och moral. Användarna drar också nytta av detta. Med högre versionskvalitet ser de mindre störningar och får åtkomst till nya funktioner mycket tidigare.
Använda en progressiv exponeringsmetod
Distribuera uppdateringar gradvis, med due diligence. Använd distributionsmodeller som ger dig kontrollen att gradvis öka antalet instanser och kunder tills uppdateringen antas på ett säkert sätt av alla.
Testa varje uppdatering på ett kontrollerat sätt så att problem åtgärdas tidigt i produktionen. Undvik att lansera en felaktig uppdatering som påverkar hela kundbasen.
Testa om uppdateringen är bakåtkompatibel och framåtkompatibel.
Contosos utmaning
- Teamet ser stora fördelar med att byta metod för att göra mindre versioner. De ägnar mindre tid nu åt versionerna och känner sig energiska för att fortsätta på vägen mot ytterligare förbättringar av driftskvaliteten.
- När de experimenterar med nya funktioner har vissa av ändringarna inte tagits emot väl av användare eller orsakat en ökning av supportsamtal på grund av den branta inlärningskurvan de tar med sig.
- De undrar hur de kan fortsätta att förnya sina program för att maximera användarens produktivitet, samtidigt som de minimerar effekten av att släppa funktioner som kanske inte är lika populära eller lätta att använda.
Tillämpa metoden och resultaten
- De bestämde sig för att implementera en funktionsversionsmodell som exponerar nya funktioner för användare stegvis med hjälp av funktionsflaggor.
- Under planeringsstegen för nya funktioner definieras ett kriterium för att välja vilka användare som ska exponeras för funktionen först. En liten grupp användare väljs för att ta emot den nya funktionen först. Beroende på användarfeedback distribueras funktionen till successivt större grupper tills hela användarpopulationen kör den nya versionen. När fler användare exponeras för de nya funktionerna dokumenterar supportteamet resultatet av supportärendena för att dela internt och eventuellt fylla i de externa vanliga frågorna.