Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure

Misslyckade distributioner och felaktiga versioner är vanliga orsaker till programfel. Din metod för distribution och testning spelar en viktig roll för den övergripande tillförlitligheten för ett verksamhetskritiskt program.

Distribution och testning bör utgöra grunden för alla program- och infrastrukturåtgärder för att säkerställa konsekventa resultat för verksamhetskritiska arbetsbelastningar. Var beredd på att distribuera varje vecka, varje dag eller oftare. Utforma dina CI/CD-pipelines (kontinuerlig integrering och kontinuerlig distribution) för att stödja dessa mål.

Strategin bör implementera:

• Rigorös förhandsversionstestning. Uppdateringar bör inte medföra defekter, sårbarheter eller andra faktorer som kan äventyra programmets hälsa.

• Transparenta distributioner. Det bör vara möjligt att distribuera uppdateringar när som helst utan att påverka användarna. Användarna bör kunna fortsätta sina interaktioner med programmet utan avbrott.

• Åtgärder med hög tillgänglighet. Distributions- och testprocesser och verktyg måste vara mycket tillgängliga för att stödja övergripande programtillförlitlighet.

• Konsekventa distributionsprocesser. Samma programartefakter och processer bör användas för att distribuera infrastrukturen och programkoden i olika miljöer. Automatisering från slutpunkt till slutpunkt är obligatoriskt. Manuella åtgärder måste undvikas eftersom de kan medföra tillförlitlighetsrisker.

Det här designområdet ger rekommendationer om hur du optimerar distributions- och testprocesser med målet att minimera stilleståndstiden och upprätthålla programmets hälsa och tillgänglighet.

Viktigt!

Den här artikeln är en del av verksamhetskritiska arbetsbelastningsserier för Azure Well-Architected Framework. Om du inte är bekant med den här serien rekommenderar vi att du börjar med Vad är en verksamhetskritisk arbetsbelastning?.

Distribution med noll stilleståndstid

Visa följande video för en översikt över distribution med noll driftstopp.

Att uppnå distributioner utan driftstopp är ett grundläggande mål för verksamhetskritiska program. Ditt program måste vara tillgängligt hela dagen, varje dag, även när nya versioner lanseras under kontorstid. Investera dina ansträngningar i förväg för att definiera och planera distributionsprocesser för att driva viktiga designbeslut som om resurser ska behandlas som tillfälliga.

Om du vill uppnå distribution utan avbrott distribuerar du ny infrastruktur bredvid den befintliga infrastrukturen, testar den noggrant, övergår till slutanvändartrafik och inaktiverar först sedan den tidigare infrastrukturen. Andra metoder, till exempel arkitekturen för skalningsenheter, är också viktiga.

Referensimplementeringarna Mission-Critical Online och Azure Mission-Critical Connected illustrerar den här distributionsmetoden, som du ser i det här diagrammet:

Programmiljöer

Se följande video för en översikt över rekommendationer för programmiljöer.

Du behöver olika typer av miljöer för att verifiera och mellanlagra distributionsåtgärder. Typerna har olika funktioner och livscykeler. Vissa miljöer kan återspegla produktionsmiljön och vara långlivade, och andra kan vara kortvariga och ha färre funktioner än produktion. Genom att konfigurera dessa miljöer tidigt i utvecklingscykeln kan du säkerställa flexibilitet, uppdelning av produktions- och förproduktionstillgångar och noggranna tester av åtgärder innan de släpps till produktionsmiljön. Alla miljöer bör återspegla produktionsmiljön så mycket som möjligt, även om du kan tillämpa förenklingar på lägre miljöer efter behov. Det här diagrammet visar en verksamhetskritisk arkitektur:

Det finns några vanliga överväganden:

• Komponenter ska inte delas mellan miljöer. Möjliga undantag är nedströmssäkerhetsenheter som brandväggar och källplatser för syntetiska testdata.

• Alla miljöer bör använda IaC-artefakter (infrastruktur som kod) som Terraform- eller Azure Resource Manager-mallar (ARM).

Utvecklingsmiljöer

Se följande video för information om tillfälliga utvecklingsmiljöer och automatiserad funktionsvalidering.

Utformningsbeaktanden

