Anbefalinger for utforming av en forsyningskjede for arbeidsbelastningsutvikling

Gjelder denne Power Platform anbefalingen for Well-Architected Operational Excellence-sjekklisten:

Denne veiledningen beskriver anbefalingene for utforming av en leveringskjede for arbeidsbelastningsutvikling som er basert på kontinuerlig integrasjon og CI/CD-pipeliner (kontinuerlig levering). I skyarbeidsbelastninger er en forsyningskjede en standardisert pakke med verktøy og prosesser som du bruker for å påvirke endring av konfigurasjon og arbeidsbelastning på tvers av miljøer. Utvikle en leveringskjede for å sikre at du har en forutsigbar, standardisert metode for vedlikehold av arbeidsbelastningen. CI/CD-pipeliner er manifestasjonen av forsyningskjeden, men du bør ha én enkelt forsyningskjede. Du kan ha flere pipeliner som følger de samme prosessene og bruker de samme verktøyene.

Innarbeid en forsyningskjede for å beskytte arbeidsbelastningen mot skade som kan oppstå når du ikke håndterer arbeidsbelastningsendringer på riktig måte. Vær alltid oppmerksom på tilstanden til arbeidsmengden din, slik at du ikke risikerer å oppleve uforutsigbar oppførsel. Denne risikoen forsterkes hvis du trenger å bruke kritisk tid på å spore uforklarte endringer når det oppstår problemer. For å minimere disse risikoene standardiserer du prosessene og verktøyene som definerer forsyningskjedet, og sikrer at arbeidsbelastningsteamet overholder dem fullt ut.

Viktige utformingsstrategier

Anbefalingene nedenfor kan hjelpe deg med å definere kjerneprinsippene i forsyningskjeden.

Gjør foreslåtte endringer i arbeidsbelastningen via forsyningskjedeprosesser og -verktøy. Ta i bruk en streng policy for automatiserte malbaserte distribusjoner. Denne metoden bidrar til å sikre at konfigurasjonen av arbeidsbelastningen din i alle miljøer er standardisert, veldefinert og kontrollert. Ikke utfør oppdateringer ved hjelp av manuelle prosesser eller menneskelig interaksjon for miljøer i en kodekampanjekjede. Innarbeid alle endringer i miljøet gjennom en pipeline ved å følge distribusjonspraksisen du definerer. For å bidra til å håndheve denne policyen bør du vurdere å begrense tilgang til skrivebeskyttet som standard og bruke en tilgangsgodkjenningsport til å tillate skrivetilgang.

En viktig del av dette prinsippet er at alle endringene er foreslåtte endringer til de er distribuert i produksjon. Ved hjelp av automatisert testing, for eksempel integrering og testing av innhold, kan du gjøre det mulig for forsyningskjeden å automatisk avvise endringer.

Bruk ett sett med koderessurser og -artefakter i alle miljøer og pipeliner. Et vanlig problemområde for organisasjoner er at ikke-produksjonsmiljøer er forskjellige fra produksjonsmiljøer. Manuell bygging av produksjons- og ikke-produksjonsmiljøer kan føre til uoverensstemmelser i konfigurasjoner mellom miljøene. Dette samsvaret reduserer testingen og gjør det mer sannsynlig at endringer kan skade et produksjonssystem.

Gjenspeil organisasjonsstrukturen i forsyningskjede- og pipelineutformingen. Organisasjonen din kan være siloinndelt mellom team. Hvert team kan administrere en del av forsyningskjeden. Mange organisasjoner har for eksempel team som administrerer sikkerhets- og samsvarsinnstillinger eller miljøkonfigurasjoner. Disse teamene er atskilt fra utviklingsteam som administrerer programutvikling, testing og distribusjoner. Det finnes mange måter å organisere teamene som er involvert i en leveringskjede. Forsyningskjeden er avhengig av at alle teamene samarbeider sømløst. Sørg for at alle team følger standardprosesser, og bruk standardverktøy for å gjøre forsyningskjeden så effektiv som mulig.

Forsyningskjeden din kan være avhengig av tredjepartsleverandører hvis du outsourcer deler av arbeidsbelastningens livssyklus. Disse leverandørene er like avgjørende for suksessen til forsyningskjeden din som interne ressurser. Sørg for at Der er gjensidig enighet på tvers av alle team om prosessene og verktøyene du bruker.

Standardisere distribusjonsmetoden. Snakk med produkteieren om akseptabel nedetid for arbeidsbelastningen din. Avhengig av hvor mye nedetid som kan godtas, kan du velge distribusjonsmetoden som passer for dine krav. Ideelt sett bør du utføre distribusjoner i løpet av et vedlikeholdsvindu for å redusere kompleksiteten og risikoen.

Planlegge en helhetlig teststrategi. Et kjerneprinsipp for systempålitelighet er "skift venstre"-prinsippet. Utvikling og distribusjon av et program er en prosess som beskrives som en serie med trinn som går fra venstre til høyre. Du bør ikke begrense testingen til slutten av prosessen. Flytt så mye som mulig av testingen til starten, eller til venstre. Det er rimeligere å reparere feil når du oppdager dem tidlig. De kan være dyre eller umulige å fikse senere i applikasjonens livssyklus.

Når det er mulig, kan du bruke automatisert testing for å sikre konsekvens. Inkluder følgende typer testing i forsyningskjedeutformingen:

