Anbefalinger til design af en forsyningskæde til udvikling af arbejdsbelastning
Gælder for denne Power Platform anbefaling af Well-Architected Operational Excellence-tjekliste:
| OE:06 | Byg et værktøj til arbejdsbelastninger, der fører de foreslåede ændringer gennem forudsigelige, automatiserede pipelines. Pipelines tester og fremmer disse ændringer på tværs af miljøer. Optimer en forsyningskæde for at gøre din arbejdsbyrde pålidelig, sikker, omkostningseffektiv og effektiv. |
|---|
I denne vejledning beskrives anbefalingerne til design af en forsyningskæde til udvikling af arbejdsbelastninger, der er baseret på CI/CD-pipelines (løbende integration og løbende levering). I skybelastninger er en forsyningskæde en standardiseret pakke med værktøjer og processer, du bruger til at påvirke ændringer i konfigurationen og arbejdsbelastningen på tværs af miljøer. Udvikl et værktøj for at sikre, at du har en forudsigelig, standardiseret metode til vedligeholdelse af arbejdsbelastningen. CI/CD-pipelines er manifestationen af forsyningskæden, men du bør have en enkelt forsyningskæde. Du har muligvis flere pipelines, der følger de samme processer og bruger de samme værktøjer.
Indarbejd en forsyningskæde for at beskytte din arbejdsbelastning mod skader, der kan opstå, når du ikke administrerer ændringerne i arbejdsbelastningen korrekt. Vær altid opmærksom på din arbejdsbyrde, så du ikke risikerer at opleve uforudsigelig adfærd. Denne risiko forværres, hvis du har brug for at bruge kritisk tid på at spore uopgjorte ændringer, når der opstår problemer. Du kan minimere disse risici ved at standardisere de processer og værktøjer, der definerer forsyningskæden, og sikre, at dit arbejdsteam overholder dem fuldt ud.
Vigtigste designstrategier
Følgende anbefalinger kan hjælpe dig med at definere kerneprincipper for forsyningskæden.
Foretag foreslåede ændringer af arbejdsbelastningen ved hjælp af forsyningskædeprocesser og -værktøjer. Gennemtving en restriktiv politik for automatiserede skabelonbaserede installationer. Denne metode er med til at sikre, at konfigurationen af arbejdsbelastningen på tværs af alle miljøer er standardiseret, veldefineret og kontrolleret. I forbindelse med miljøer i en kodeoverførselskæde skal du ikke udføre opdateringer ved hjælp af manuelle processer eller menneskelig interaktion. Indarbejd alle ændringer i miljøet via en pipeline ved at følge de fremgangsmåder for installation, du definerer. Hvis du vil gennemtvinge denne politik, kan du evt. som standard begrænse adgangen til skrivebeskyttet adgang og bruge en adgangsgodkendelsesport til at tillade skriveadgang.
Et vigtigt element i dette princip er, at alle ændringer foreslåede ændringer, indtil de implementeres i produktionen. Via automatiseret test som f.eks. integration og røgtest kan du aktivere forsyningskæden til automatisk at afvise ændringer.
Brug ét sæt kodeaktiver og artefakter på tværs af alle miljøer og pipelines. En almindelig udfordring for organisationer er, når ikke-produktionsmiljøer ikke er de samme som produktionsmiljøer. Manuel udvikling af produktionsmiljøer og ikke-produktionsmiljøer kan resultere i uoverensstemmelser i konfigurationer mellem miljøer. Denne uoverensstemmelse sinker testen og gør det mere sandsynligt, at ændringer kan skade et produktionssystem.
Sørg for, at din organisationsstruktur afspejles i din forsyningskæde og dine pipelinedesign. Din organisation er muligvis siloopdelt mellem teams. De enkelte teams administrerer måske en del af forsyningskæden. Mange organisationer har f.eks. teams, der administrerer indstillinger for sikkerhed og overholdelse af standarder eller miljøkonfigurationer. Disse teams er ikke de samme som udviklingsteams, der administrerer programudvikling, test og installationer. Du kan organisere de teams, der er involveret i forsyningskæden, på mange måder. Din forsyningskæde er afhængig af, at teams kan arbejde problemfrit sammen. Sørg for, at alle teams følger standardprocesserne og bruger standardværktøjer for at gøre forsyningskæden så effektiv som muligt.
Din forsyningskæde kan være afhængig af tredjepartsleverandører, hvis du outsourcer dele af arbejdsbelastningens livscyklus. Disse leverandører er lige så afgørende for din forsyningskædes succes som interne ressourcer. Sørg for, at der er gensidig enighed på tværs af alle teams om de processer og værktøjer, du bruger.
Standardiser installationsmetoden. Tal med produktejeren om den acceptable nedetid i produktionen for arbejdsbelastningen. Afhængigt af, hvor meget nedetid der kan accepteres, kan du vælge den installationsmetode, der passer til dine behov. Det ideelle er at udføre installationer i vedligeholdelsesvindue for at reducere kompleksiteten og risikoen.
Planlæg en holistisk teststrategi. Et centralt princip for systempålidelighed er "skift til venstre"-princippet. Udvikling og installation af et program er en proces, der er beskrevet som en række trin, der udføres fra venstre mod højre. Du bør ikke begrænse testen til slutningen af processen. Skift testen til starten eller til venstre så meget, du kan. Det er billigere at reparere fejl, når de opdages tidligt. De kan være dyre eller umulige at rette senere i applikationens livscyklus.
Hvis det er muligt, bør du bruge automatiseret test for at sikre ensartethed. Medtag følgende typer test i dit design af forsyningskæder:
Enhedstest: Enhedstest køres typisk som en del af en kontinuerlig integrationsrutine. Enhedstest skal være omfattende og hurtige. De skal helst dække 100 procent af koden. Anvend enhedstest på alle kodeaktiver, herunder skabeloner og scripts.
Røgtest: Røgtest verificerer, at en arbejdsbyrde kan stå op i et testmiljø og fungerer som forventet. Røgtest viser ikke komponenternes interoperabilitet. Røgtest kontrollerer, at installationsmetoden for infrastrukturen og programmet fungerer, og at systemet svarer som ønsket, når processen er fuldført.
Integrationstest: Integrationstest sikrer, at applikationskomponenterne fungerer individuelt, og bestemmer derefter, om komponenterne kan interagere med hinanden, som de skal. Det kan tage lang tid at køre en stor pakke med integrationstest. Derfor er det bedst at inkorporere shift-left-princippet og udføre test tidligt i softwareudviklingens livscyklus. Reservér integrationstest for scenarier, du ikke kan teste med en røgtest eller en enhedstest. Du kan køre langvarige testprocesser jævnligt efter behov. Et jævnligt interval sikrer et godt kompromis og registrerer interoperabilitetsproblemer mellem programkomponenterne senest én dag efter, at de er introduceret. I visse testscenarier er det en fordel at udføre manuelle kørsler. Brug manuelle test, når du skal introducere elementer af menneskelig interaktivitet i testene.
Accepttest: Afhængigt af konteksten kan du udføre accepttest manuelt. De kan være delvist eller fuldt automatiseret. Accepttesten bestemmer, om softwaresystemet overholder kravspecifikationerne. Hovedformålet med denne test er at evaluere systemets overholdelse af forretningskravene og afgøre, om systemet opfylder de krævede kriterier for levering til brugerne.
Implementer kvalitetsporte i hele din kodepromoveringsproces gennem test. Installér koden i mindre vigtige miljøer, f.eks. kvalitetssikring og test, og op i mere vigtige miljøer, f.eks. midlertidigt miljø og produktion. Efterhånden som installationen går gennem kvalitetsporte, skal du sikre, at den lever op til dine kvalitetsmål, før ændringerne går i produktion. Dine virksomhedskrav bestemmer, hvad der skal have fokus i dine kvalitetsporte. Overvej også de grundlæggende Power Platform veldesignede principper: Sikkerhed, pålidelighed og ydeevneeffektivitet.
Integrer også godkendelsesarbejdsprocesser i dine kvalitetsporte. Definer klart og automatiser godkendelsesarbejdsprocesser, når det er relevant. Definer kriterier for kvalitetsaccept i din automatisering, så du kan bevæge dig effektivt og sikkert gennem dine porte.
Power Platform-processtyring
Pipelines har Power Platform til formål at demokratisere administration af programlivscyklus (ALM) for Power Platform og Dynamics 365-kunder ved at bringe ALM-automatisering og funktioner til kontinuerlig integration og kontinuerlig levering (CI/CD) ind i tjenesten.
Microsoft Power Platform Build Tools til Azure DevOps kan bruges til at automatisere almindelige build- og udrulningsopgaver, der er relateret til apps, der er bygget på Power Platform.
GitHub Actions til Power Platform gør det muligt for udviklere at bygge automatiserede arbejdsgange for softwareudvikling. Med GitHub-handlinger for Microsoft Power Platform kan du oprette arbejdsprocesser i dit lager for at bygge, teste, pakke, frigive og installere apps, udføre automatisering og administrere bots og andre komponenter, der er bygget på Power Platform.
ALM Accelerator er et open source-værktøj, der består af et sæt applikationer, scripts og pipelines designet til at automatisere den kontinuerlige integrations-/kontinuerlige leveringsproces.
Automatiser test med Azure Pipelines.
Power Apps checker Web API indeholder en mekanisme til at køre statiske analysekontroller i forhold til tilpasninger og udvidelser til platformen Microsoft Dataverse .
Microsoft Power Platform CLI (PAC CLI) er et kommandolinjeværktøj, der understøtter import og eksport af Power Platform løsninger samt pakning til og udpakning fra Power Platform løsningskildefiler. PAC CLI er tilgængelig som et selvstændigt kommandolinjeværktøj eller som en udvidelse til Visual Studio Code.
Du kan bruge Terraform, Bicep og Azure Resource Manager til installation af infrastruktur som kode (IaC), der ikke kan ændres. Afhængigt af dine krav og teamets kendskab til værktøjerne kan du bruge et eller flere af disse værktøjer til installation og administration af dine ressourcer.
Organisatorisk justering
Cloud Adoption Framework indeholder en vejledning til centrale team i at levere landingszoner for arbejdsbelastning. Landingszonerne for arbejdsbelastninger er det sted, hvor arbejdsbelastningens brugerdefinerede forsyningskæde udruller programmer til.
Få mere at vide i Hvad er en Azure-landingszone? og designprincipperne for Azure-landingszoner.