Dela via

Rekommendationer för att utforma en leverantörskedja för arbetsbelastningsutveckling

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

OE:06 Skapa en leveranskedja för arbetsbelastningar som driver föreslagna ändringar via förutsägbara, automatiserade pipelines. Pipelines testar och höjer upp dessa ändringar i olika miljöer. Optimera en leveranskedja för att göra din arbetsbelastning tillförlitlig, säker, kostnadseffektiv och högpresterande.

Den här guiden beskriver rekommendationerna för att utforma en leveranskedja för arbetsbelastningsutveckling som baseras på ci/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Utveckla en leveranskedja för att säkerställa att du har en förutsägbar, standardiserad metod för att underhålla din arbetsbelastning. CI/CD-pipelines är en manifestation av leveranskedjan, men du bör ha en enda leveranskedja. Och du kan ha flera pipelines som följer samma processer och använder samma verktyg.

Använd en leveranskedja för att skydda din arbetsbelastning mot skador som kan uppstå när du inte hanterar ändringar i arbetsbelastningen korrekt. Var alltid medveten om arbetsbelastningens tillstånd, så du riskerar inte att uppleva oförutsägbart beteende. Den här risken förvärras om du behöver ägna kritisk tid åt att spåra de ändringar som inte har redovisats när problem uppstår. Minimera dessa risker genom att standardisera de processer och verktyg som definierar din leveranskedja och se till att arbetsbelastningsteamet helt förbinder sig att använda dem.

Definition

Period Definition
Leverantörskedja I molnarbetsbelastningar är en leveranskedja en standardiserad uppsättning verktyg och processer som du använder för att påverka infrastruktur- och programändringar i olika miljöer.

Viktiga designstrategier

Kommentar

Rekommendationerna i den här guiden refererar till arbetsbelastningsmiljöer i en kodhöjningskedja. Sandbox-miljön eller andra undersökande och konceptsäkra miljöer kräver mindre stränghet och struktur.

Följande rekommendationer kan hjälpa dig att definiera grundsatserna i din leveranskedja.

Framtvinga en strikt princip för automatiserade mallbaserade distributioner

Gör föreslagna arbetsbelastningsändringar via processer och verktyg för leveranskedjan. Framtvinga en strikt princip för automatiserade mallbaserade distributioner. Den här metoden hjälper till att säkerställa att arbetsbelastningens konfiguration i alla miljöer är standardiserad, väldefinierad och strikt kontrollerad. För miljöer i en kodbefordranskedja ska du inte utföra uppdateringar med hjälp av manuella processer eller mänsklig interaktion med molnplattformens kontrollplan, till exempel portalen eller ett API. Införliva alla ändringar i miljön via en pipeline genom att följa de distributionsmetoder som du definierar. Du kan använda den här principen genom att begränsa åtkomsten till skrivskyddad som standard och använda en åtkomstauktoriseringsgrind för att tillåta skrivåtkomst.

En viktig aspekt av den här grundsats är att alla ändringar är föreslagna ändringar tills de distribueras till produktion. Genom automatiserad testning, till exempel integrering och röktestning, gör du det möjligt för leveranskedjan att automatiskt avvisa ändringar.

Distribuera repeterbar och oföränderlig infrastruktur som kod

Distribuera repeterbar och oföränderlig infrastruktur som kod (IaC). IaC är hanteringen av infrastrukturen i en beskrivande modell som använder ett versionshanteringssystem som speglar källkoden. När du skapar ett program bör samma källkod generera samma binärfil varje gång det kompileras. På liknande sätt genererar en IaC-modell samma miljö varje gång den tillämpas.

Införliva IaC för att säkerställa att ditt team följer en väletablerad standardprocess. Vissa organisationer utser en enskild enskild eller liten grupp individer för att distribuera och konfigurera infrastrukturen. När du implementerar en helt automatiserad process kräver infrastrukturdistributioner mindre hantering från enskilda användare. Ansvaret överförs till automatiseringsprocessen och verktygen. Teammedlemmar kan initiera infrastrukturdistributioner för att upprätthålla konsekvens och kvalitet.

