Rekommendationer för att utforma en leveranskedja för arbetsbelastningsutveckling

  • Artikel

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

OE:06 Skapa en arbetsbelastningsförsörjningskedja 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 ä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 fullt ut åtar 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

Anteckning

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 noggrannhet och struktur.

Grundläggande grundsatser

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

Gör föreslagna arbetsbelastningsändringar via leveranskedjeprocesser och verktyg. 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 noggrant kontrollerad. För miljöer i en kodbefordringskedja 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 (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 den 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 din arbetsbelastning 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 dina distributionsstämplar ansluter automatiskt till befintliga resurser.

Om du vill optimera din IaC-pipeline för konsekvens och effektivitet skapar du en oföränderlig infrastruktur snarare än 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 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 matchningslösa konfigurationer mellan miljöerna. Det här matchningsfelet gör testningen långsammare 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 så att de uppfyller kraven för varje miljö.

För att kontrollera kostnaderna finns det vanligtvis en avvikelse mellan produktionsmiljöer 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 åt 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ägbarheten när du gör ändringar.

Återspegla organisationens struktur 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, till exempel nätverk, data och beräkningsresurser. Dessa team ä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 en ömsesidig överenskommelse mellan alla team om de processer och verktyg som du använder.

Standardisera distributionsmetoden. Prata med produktägaren om den godkända mängden produktionsavbrott för din arbetsbelastning. Beroende på hur mycket, om någon, driftstopp är acceptabel kan du välja den distributionsmetod som passar dina behov. Helst bör du utföra distributioner under en underhållsperiod 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 radien för buggar under distributionen.

När du definierar distributionsmetoden antar du en standardprincip för att endast distribuera den minsta genomförbara ändringen i varje distribution. Beroende på faktorer som arbetsbelastningens allvarlighetsgrad och komplexiteten hos komponenterna avgör du den minsta genomförbara ä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 bestämma att den minsta genomförbara ändringen bara är en enda uppdatering av resursgruppen i omfånget.

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 vanliga 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-landningszoner ger rekommenderade metoder som baseras på principdriven styrning vid sidan av prenumerationsdemokratisering. En landningszon bör kräva minimala ändringar under arbetsbelastningens livscykel.

Din kärninfrastruktur och funktioner, till exempel 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 pipelinesna.

Planera för en holistisk teststrategi. En grundläggande grundsats i systemets tillförlitlighet är skift vänster-principen . 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 bör versionskontrolleras och distribueras via samma mekanismer som programkod. 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 leveranskedjas design.

  • 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 att producera en definierad 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 integrationstestsvit. Därför är det bäst att införliva skift vänsterprincipen 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 med jämna mellanrum 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 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 fokus för dina kvalitetsgrindar är. Tänk också på de grundläggande principerna för Well-Architected Framework: 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 effektivt och säkert.

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 som stöder 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.

Organisatorisk anpassning

Cloud Adoption Framework ger vägledning för centrala team för att tillhandahålla landningszoner för arbetsbelastningar. Landningszonerna för arbetsbelastningen är där arbetsbelastningens anpassade leveranskedja distribuerar program till.

Mer information finns i Landningszoner och designprinciper för Azure-landningszoner.

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 utmärkt drift