• Funktioner. Lägre krav på tillförlitlighet, kapacitet och säkerhet är godtagbara för utvecklingsmiljöer.

• Livscykel. Utvecklingsmiljöer bör skapas efter behov och finnas under en kort tid. Kortare livscykel hjälper till att förhindra att konfigurationen avviker från kodbasen och minskar kostnaderna. Utvecklingsmiljöer delar ofta livscykeln för en funktionsgren.

• Densitet. Teams behöver flera miljöer för parallell funktionsutveckling. De kan samexistera i en enda prenumeration.

Designrekommendationer

• Behåll miljön i en dedikerad prenumeration med kontextuppsättning för utvecklingsändamål.

• Använd en automatiserad process för att distribuera kod från en funktionsgren till en utvecklingsmiljö.

Testa eller mellanlagringsmiljöer

Dessa miljöer används för testning och validering. Många testcykler utförs för att säkerställa buggfri distribution till produktion. Lämpliga tester för en verksamhetskritisk arbetsbelastning beskrivs i avsnittet Kontinuerlig validering och testning .

Utformningsbeaktanden

• Funktioner. Dessa miljöer bör återspegla produktionsmiljön för tillförlitlighet, kapacitet och säkerhet. Om det inte finns någon produktionsbelastning använder du en syntetisk användarbelastning för att tillhandahålla realistiska mått och värdefulla hälsomodelleringsindata.

• Livscykel. De här miljöerna är kortvariga. De bör förstöras när testvalideringarna har slutförts.

• Densitet. Du kan köra många oberoende miljöer i en prenumeration. Du bör också överväga att använda flera miljöer, var och en i en dedikerad prenumeration.

Kommentar

Verksamhetskritiska program bör genomgå rigorösa tester.

Du kan utföra olika testfunktioner i en enda miljö, och i vissa fall måste du göra det. Om du till exempel vill att kaostestning ska ge meningsfulla resultat måste du först placera programmet under belastning så att du kan förstå hur programmet svarar på inmatade fel. Därför utförs kaostestning och belastningstestning vanligtvis parallellt.

Designrekommendationer

• Se till att minst en mellanlagringsmiljö helt återspeglar produktionen för att möjliggöra produktionsliknande testning och validering. Kapaciteten i den här miljön kan flexas baserat på körningen av testaktiviteter.

• Generera syntetisk användarbelastning för att ge ett realistiskt testfall för ändringar i en av miljöerna.

  Kommentar

  Referensimplementeringen Mission Critical Online innehåller ett exempel på en användarbelastningsgenerator.

• Definiera antalet mellanlagringsmiljöer och deras syften inom utvecklings- och lanseringscykeln.

Produktionsmiljöer

Utformningsbeaktanden

• Funktioner. De högsta nivåerna av tillförlitlighet, kapacitet och säkerhetsfunktioner för programmet krävs.

• Livscykel. Även om livscykeln för arbetsbelastningen och infrastrukturen förblir densamma, behöver alla data, inklusive övervakning och loggning, särskild hantering. Till exempel krävs hantering för säkerhetskopiering och återställning.

• Densitet. För vissa program kanske du vill överväga att använda olika produktionsmiljöer för att tillgodose olika klienter, användare eller affärsfunktioner.

Designrekommendationer

Ha en tydlig styrningsgräns för produktion och lägre miljöer. Placera varje miljötyp i en dedikerad prenumeration för att uppnå det målet. Den här segmenteringen säkerställer att resursutnyttjandet i lägre miljöer inte påverkar produktionskvoterna. Dedikerade prenumerationer anger också åtkomstgränser.

Tillfälliga blå/gröna distributioner

En blå/grön distributionsmodell kräver minst två identiska distributioner. Den blå distributionen är den aktiva som hanterar användartrafik i produktion. Den gröna distributionen är den nya som förbereds och testas för att ta emot trafik. När den gröna distributionen har slutförts och testats dirigeras trafiken gradvis från blått till grönt. Om belastningsöverföringen lyckas blir den gröna distributionen den nya aktiva distributionen. Den gamla blå distributionen kan sedan inaktiveras via en stegvis process. Men om det finns problem i den nya distributionen kan den avbrytas och trafiken kan antingen finnas kvar i den gamla blå distributionen eller omdirigeras till den.