• Enhetstesting: Enhetstester kjøres vanligvis som en del av en kontinuerlig integrasjonsrutine. Enhetstester bør være omfattende og raske. De skal ideelt sett dekke 100 prosent av koden. Bruk enhetstester på alle koderessurser, inkludert maler og skript.

• Røyktesting: Røyktester bekrefter at en arbeidsbelastning kan stå opp i et testmiljø og fungerer som forventet. Pretester kontrollerer ikke komponentenes interoperabilitet. Pretestene kontrollerer at distribusjonsmetodikken for infrastrukturen og programmet fungerer, og at systemet svarer slik det er planlagt etter at prosessen er fullført.

• Integrasjonstesting: Integrasjonstester sikrer at applikasjonskomponentene fungerer individuelt, og avgjør deretter om komponenter kan samhandle med hverandre som de skal. Det kan ta ganske lang tid å kjøre en stor pakke med integreringstester. Derfor er det best å innlemme shift-left-prinsippet og utføre testing tidlig i programvareutviklingens livssyklus. Reserver integreringstester til scenarioer du ikke kan teste med en pretest eller enhetstest. Du kan kjøre testprosesser som kjører lenge, med jevne mellomrom, hvis det er nødvendig. Et regelmessig intervall sikrer et godt kompromiss og registrerer problemer med interoperabilitet mellom programkomponentene senest én dag etter at de ble innført. Noen testscenarier drar nytte av manuelle kjøringer. Bruk manuell testing når du må å introdusere elementer av menneskelig interaktivitet i testene.

• Godkjenningstesting: Avhengig av konteksten kan du utføre godkjenningstesting manuelt. Den kan være helt eller delvis automatisert. Godkjenningstesting avgjør om programvaresystemet oppfyller kravspesifikasjonene. Hovedformålet med denne testen er å evaluere systemets samsvar med forretningskravene og avgjøre om systemet oppfyller de nødvendige kriteriene for levering til brukerne.

Implementer kvalitetsporter gjennom hele kodepromoteringsprosessen gjennom testing. Distribuer koden i lavere miljøer, for eksempel kvalitetssikring og testing, og opp gjennom høyere miljøer, for eksempel midlertidige miljøer og produksjon. Når distribusjonen går gjennom kvalitetsporter, må du sørge for at den oppfyller kvalitetsmålene før endringer går til produksjon. Dine forretningskrav avgjør hva fokuset for kvalitetsportene er. Vurder også de grunnleggende Power Platform velkonstruerte prinsippene: Sikkerhet, pålitelighet og ytelseseffektivitet.

Integrer også godkjenningsarbeidsflyter i kvalitetsportene. Definer klart og automatiser godkjenningsarbeidsflyter når det er behov for det. Definer kriterier for kvalitetsaksept i automatiseringen din, slik at du kan bevege deg gjennom portene dine effektivt og trygt.

Tilrettelegging for Power Platform

Pipeliner tar Power Platform sikte på å demokratisere administrasjon av programlivssyklus (ALM) for Power Platform og Dynamics 365-kunder ved å bringe ALM-automatisering og funksjoner for kontinuerlig integrasjon og kontinuerlig levering (CI/CD) inn i tjenesten.

Microsoft Power Platform Build Tools for Azure DevOps kan brukes til å automatisere vanlige kompilerings- og distribusjonsoppgaver relatert til apper bygget på Power Platform.

GitHub Actions for Power Platform gjør det mulig for utviklere å bygge automatiserte arbeidsflyter for programvareutvikling. Med GitHub-handlinger for Microsoft Power Platform kan du opprette arbeidsflyter i lageret for å bygge, teste, pakke, distribuere og distribuere apper, utføre automatisering og administrere automatiseringer og andre komponenter som er innebygd i Power Platform.

ALM Accelerator er et åpen kildekode-verktøy som består av et sett med applikasjoner, skript og pipeliner designet for å automatisere den kontinuerlige integrasjons-/kontinuerlige leveringsprosessen.

Automatiser tester med Azure Pipelines.

Power Apps checker Web API gir en mekanisme for å kjøre statiske analysekontroller mot tilpassinger og utvidelser til Microsoft Dataverse plattformen.

Microsoft Power Platform CLI (PAC CLI) er et kommandolinjeverktøy som støtter import og eksport av Power Platform løsninger, og pakking til og utpakking fra Power Platform løsningskildefiler. PAC CLI er tilgjengelig som et frittstående kommandolinjeverktøy eller som en utvidelse for Visual Studio kode.

Du kan bruke Terraform, Bicep og Azure Resource Manager for ustrukturerbar infrastruktur som kodedistribusjoner (IaC). Avhengig av kravene dine og teamets kjennskap til verktøyene, kan du bruke ett eller flere av disse verktøyene til distribusjoner og administrasjon av ressursene.

Organisasjonsjustering

Cloud Adoption Framework gir veiledning for sentrale team for å sørge for landingssoner for arbeidsbelastning. Landingssonene for arbeidsbelastninger er der arbeidsbelastningens egendefinerte forsyningskjede distribuerer programmer til.

Finn ut mer i Hva er en Azure-landingssone? og utformingsprinsippene for Azure-landingssoner.

Relatert informasjon

• Azure DevOps
• Søyle for pålitelighet
• Sikkerhet søyle

Neste trinn