Rekommendationer för utformning av försörjningskedja för arbetsbelastningsutveckling
Gäller för den här Power Platform rekommendationen för checklistan Well-Architected Operational Excellence:
| OE:06 | Bygg upp en försörjningskedja för arbetsbelastning som driver fram föreslagna ändringar genom automatiserade pipelines. Pipelines testar och främjar dessa ändringar i olika miljöer. Optimera en försörjningskedja för att göra din arbetsbelastning tillförlitlig, säker, kostnadseffektiv och presterande. |
|---|
I den här guiden beskrivs rekommendationer för hur du utformar en försörjningskedja för arbetsbelastningsutveckling som bygger pipelines med kontinuerlig integrering och kontinuerlig försörjning (CI/CD). I molnarbetsbelastningen är en försörjningskedja en standardiserad uppsättning verktyg och processer som du använder för att påverka konfigurations- och arbetsbelastningsförändringar i olika miljöer. Utveckla en försörjningskedja för att säkerställa att du har en standardiserad metod för att bevara arbetsbelastningen. CI/CD-pipelines är manifestationen av försörjningskedjan, men du bör ha en enda försörjningskedja. Du kan ha flera pipelines som följer samma processer och använder samma verktyg.
Inkludera en försörjningskedja för att skydda din arbetsbelastning från skador som kan uppstå när du inte hanterar ändringar i arbetsbelastningen på rätt sätt. Var alltid medveten om tillståndet för din arbetsbelastning, så att du inte riskerar att uppleva oförutsägbart beteende. Den här risken ökar om du behöver ägna viktig tid åt att spåra oredovisade ändringar när problem uppstår. Standardisera processer och verktyg för att minimera riskerna och se till att ditt arbetsbelastningsteam använder systemet helt och hållet.
Viktiga designstrategier
Med hjälp av följande rekommendationer kan du definiera huvudprinciperna för försörjningskedjan.
Gör föreslagna arbetsbelastningsändringar via processer och verktyg för försörjningskedja. Se till att automatiska mallbaserade distributioner tillämpas. Med den här metoden kan du se till att arbetsbelastningens konfiguration i alla miljöer är standardiserad, väldefinierad och säkert kontrollerad. För miljöer i en kodkampanj ska du inte utföra uppdateringar med hjälp av manuella processer eller interaktion mellan människor. Införliva alla ändringar i miljön med en pipeline genom att följa de distributionsrutiner du anger. Du kan se till att policyn efterlevs genom att begränsa åtkomsten till skrivskyddade data som standard och genom att använda en åtkomstbehörighetsgrind för att tillåta skrivåtkomst.
En viktig aspekt av denna princip är att alla förändringar är föreslagna ändringar tills de implementeras i produktionen Med hjälp av automatiserade tester, som integration och grovtest, gör du det möjligt för din försörjningskedja att automatiskt avvisa ändringar.
Använd en uppsättning kodresurser och artifakter i alla miljöer och pipelines. En vanlig stötesten för organisationer är när icke-produktionsmiljöer skiljer sig från produktionsmiljöer. Om produktions- och icke-produktionsmiljöer skapas manuellt kan det leda till felaktiga konfigurationer mellan miljöerna. Denna felmatchning saktar ner testningen och gör det mer sannolikt att ändringar kan skada ett produktionssystem.
Spegla din organisationsstruktur i din försörjningskedja och pipelinedesign. Din organisation kan vara indelad i silor mellan teamen Varje team kan hantera en del av försörjningskedjan. Många organisationer har till exempel team som hanterar säkerhets- och regelefterlevnadsinställningar eller miljökonfigurationer. Dessa team är separerade från utvecklingsteam som hanterar programutveckling, testning och distributioner. Det finns många sätt att ordna de team som är involverade i en försörjningskedja. Din försörjningskedja är beroende av att alla team arbetar sömlöst tillsammans. Se till att alla team följer standardprocesserna och använder standardverktyg för att göra försörjningskedjan så effektiv som möjligt.
Din försörjningskedja kan vara beroende av tredjepartsleverantörer om du lägger ut delar av arbetsbelastningens livscykel på entreprenad. Dessa leverantörer är lika viktiga för att din försörjningskedja ska lyckas som interna resurser. Se till att Dit finns en ömsesidig överenskommelse mellan alla team om de processer och verktyg som du använder.
Standardisera distributionsmetoden. Prata med produktägaren om den acceptabla mängden produktionsstopp för din arbetsbelastning. Beroende på hur mycket driftavbrott som kan accepteras kan du välja den distributionsmetod som är rätt för dina krav. Du bör därför utföra distributioner i samband med underhåll för att minska komplexiteten och risken.
Planera för en holistisk teststrategi. En grundläggande princip för systemtillförlitlighet är principen om "skift vänster". Att utveckla och distribuera ett program är en process som beskrivs som en serie med steg från vänster till höger. Du bör inte begränsa testerna till slutet av processen. Så mycket som möjligt kan du flytta testningen till början eller åt vänster. Fel är billigare att reparera när du upptäcker dem tidigt. De kan vara dyra eller omöjliga att åtgärda senare i programmets livscykel.
Om det är möjligt kan du använda automatiserade tester för att säkerställa enhetlighet. Ta med följande typer av tester i utformningen av försörjningskedjan:
Enhetstestning: Enhetstester körs vanligtvis som en del av en rutin för kontinuerlig integrering. Enhetstester bör vara omfattande och snabba. De ska täcka 100 procent av koden. Tillämpa enhetstester på alla kodtillgångar, inklusive mallar och skript.
Rökprovning: Röktester verifierar att en arbetsbelastning kan ställas upp i en testmiljö och fungerar som förväntat. Grovtester verifierar inte komponenternas interoperabilitet. Grovtester verifierar att implementeringsmetoden för infrastrukturen och programmet fungerar och att systemet svarar som avsett efter att processen är klar.
Integrationstestning: Integrationstester säkerställer att applikationskomponenterna fungerar individuellt och sedan avgör om komponenterna kan interagera med varandra som de ska. Det kan ta avsevärd tid att köra en stor integrationstestsvit. Därför är det bäst att införliva shift-left-principen och utföra tester tidigt i mjukvaruutvecklingens livscykel. Reservera integrationstester för scenarier som du inte kan testa med ett grovtest eller enhetstest. Du kan köra långa testprocesser med ett regelbundet intervall om det behövs. Ett regelbundet intervall ger ett bra sätt att identifiera problem mellan programkomponenterna senast en dag efter det att de introduceras. Vissa testscenarier har nytta av manuella körningar. Använd manuell testning när du behöver introducera mänskliga interaktivitetselement i tester.
Acceptanstestning: Beroende på sammanhanget kan du utföra acceptanstestning manuellt. Den kan vara helt eller delvis automatiserad. Acceptanstester avgör om programvarusystemet uppfyller kravspecifikationerna. Huvudsyftet med detta test är att utvärdera systemets överensstämmelse med affärskraven och avgöra om systemet uppfyller de kriterier som krävs för leverans till användare.
Implementera kvalitetsgrindar genom hela kodmarknadsföringsprocessen genom testning. Distribuera koden i lägre miljöer, som kvalitetssäkring och testning och högre miljöer, som mellanlagring och produktion. När distributionen klarar kvalitetsmålen bör du se till att den uppfyller kvalitetsmålen innan produktionsändringarna sker. Dina affärskrav avgör vad dina kvalitetsgrindar fokuserar på. Tänk också på de grundläggande Power Platform Well-Architected-principerna: Säkerhet, Tillförlitlighet och Prestandaeffektivitet.
Integrera också godkännandearbetsflöden i kvalitetsgrindar. Definiera och automatisera arbetsflöden för godkännande när det behövs. Definiera kriterier för kvalitetsgodkännande i din automation, så att du kan röra dig genom dina grindar effektivt och säkert.
Underlätta Power Platform
Pipelines syftar Power Platform till att demokratisera hantering av programmets livscykel (ALM) för Power Platform och Dynamics 365-kunder genom att införa ALM-automatisering och CI/CD-funktioner (kontinuerlig integrering och kontinuerlig leverans) i tjänsten.
Microsoft Power Platform Byggverktyg för kan användas för Azure DevOps att automatisera vanliga bygg- och distributionsuppgifter relaterade till appar som bygger på Power Platform.
GitHub Actions för att göra det möjligt för utvecklare att skapa automatiserade arbetsflöden för Power Platform programvaruutvecklingens livscykel. Med GitHub-åtgärder för Microsoft Power Platform, kan du skapa arbetsflöden i ditt arkiv för att bygga, testa, paketera, släppa och distribuera appar; utföra automatisering; och hantera bots och andra komponenter som bygger på Power Platform.
ALM Accelerator är ett verktyg med öppen källkod som består av en uppsättning applikationer, skript och pipelines som är utformade för att automatisera processen för kontinuerlig integrering/kontinuerlig leverans.
Automatisera tester med Azure Pipelines.
Power Apps checker Web API tillhandahåller en mekanism för att köra statiska analyskontroller mot anpassningar och tillägg till Microsoft Dataverse plattformen.
Microsoft Power Platform CLI (PAC CLI) är ett kommandoradsverktyg som stöder import och export av Power Platform lösningar samt packning till och uppackning från Power Platform lösningarnas källfiler. PAC CLI är tillgängligt som ett fristående kommandoradsverktyg eller som ett tillägg för Visual Studio Code.
Du kan använda Terraform, Bicep och Azure Resource Manager för oföränderliga IaC-distributioner (infrastruktur som kod). Beroende på dina krav och teamets kännedom om verktygen kan du använda ett eller flera av dessa verktyg för distributionerna och hanteringen av resurserna.
Organisationsanpassning
Cloud Adoption Framework ger vägledning för centrala team som tillhandahåller landningszoner för arbetsbelastningen. Landningszonerna för arbetsbelastningar är den plats där arbetsbelastningens anpassade försörjningskedja distribuerar program till.
Läs mer i Vad är en Azure-landningszon? och designprinciperna för Azure-landningszoner.