Azure Mission-Critical rekommenderar en blå/grön distributionsmetod där infrastruktur och program distribueras tillsammans som en del av en distributionsstämpel. Så om du distribuerar en ändring av infrastrukturen eller programmet resulterar det alltid i en grön distribution som innehåller båda lagren. Med den här metoden kan du testa och verifiera effekten av ändringen mot infrastrukturen och programmet från slutpunkt till slutpunkt innan du omdirigerar användartrafik till den. Metoden ökar förtroendet för att släppa ändringar och möjliggör uppgraderingar utan stilleståndstid eftersom kompatibiliteter med underordnade beroenden som Azure-plattformen, resursprovidrar och IaC-moduler kan verifieras.

Utformningsbeaktanden

• Teknikfunktioner. Dra nytta av de inbyggda distributionsfunktionerna i Azure-tjänster. Azure App Service tillhandahåller till exempel sekundära distributionsplatser som kan växlas efter en distribution. Med Azure Kubernetes Service (AKS) kan du använda en separat podddistribution på varje nod och uppdatera tjänstdefinitionen.

• Distributionens varaktighet. Distributionen kan ta längre tid att slutföra eftersom stämpeln innehåller infrastrukturen och programmet i stället för bara den ändrade komponenten. Detta är dock acceptabelt eftersom risken för att alla komponenter inte fungerar som förväntat åsidosätter tidsproblemen.

• Kostnadspåverkan. Det finns en extra kostnad på grund av de två distributionerna sida vid sida, som måste samexistera tills distributionen är klar.

• Trafikövergång. När den nya distributionen har verifierats måste trafiken övergå från den blå miljön till den gröna. Den här övergången kräver orkestrering av användartrafik mellan miljöerna. Övergången bör vara helt automatiserad.

• Livscykel. Verksamhetskritiska distributionsstämplar bör betraktas som tillfälliga. När du använder kortlivade stämplar skapas en nystart varje gång, innan resurser etableras.

Designrekommendationer

• Använd en blå/grön distributionsmetod för att släppa alla produktionsändringar. Distribuera all infrastruktur och programmet varje gång, för alla typer av ändringar, för att uppnå ett konsekvent tillstånd och noll stilleståndstid. Även om du kan återanvända miljöer rekommenderar vi det inte för verksamhetskritiska arbetsbelastningar. Behandla varje regional distributionsstämpel som tillfällig med en livscykel som är kopplad till en enskild version.

• Använd en global lastbalanserare, till exempel Azure Front Door, för att samordna den automatiserade övergången av användartrafik mellan de blå och gröna miljöerna.

• Om du vill överföra trafik lägger du till en grön serverdelsslutpunkt som använder låg trafik till volymvikt, till exempel 10 procent. När du har kontrollerat att den låga trafikvolymen på den gröna distributionen fungerar och ger den förväntade programhälsan ökar du gradvis trafiken. När du gör det använder du en kort uppfartsperiod för att fånga fel som kanske inte omedelbart är uppenbara.

  När all trafik har övergått tar du bort den blå serverdelen från befintliga anslutningar. Ta till exempel bort serverdelen från den globala lastbalanseringstjänsten, tömma köer och koppla från andra associationer. Detta hjälper till att optimera kostnaden för att underhålla sekundär produktionsinfrastruktur och se till att nya miljöer är fria från konfigurationsavvikelser.

  Nu inaktiverar du den gamla och nu inaktiva blå miljön. För nästa distribution upprepar du processen med blått och grönt omvänt.

Distribution med prenumerationsomfång

Beroende på programmets skalningskrav kan du behöva flera produktionsprenumerationer för att fungera som skalningsenheter.

Visa följande video för att få en översikt över rekommendationer för omfångsprenumerationer för ett verksamhetskritiskt program.

Utformningsbeaktanden

• Skalbarhet. För storskaliga programscenarier med betydande trafikvolymer utformar du lösningen för att skala över flera Azure-prenumerationer så att skalningsgränserna för en enskild prenumeration inte begränsar skalbarheten.

  Viktigt!

  Användningen av flera prenumerationer kräver ytterligare CI/CD-komplexitet, som måste hanteras på rätt sätt. Därför rekommenderar vi endast flera prenumerationer i extrema skalningsscenarier, där gränserna för en enskild prenumeration sannolikt kommer att bli en begränsning.