Utforma arbetsbelastningen som en logisk grupp med komponenter som du kan paketera i en mall för att göra distributioner enkla och repeterbara. Du kan se dessa paket som stämplar eller skalningsenheter. Mer information finns i mönstret Distributionsstämplar. När du behöver distribuera din arbetsbelastning för att skala ut till en annan region eller zon inom samma region distribuerar du en stämpel med hjälp av en pipeline. Beroende på hur du utformar dina stämplar kan du distribuera en delmängd av arbetsbelastningen i stället för hela arbetsbelastningen. Inkludera nätverkskomponenter i dina IaC-pipelines för att säkerställa att distributionsstämplarna automatiskt ansluter till befintliga resurser.

Om du vill optimera din IaC-pipeline för konsekvens och effektivitet skapar du en oföränderlig infrastruktur i stället för en föränderlig infrastruktur. Implementera en oföränderlig infrastruktur för att säkerställa att alla system i omfånget ersätts med den uppdaterade konfigurationen samtidigt och identiskt med varje distribution.

Använd samma uppsättning distributionsartefakter i alla miljöer

Använd en uppsättning kodtillgångar och artefakter i alla miljöer och pipelines. En vanlig smärtpunkt för organisationer är när icke-produktionsmiljöer skiljer sig från produktionsmiljöer. Att skapa produktions- och icke-produktionsmiljöer manuellt kan resultera i felmatchade konfigurationer mellan miljöerna. Det här matchningsfelet saktar ned testningen och gör det mer troligt att ändringar kan skada ett produktionssystem. En IaC-metod minimerar dessa problem. När du använder IaC-automatisering kan du använda samma infrastrukturkonfigurationsfiler för alla miljöer för att skapa nästan identiska miljöer. Du kan lägga till parametrar i infrastrukturkonfigurationsfilerna och justera dem för att uppfylla kraven för varje miljö.

För att kontrollera kostnaderna finns det vanligtvis en avvikelse mellan produktions- och icke-produktionsmiljöer. Du behöver ofta inte samma grad av redundans och prestanda i icke-produktionsmiljöer som i produktion. Antalet och SKU:n för dina resurser kan skilja sig mellan miljöer. Se till att du kontrollerar och förstår variansen med hjälp av standardiserade parametrar som hjälper dig att upprätthålla förutsägbarhet när du gör ändringar.

Återspegla organisationsstrukturen i leveranskedjan

Återspegla din organisationsstruktur i leveranskedjan och pipelinedesignen. Din organisation kan vara silod bland team. Varje team kan hantera en del av leveranskedjan. Många organisationer har till exempel team som hanterar infrastrukturdomäner som nätverk, data och beräkningsresurser. De här teamen är åtskilda från utvecklingsteam som hanterar programutveckling, testning och distributioner. I vissa organisationer ingår utvecklings- och infrastrukturteam i DevOps-team som tillsammans hanterar alla infrastruktur- och programdistributioner. Det finns många sätt att organisera de team som är involverade i en leveranskedja. Din leveranskedja förlitar sig på att alla team sömlöst arbetar tillsammans. Se till att alla team följer standardprocesser och använder standardverktyg för att göra leveranskedjan så effektiv som möjligt.

Din leveranskedja kan förlita sig på tredjepartsleverantörer om du outsourcar delar av arbetsbelastningens livscykel. Dessa leverantörer är lika viktiga för att leveranskedjan ska lyckas som interna resurser. Se till att det finns ett ömsesidigt avtal mellan alla team om de processer och verktyg som du använder.

Välj rätt distributionsmetod

Standardisera distributionsmetoden. Prata med produktägaren om den godkända mängden produktionsavbrott för din arbetsbelastning. Beroende på hur mycket, om någon, stilleståndstid är acceptabel kan du välja den distributionsmetod som passar dina behov. Helst bör du utföra distributioner under ett underhållsfönster för att minska komplexiteten och risken. Om ingen stilleståndstid är acceptabel använder du en blågrön distributionsmetod.

