Distribution och testning för verksamhetskritiska arbetsbelastningar i Azure

Misslyckade distributioner och felaktiga versioner är vanliga orsaker till programstopp. 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 (continuous integration and continuous deployment) för att stödja dessa mål.

Strategin bör implementera:

• Rigorös förhandsversionstestning. Uppdateringar bör inte infö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 testningsprocesser och verktyg måste ha hög tillgänglighet 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 testningsprocesser 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 den verksamhetskritiska arbetsbelastningsserien 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 stilleståndstid.

Att uppnå distributioner utan stilleståndstid ä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, till exempel om resurser ska behandlas som tillfälliga.

Om du vill uppnå distribution utan stilleståndstid distribuerar du ny infrastruktur bredvid den befintliga infrastrukturen, testar den noggrant, överför 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. Att konfigurera dessa miljöer tidigt i utvecklingscykeln bidrar till att säkerställa flexibilitet, separation av produktions- och förproduktionstillgångar och noggrann testning 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 underordnade säkerhetsinstallationer 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.

Designöverväganden

• Funktioner. Lägre krav för 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 kontexten inställd 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 .

Designöverväganden

• 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. Dessa miljöer ä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.

Anteckning

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. För att kaostestning ska ge meningsfulla resultat måste du till exempel först placera programmet under belastning så att du kan förstå hur programmet svarar på inmatade fel. Det är därför kaostestning och belastningstestning vanligtvis utförs 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.

  Anteckning

  Referensimplementeringen För verksamhetskritisk online är ett exempel på en generator för användarbelastning.

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

Produktionsmiljöer

Designöverväganden

• 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. Att distribuera en ändring av infrastrukturen eller programmet resulterar därför alltid i en grön distribution som innehåller båda lagren. Med den här metoden kan du fullständigt 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 kompatibilitet med underordnade beroenden som Azure-plattformen, resursprovidrar och IaC-moduler kan verifieras.

Designöverväganden

• Teknikfunktioner. Dra nytta av de inbyggda distributionsfunktionerna i Azure-tjänster. Till exempel tillhandahåller Azure App Service 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 den för en enda 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 tillämpar du en kort ramp-up-period 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. På så sätt kan du optimera kostnaden för att underhålla den sekundära produktionsinfrastrukturen 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å och grön omvänd.

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.

Designöverväganden

• 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 flera prenumerationer endast i scenarier med extrem skalning, 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 i en enda region, men du bör distribuera dem i oberoende prenumerationer.

• Placera globala delade resurser i en dedikerad prenumeration för att möjliggöra konsekvent distribution av regionala prenumerationer. 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 fullständigt. Mer specifikt kan du med testning uppfylla dina standarder för tillförlitlighet, prestanda, tillgänglighet, säkerhet, kvalitet och skala. 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 hela DevOps-livscykeln (den yttre loopen), vilket är när koden startar på sökvägen från pipelineprocesser till 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.

Testa	Description
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.
Gränssnittstestning	Verifierar att programanvändargränssnitt distribueras och att interaktionen med 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 uppnå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. Skala däremot ned systemets databehandlingsresurser och övervaka hur det beter sig under belastning och avgöra om det kan återställas.
Prestandatestning	Kombinerar aspekter av belastnings- och stresstestning för att verifiera prestanda under belastning och upprätta benchmark-beteenden 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 åtgärder. 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).

Designöverväganden

• Automatisering. Automatiserad testning är viktigt för att validera program- eller infrastrukturändringar i tid och upprepningsbart.

• Testordning. I vilken ordning testerna 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örtider 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 ställa in lämpliga tröskelvärden för autoskalning. För tjänster som inte har stöd för automatisk skalning kan belastningstestning hjälpa dig att finjustera automatiserade operativa procedurer.

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

• Analys av felläge. Det är viktigt att introducera 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, påverkan och bredden på påverkan (partiellt eller fullständigt avbrott). En exempelanalys som har skapats för referensimplementeringen av 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

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

• Säkerställ konsekvens genom att automatisera alla tester av 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 versionsstyras 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 funktionsbarhet upprätthålls.

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

  Tips

  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 har stöd för anpassade experiment som riktar in sig på infrastruktur- och programkomponenter.

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

• Skanna och övervaka slutpunkt till slutpunkt-programleveranskedjan och paketberoenden för 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 versionskontrollad tillsammans med andra programartefakter. Användning av IaC främjar kodkonsekvens 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.

Designöverväganden

• 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. Till exempel kan redundans- och skalningsåtgärder vara beroende av automatisering som tillhandahålls av DevOps-verktyg. Teknikteamen måste förstå effekten av att en distributionstjänst inte är tillgänglig i förhållande till den övergripande arbetsbelastningen. Distributionsverktygen måste vara tillförlitliga och ha hög tillgänglighet.

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

Designöverväganden

• 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 enda Azure-region en operativ risk.

  Anta till exempel att trafiken är utspridd över två regioner: Region 1 och Region 2. Region 2 är värd för Azure DevOps-verktygsinstansen. Anta att det uppstår 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öras 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 redundansorkestrerings- och skalningsåtgärder kan fortsätta att fungera även om den primära regionen som är värd för distributionsverktygsuppsättningar 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 har stöd för snabba versioner.

Designöverväganden

• Minimera åtkomsten. Utvecklare bör utföra sitt arbete i grenarna funktion/* och korrigering/* . Dessa grenar blir startpunkter för ändringar. Rollbaserade begränsningar bör tillämpas på grenar som en del av förgreningsstrategin. Tillåt till exempel endast administratörer att skapa versionsgrenar eller tillämpa namngivningskonventioner för grenar.

• Accelererad process för nödsituationer. Förgreningsstrategin bör tillåta att snabbkorrigeringar slås samman till huvud så snart det är praktiskt möjligt. På så sätt innehåller framtida versioner korrigeringen och upprepning av problemet undviks. Använd endast den här processen för mindre ändringar som åtgärdar brådskande problem och använder den med återhållsamhet.

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 testningsprocess för att verifiera bidrag till kodändringar innan de godkänns. Gruppmedlemmar måste också granska ändringar.

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

  • Se till att ändringar endast görs i huvuddata via pr. Använd en grenprincip för att förhindra direkta incheckningar.
  • Varje gång en PR slås samman till main bör den automatiskt starta en distribution mot en integrationsmiljö.
  • Huvudgrenen bör betraktas som stabil. Det bör vara säkert att skapa en version från main när som helst.

• Använd dedikerade versions-/* grenar som skapas från huvudgrenen och används för att distribuera till produktionsmiljöer. release/* grenar ska 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.

Designöverväganden

• 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 databearbetningsmetoder 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.

• Implementera MLOps-arbetsflödet.

• Utveckla analysmodeller som är sammanhangsmedvetna och beroendemedvetna för att ge förutsägelser med automatiserad funktionsteknik för att hantera schema- och beteendeändringar.

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

Nästa steg

Granska säkerhetsövervägandena.

Säkerhet