• Miljögränser. Distribuera produktions-, utvecklings- och testmiljöer i separata prenumerationer. Den här metoden säkerställer att lägre miljöer inte bidrar till skalningsgränser. Det minskar också risken för miljöuppdateringar med lägre miljö som förorenar produktionen genom att tillhandahålla en tydlig hanterings- och identitetsgräns.

• Styrning. När du behöver flera produktionsprenumerationer bör du överväga att använda en dedikerad programhanteringsgrupp för att förenkla principtilldelningen via en principaggregeringsgräns.

Designrekommendationer

• Distribuera varje regional distributionsstämpel i en dedikerad prenumeration för att säkerställa att prenumerationsgränserna endast gäller inom ramen för en enda distributionsstämpel och inte i hela programmet. När det är lämpligt kan du överväga att använda flera distributionsstämplar inom en enda region, men du bör distribuera dem mellan oberoende prenumerationer.

• Placera globala delade resurser i en dedikerad prenumeration för att möjliggöra konsekvent regional prenumerationsdistribution. Undvik att använda en specialiserad distribution för den primära regionen.

Kontinuerlig validering och testning

Testning är en kritisk aktivitet som gör att du kan verifiera hälsotillståndet för programkoden och infrastrukturen fullt ut. Mer specifikt kan du med testning uppfylla dina standarder för tillförlitlighet, prestanda, tillgänglighet, säkerhet, kvalitet och skalning. Testningen måste vara väldefinierad och tillämpad som en del av din programdesign och DevOps-strategi. Testning är ett viktigt problem under den lokala utvecklarprocessen (den inre loopen) och som en del av den fullständiga DevOps-livscykeln (den yttre loopen), vilket är när koden startar på sökvägen från pipelineprocesser för lansering mot produktionsmiljön.

Visa följande video för att få en översikt över kontinuerlig validering och testning.

Det här avsnittet fokuserar på testning av yttre loopar. Den beskriver olika typer av tester.

Test	beskrivning
Enhetstestning	Bekräftar att programmets affärslogik fungerar som förväntat. Verifierar den övergripande effekten av kodändringar.
Röktestning	Identifierar om infrastruktur- och programkomponenter är tillgängliga och fungerar som förväntat. Vanligtvis testas endast en enskild virtuell användarsession. Resultatet bör vara att systemet svarar med förväntade värden och beteende. Vanliga scenarier för röktestning är att nå HTTPS-slutpunkten för ett webbprogram, köra frågor mot en databas och simulera ett användarflöde i programmet.
Användargränssnittstestning	Verifierar att programanvändargränssnitt distribueras och att interaktionen mellan användargränssnittet fungerar som förväntat. Du bör använda verktyg för gränssnittsautomatisering för att driva automatisering. Under ett användargränssnittstest bör ett skript efterlikna ett realistiskt användarscenario och slutföra en serie steg för att utföra åtgärder och uppnå ett avsett resultat.
Belastningstestning	Validerar skalbarhet och programåtgärd genom att öka belastningen snabbt och/eller gradvis tills ett förutbestämt tröskelvärde har nåtts. Belastningstester är vanligtvis utformade kring ett visst användarflöde för att verifiera att programkraven uppfylls under en definierad belastning.
Stresstestning	Tillämpar aktiviteter som överbelastar befintliga resurser för att fastställa lösningsgränser och verifiera systemets förmåga att återställa korrekt. Huvudmålet är att identifiera potentiella flaskhalsar och skalningsgränser för prestanda. Däremot skalar du ned systemets databehandlingsresurser och övervakar hur det fungerar under belastning och avgör om det kan återställas.
Prestandatestning	Kombinerar aspekter av belastnings- och stresstestning för att validera prestanda under belastning och upprätta prestandabeteenden för programåtgärd.
Kaostestning	Injicerar artificiella fel i systemet för att utvärdera hur det reagerar och för att verifiera effektiviteten av återhämtningsåtgärder, operativa procedurer och minskningar. Att stänga av infrastrukturkomponenter, avsiktligt försämra prestanda och införa programfel är exempel på tester som kan användas för att verifiera att programmet reagerar som förväntat när scenarierna faktiskt inträffar.
Intrångstest	Säkerställer att ett program och dess miljö uppfyller kraven för en förväntad säkerhetsstatus. Målet är att identifiera säkerhetsrisker. Säkerhetstestning kan omfatta leveranskedjan för programvara från slutpunkt till slutpunkt och paketberoenden, med genomsökning och övervakning av kända vanliga sårbarheter och exponeringar (CVE).