Använd en metod för progressiv exponering för att minska risken för att introducera oupptäckta buggar för dina kunder i stort. Den här metoden kallas även för kanariedistributioner och distribuerar till kontrollerade grupper av användare i en gradvis sekvens. Det fångar upp problem innan de påverkar fler användare. Den första distributionsgruppen kan vara ett underavsnitt av dina kunder som är medvetna om distributionsstrategin. Det här underavsnittet av kunder kan tolerera en viss mängd oväntat beteende och ge feedback. Eller så kan det vara en grupp interna användare som hjälper till att innehålla bläddradien för buggar under distributionen.

När du definierar distributionsmetoden antar du en standardprincip för att endast distribuera den minsta livskraftiga ändringen i varje distribution. Beroende på faktorer som arbetsbelastningens allvarlighetsgrad och komponenternas komplexitet avgör du den minsta livskraftiga ändringen. Om du använder en oföränderlig infrastruktur är den minsta genomförbara ändringen vanligtvis distributionen av resurser med den senaste konfigurationen för att ersätta resurser som kör den tidigare versionen. Om du använder en föränderlig infrastruktur kan du besluta att den minsta livskraftiga ändringen bara är en enda uppdatering av resursgruppen i omfånget.

Följ en metod med flera lager

Följ en metod med flera lager för att återspegla olika livscykeler. Grundläggande lager bör förbli statiska under större delen av arbetsbelastningens livscykel och programskikten ändras ofta. För att ta hänsyn till dessa skillnader bör du ha olika pipelines för att genomföra ändringar på varje lager.

En landningszon är på det lägsta lagret. En landningszon är en logisk gruppering av grundläggande element, till exempel prenumerationer, hanteringsgrupper, resursgrupper, styrningsfunktioner och nätverkstopologi. Med en landningszon kan du enkelt distribuera och hantera din arbetsbelastning och tillhandahåller centrala driftsteam eller plattformsteam med en upprepningsbar metod för en miljökonfiguration. För att leverera konsekventa miljöer tillhandahåller alla Azure-landningszoner en uppsättning gemensamma designområden, en referensarkitektur, en referensimplementering och en process för att ändra en distribution så att den passar dina designkrav. Designprinciperna för Azure-landningszonen ger rekommenderade metoder baserat på principdriven styrning tillsammans med prenumerationsdemokratisering. En landningszon bör kräva minimala ändringar under arbetsbelastningens livscykel. Ett exempel på en landningszon finns i Vad är en Azure-landningszon. Den här konceptarkitekturen innehåller en uppsättning yttranden som rekommenderas för Azure.

Din kärninfrastruktur och funktioner, som ingress- och utgående nätverksstyrenheter, belastningsutjämning, nätverksroutningslösningar, DNS-hantering och kärnservrar, bör också kräva ovanliga större ändringar. Men de kan kräva frekventa konfigurationsuppdateringar.

Ditt program- och datalager kräver frekventa konfigurationsuppdateringar och frekventa infrastrukturändringar. Dessa komponenter bör ha de mest dynamiska pipelines.

Införliva omfattande typer av testning

Planera för en holistisk teststrategi. En grundläggande grundsats i systemets tillförlitlighet är skift vänsterprincipen . Att utveckla och distribuera ett program är en process som beskrivs som en serie steg från vänster till höger. Du bör inte begränsa testningen till slutet av processen. Så mycket som möjligt flyttar du testningen till början eller till vänster. Fel är billigare att reparera när du fångar dem tidigt. De kan vara dyra eller omöjliga att åtgärda senare i programmets livscykel.

Testa all kod, inklusive programkod, infrastrukturmallar och konfigurationsskript. Miljön som kör program ska vara versionskontrollerad och distribuerad via samma mekanismer som programkoden. Du kan testa och verifiera miljön med hjälp av samma testparadigm som dina team redan använder för programkod.