Utformningsbeaktanden

• Automatisering. Automatiserad testning är viktigt för att validera program- eller infrastrukturändringar i tid och på ett repeterbart sätt.

• Testordning. Den ordning i vilken tester utförs är en viktig faktor på grund av olika beroenden, till exempel behovet av att ha en programmiljö som körs. Testvaraktigheten påverkar också ordningen. Tester med kortare körningstider bör köras tidigare i cykeln när det är möjligt för att öka testeffektiviteten.

• Skalbarhetsgränser. Azure-tjänster har olika mjuka och hårda gränser. Överväg att använda belastningstestning för att avgöra om ett system riskerar att överskrida dem under den förväntade produktionsbelastningen. Belastningstestning kan också vara användbart för att ange lämpliga tröskelvärden för automatisk skalning. För tjänster som inte stöder automatisk skalning kan belastningstestning hjälpa dig att finjustera automatiserade driftprocedurer.

  Systemkomponenternas oförmåga, till exempel aktiva/passiva nätverkskomponenter eller databaser, att skalas på rätt sätt kan vara restriktiv. Stresstestning kan hjälpa dig att identifiera begränsningar.

• Analys av felläge. Det är viktigt att införa fel i programmet och den underliggande infrastrukturen och utvärdera effekten för att utvärdera lösningens redundansmekanismer. Under den här analysen identifierar du risken, effekten och effektens bredd (delvis eller fullständigt avbrott). En exempelanalys som har skapats för referensimplementeringen Mission Critical Online finns i Avbrottsrisker för enskilda komponenter.

• Övervakning. Du bör samla in och analysera testresultat individuellt och även aggregera dem för att utvärdera trender över tid. Du bör kontinuerligt utvärdera testresultat för noggrannhet och täckning.

Designrekommendationer

Visa följande video för att se hur återhämtningstestning kan integreras med Azure DevOps CI/CD-pipelines.

• Säkerställa konsekvens genom att automatisera alla tester på infrastruktur- och programkomponenter. Integrera testerna i CI/CD-pipelines för att orkestrera och köra dem där det är tillämpligt. Information om teknikalternativ finns i DevOps-verktyg.

• Behandla alla testartefakter som kod. De bör underhållas och versionskontrolleras tillsammans med andra programkodartefakter.

• Justera serviceavtalet för testinfrastrukturen med serviceavtalet för distributions- och testcykler.

• Kör röktester som en del av varje distribution. Kör även omfattande belastningstester tillsammans med stress- och kaostester för att verifiera att programmets prestanda och funktionsduglighet bibehålls.

  • Använd belastningsprofiler som återspeglar verkliga användningsmönster med hög belastning.
  • Kör kaosexperiment och felinmatningstester samtidigt som belastningstester.

  Dricks

  Azure Chaos Studio är en inbyggd uppsättning verktyg för kaosexperiment. Verktygen gör det enkelt att utföra kaosexperiment och mata in fel i Azure-tjänster och programkomponenter.

  Chaos Studio tillhandahåller inbyggda kaosexperiment för vanliga felscenarier och stöder anpassade experiment som riktar in sig på infrastruktur och programkomponenter.

• Om databasinteraktioner, som att skapa poster, krävs för belastnings- eller röktester använder du testkonton som har lägre behörighet och gör testdata separerbara från verkligt användarinnehåll.

• Genomsök och övervaka leveranskedjan för programvara från slutpunkt till slutpunkt och paketberoenden efter kända CVE:er.

  • Använd Dependabot för GitHub-lagringsplatser för att säkerställa att lagringsplatsen automatiskt är uppdaterad med de senaste versionerna av paket och program som den är beroende av.

Infrastruktur som koddistributioner

Infrastruktur som kod (IaC) behandlar infrastrukturdefinitioner som källkod som är versionskontrollerad tillsammans med andra programartefakter. Med hjälp av IaC ökar kodkonsekvensen mellan miljöer, eliminerar risken för mänskliga fel under automatiserade distributioner och ger spårbarhet och återställning. För blå/gröna distributioner är det absolut nödvändigt att använda IaC med helt automatiserade distributioner.

En verksamhetskritisk IaC-lagringsplats har två distinkta definitioner som mappas till globala och regionala resurser. Information om dessa typer av resurser finns i kärnarkitekturmönstret.

Utformningsbeaktanden

• Repeterbar infrastruktur. Distribuera verksamhetskritiska arbetsbelastningar på ett sätt som genererar samma miljö varje gång. IaC bör vara den primära modellen.

• Automatisering. Alla distributioner måste vara helt automatiserade. Mänskliga processer är felbenägna.

Designrekommendationer

• Tillämpa IaC och se till att alla Azure-resurser definieras i deklarativa mallar och underhålls på en lagringsplats för källkontroll. Mallar distribueras och resurser etableras automatiskt från källkontrollen via CI/CD-pipelines. Vi rekommenderar inte att du använder imperativa skript.

• Förhindra manuella åtgärder mot alla miljöer. Det enda undantaget är helt oberoende utvecklarmiljöer.

DevOps-verktyg

Effektiv användning av distributionsverktyg är avgörande för den övergripande tillförlitligheten eftersom DevOps-processer påverkar den övergripande funktions- och programdesignen. Redundans- och skalningsåtgärder kan till exempel bero på automatisering som tillhandahålls av DevOps-verktyg. Teknikteamen måste förstå effekten av att en distributionstjänst inte är tillgänglig med avseende på den övergripande arbetsbelastningen. Distributionsverktyget måste vara tillförlitligt och mycket tillgängligt.

Microsoft tillhandahåller två Azure-inbyggda verktygsuppsättningar, GitHub Actions och Azure Pipelines, som effektivt kan distribuera och hantera ett verksamhetskritiskt program.

Utformningsbeaktanden

• Teknikfunktioner. Funktionerna i GitHub och Azure DevOps överlappar varandra. Du kan använda dem tillsammans för att få ut det bästa av båda. En vanlig metod är att lagra kodlagringsplatser i GitHub.com eller GitHub AE när du använder Azure Pipelines för distribution.

  Tänk på komplexiteten som läggs till när du använder flera tekniker. Utvärdera en omfattande funktionsuppsättning mot övergripande tillförlitlighet.

• Regional tillgänglighet. När det gäller maximal tillförlitlighet utgör beroendet av en enskild Azure-region en operativ risk.

  Anta till exempel att trafiken är spridd över två regioner: Region 1 och Region 2. Region 2 är värd för Azure DevOps-verktygsinstansen. Anta att det finns ett avbrott i region 2 och att instansen inte är tillgänglig. Region 1 hanterar automatiskt all trafik och behöver distribuera extra skalningsenheter för att ge en bra redundansupplevelse. Men det kommer inte att kunna göra det på grund av Azure DevOps-beroendet i region 2.

• Datareplikering. Data, inklusive metadata, pipelines och källkod, bör replikeras mellan regioner.

Designrekommendationer

• Båda teknikerna finns i en enda Azure-region, vilket kan göra din strategi för haveriberedskap restriktiv.

  GitHub Actions passar bra för bygguppgifter (kontinuerlig integrering) men kan sakna funktioner för komplexa distributionsuppgifter (kontinuerlig distribution). Med tanke på den omfattande funktionsuppsättningen i Azure DevOps rekommenderar vi den för verksamhetskritiska distributioner. Du bör dock göra ett val när du har utvärderat kompromisser.

• Definiera ett serviceavtal för tillgänglighet för distributionsverktyg och se till att det överensstämmer med bredare krav på programtillförlitlighet.

• För scenarier med flera regioner som använder en aktiv/passiv eller aktiv/aktiv distributionskonfiguration kontrollerar du att redundansorkestrering och skalningsåtgärder kan fortsätta att fungera även om den primära regionen som är värd för distributionsverktyg blir otillgänglig.