Använd automatiserad testning när det är möjligt för att säkerställa konsekvens. Inkludera följande typer av testning i din design för leveranskedjan.

  • Enhetstestning: Enhetstester körs vanligtvis som en del av en kontinuerlig integreringsrutin. Enhetstester bör vara omfattande och snabba. De bör helst täcka 100 procent av koden och köras på under 30 sekunder.

    Implementera enhetstestning för att kontrollera att syntaxen och funktionerna i enskilda kodmoduler fungerar som de ska, till exempel genom att skapa definierade utdata för kända indata. Du kan också använda enhetstester för att kontrollera att IaC-tillgångar är giltiga.

    Tillämpa enhetstester på alla kodtillgångar, inklusive mallar och skript.

  • Röktestning: Röktester kontrollerar att en arbetsbelastning kan ställas upp i en testmiljö och fungerar som förväntat. Röktester verifierar inte komponenternas samverkan.

    Röktester kontrollerar att distributionsmetoden för infrastrukturen och programmet fungerar och att systemet svarar som avsett när processen är klar.

  • Integreringstestning: Integreringstester säkerställer att programkomponenterna fungerar individuellt och avgör sedan om komponenter kan interagera med varandra som de ska.

    Det kan ta lång tid att köra en stor integreringstestsvit. Därför är det bäst att införliva skift vänster-principen och utföra testning tidigt i livscykeln för programvaruutveckling. Reservera integreringstester för scenarier som du inte kan testa med ett röktest eller enhetstest.

    Du kan köra långvariga testprocesser regelbundet om det behövs. Ett regelbundet intervall ger en bra kompromiss och identifierar samverkansproblem mellan programkomponenter senast en dag efter att de har introducerats.

    Vissa testscenarier drar nytta av manuella körningar. Använd manuell testning när du behöver introducera mänskliga interaktivitetselement i tester.

  • Godkännandetestning: Beroende på kontexten kan du utföra godkännandetestning manuellt. Den kan vara delvis eller helt automatiserad. Godkännandetestning avgör om programvarusystemet uppfyller kravspecifikationerna.

    Huvudsyftet med det här testet är att utvärdera systemets efterlevnad av affärskraven och avgöra om systemet uppfyller de kriterier som krävs för leverans till slutanvändare.

Implementera kvalitetsgrindar i kodbefordransprocesser

Implementera kvalitetsgrindar under hela kodhöjningsprocessen via testning. Distribuera koden till lägre miljöer, till exempel utveckling och testning, och uppåt via högre miljöer, till exempel mellanlagring och produktion. När distributionen passerar genom kvalitetsgrindar ser du till att den uppfyller dina kvalitetsmål innan ändringarna går till produktion. Dina affärskrav avgör vad fokuset för dina kvalitetsgrindar är. Tänk också på de grundläggande principerna för välkonstruerat ramverk: säkerhet, tillförlitlighet och prestandaeffektivitet.

Integrera även arbetsflöden för godkännande i dina kvalitetsgrindar. Definiera och automatisera arbetsflöden för godkännande när det är lämpligt. Definiera kriterier för kvalitetsgodkännande i din automatisering så att du kan gå igenom portarna på ett effektivt och säkert sätt.

Azure-underlättande

Azure DevOps är en samling tjänster som hjälper dig att skapa en samarbetsinriktad, effektiv och konsekvent utvecklingspraxis.

Azure Pipelines tillhandahåller bygg- och versionstjänster för att stödja CI/CD i dina program.

GitHub Actions för Azure integreras med Azure för att förenkla distributioner. Använd GitHub Actions för att automatisera CI/CD-processer. Du kan skapa arbetsflöden som skapar och testar varje pull-begäran till din lagringsplats eller distribuera sammanfogade pull-begäranden till produktion.

Du kan använda Terraform-, Bicep- och Azure Resource Manager för IaC-distributioner. Beroende på dina krav och teamets kunskaper om verktygen kan du använda ett eller flera av dessa verktyg för dina distributioner och hantering av resurserna.

Exempel

Ett exempel som visar hur du använder Azure Pipelines för att skapa en CI/CD-pipeline finns i Baslinjearkitektur för Azure Pipelines.

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för driftskvalitet