Förgreningsstrategi

Det finns många giltiga metoder för förgrening. Du bör välja en strategi som garanterar maximal tillförlitlighet. En bra strategi möjliggör parallell utveckling, ger en tydlig väg från utveckling till produktion och stöder snabba versioner.

Utformningsbeaktanden

• Minimera åtkomsten. Utvecklare bör utföra sitt arbete i feature/* och fix/* grenar. Dessa grenar blir startpunkter för ändringar. Rollbaserade begränsningar bör tillämpas på grenar som en del av förgreningsstrategin. Till exempel kan bara administratörer skapa versionsgrenar eller framtvinga namngivningskonventioner för grenar.

• Accelererad process för nödsituationer. Förgreningsstrategin bör göra det möjligt att sammanfoga snabbkorrigeringar så main snart det är praktiskt möjligt. På så sätt innehåller framtida versioner korrigeringen och återkommande problem undviks. Använd endast den här processen för mindre ändringar som åtgärdar brådskande problem och använder den med fasthållning.

Designrekommendationer

• Prioritera användningen av GitHub för källkontroll.

  Viktigt!

  Skapa en förgreningsstrategi som beskriver funktionsarbete och versioner som ett minimum, och använd grenprinciper och behörigheter för att säkerställa att strategin tillämpas korrekt.

• Utlös en automatiserad testprocess för att verifiera bidrag för kodändringar innan de godkänns. Gruppmedlemmar måste också granska ändringar.

• Behandla grenen main som en kontinuerligt framåtgående och stabil gren som främst används för integreringstestning.

  • Se till att ändringar endast görs main via PRs. Använd en grenprincip för att förbjuda direkta incheckningar.
  • Varje gång en PR slås samman till mainbör den automatiskt starta en distribution mot en integrationsmiljö.
  • Grenen main bör betraktas som stabil. Det bör vara säkert att skapa en version från main vid en viss tidpunkt.

• Använd dedikerade release/* grenar som skapas från grenen main och används för att distribuera till produktionsmiljöer. release/* grenar bör finnas kvar på lagringsplatsen och kan användas för att korrigera en version.

• Dokumentera en snabbkorrigeringsprocess och använd den bara när det behövs. Skapa snabbkorrigeringar i en fix/* gren för efterföljande sammanslagning i versionsgrenen och distribution till produktion.

AI för DevOps

Du kan använda AIOps-metoder i CI/CD-pipelines för att komplettera traditionella testmetoder. Detta möjliggör identifiering av potentiella regressioner eller försämringar och gör att distributioner kan stoppas förebyggande för att förhindra potentiella negativa effekter.

Utformningsbeaktanden

• Mängden telemetridata. CI/CD-pipelines och DevOps-processer genererar en mängd olika telemetri för maskininlärningsmodeller. Telemetrin sträcker sig från testresultat och distributionsresultat till driftdata om testkomponenter från sammansatta distributionssteg.

• Skalbarhet. Traditionella databehandlingsmetoder som Extract, Transform, Load (ETL) kanske inte kan skala dataflödet för att hålla jämna steg med tillväxten av distributionstelemetri och programobservabilitetsdata. Du kan använda moderna analysmetoder som inte kräver ETL och dataflytt, till exempel datavirtualisering, för att möjliggöra kontinuerlig analys av AIOps-modeller.

• Distributionsändringar. Ändringar i distributionen måste lagras för automatiserad analys och korrelation till distributionsresultat.

Designrekommendationer

• Definiera DevOps-processdata som ska samlas in och hur du analyserar dem. Telemetri, till exempel testkörningsmått och tidsseriedata för ändringar i varje distribution, är viktigt.

  • Exponera programobservabilitetsdata från mellanlagrings-, test- och produktionsmiljöer för analys och korrelation i AIOps-modeller.

• Anta MLOps-arbetsflödet.

• Utveckla analysmodeller som är sammanhangsmedvetna och beroendemedvetna för att tillhandahålla förutsägelser med automatiserad funktionsutveckling för att hantera schema- och beteendeändringar.

• Operationalisera modeller genom att registrera och distribuera de bäst tränade modellerna i distributionspipelines.

Gå vidare

Granska säkerhetsövervägandena.

Säkerhet