Implementer en skalerbar ALM-tilnærming ved hjelp av Microsoft Package Deployer

Etter hvert som Power Platform- og Dynamics 365-implementeringer vokser i størrelse og kompleksitet, trenger organisasjoner en strategi for programlivssyklushåndtering (ALM) som støtter flere utviklere, kontrollerte utgivelser, distribusjonsautomatisering og styring på tvers av miljøer.

Denne referansearkitekturen kombinerer Microsoft Package Deployer, Git, Azure DevOps og Power Platform CLI for skalerbar ALM. Den integrerer kildekontroll, fagfellevurdering, automatiserte utrullinger, håndtering av hurtigreparasjoner og sporbarhet for utrulling.

Tip

Denne artikkelen inneholder et eksempelscenario og en generalisert referansearkitektur. Tilnærmingen kan tilpasses organisasjoner av forskjellige størrelser og på tvers av mange bransjer for å støtte skalerbar utvikling, distribusjon og praksis for releasehåndtering.

Arkitekturdiagram

Diagram over en datavers ALM-arbeidsflyt ved hjelp av Visual Studio Code, Azure Pipelines, Package Deployer og trinnvise miljøer.

Workflow

Følgende arbeidsflyt tilsvarer fasene som er illustrert i arkitekturdiagrammet.

Trinn 1: Opprett og send inn endringer

Utviklere bruker Visual Studio Code, sammen med Power Platform CLI, til å klargjøre endringer for fagfellevurdering.

  1. Utviklere bruker Visual Studio Code til å administrere miljøtilkoblinger gjennom utvidelsen Power Platform Tools Visual Studio Code. Utvidelsen gir funksjonalitet til å administrere autentiseringsprofiler som lagrer utviklernes tilkoblinger til miljøer på tvers av ulike tenants.

  2. Utviklere oppretter grener i Visual Studio Code for sitt individuelle arbeid.

  3. Utviklere trekker ut løsninger fra Dataverse og angir løsningsversjoner ved hjelp av Power Platform CLI-oppgaver som er definert i Visual Studio Code. Prosessen omfatter utpakking av løsning .zip filer og plassering av de utpakkede filene i dedikerte mapper.

  4. Utviklere velger deretter ("cherry-pick") endringene som er knyttet til deres fullførte arbeid, og bidrar til å sikre at ufullstendige endringer fra andre utviklere i det delte utviklingsmiljøet ikke blir committed.

  5. Utviklere pusher deretter sine cherry-pickede endringer til Git som pull requests for fagfellevurdering.

Trinn 2: Bygg og valider distribusjonspakker

Git-repositorier, Package Deployer og Azure Pipelines brukes til å bygge og distribuere pakker.

  1. Git-repositorier

    1. Repositoriene inneholder de kildestyrte komponentene fra Dataverse.

    2. Cherry-pickede endringer fra forrige fase slås sammen til versjonskontroll først etter at en pull request er godkjent. For å sikre sporbarhet kan du koble alle relevante backlog-arbeidselementer som er knyttet til endringene, til pull requesten.

    Arbeidselementer som er koblet til pull-forespørsler, har en logg over pipelinekjøringer og klassiske utgivelser som inneholder endringene som dekkes av arbeidselementet. Se gjennom denne historikken i arbeidselementet for å spore hvor endringene er distribuert.

  2. Pakkedistribuering

    1. Microsoft Package Deployer oppretter pakker som inneholder løsningene og dataene som kreves for utrulling til nedstrøms miljøer, for eksempel testing og produksjon. Det støtter også utvidbare funksjoner gjennom C#-kode for å utføre ekstra logikk før, under eller etter distribusjon.

    2. Plasser Package Deployer-prosjektet i samme repositorium som de utpakkede løsningene. Den inneholder følgende mapper og filer:

    • PkgAssets inneholder alle løsnings-.zip- og datafiler som skal distribueres som en del av pakken.

    • ImportConfig.xml definerer rekkefølgen løsningene distribueres i. Denne filen inneholder også utrullingsinnstillingene for hver løsning, for eksempel om uadministrerte tilpasninger overskrives under distribusjon.

  3. Bygg pipeline

    Azure Pipelines bygger Package Deployer-løsningen:

    1. Pipelinen pakker løsningskomponentene i kildekontrollen inn i .zip filer og plasserer dem i PkgAssets-mappen.

    2. Pipeline committer deretter det oppdaterte biblioteket for dynamiske koblinger for pakker (DLL) til versjonskontroll.

  4. Utrullingspipeline

    1. build-pipelinen utløser denne Azure Pipelines når den er fullført.

    2. Utrullingspipelinen er en flertrinnspipeline:

      1. Første fase: Bygg den distribuerbare pipeline-artefakten som inneholder pakken fra Package Deployer-prosjektet.

      2. Andre trinn: Distribuer pakken fra artefakten til et CI-miljø (kontinuerlig integrasjon).

        1. CI-miljøet er dedikert til utrullingsvalidering. Du kan ikke logge på dette miljøet. Hvis en utrulling mislykkes, kan team løse problemer før utrullingen påvirker andre test-, integrerings- eller produksjonsmiljøer.

        2. Distribuer til QA-miljøer (kvalitetssikring), MIG (migrering) og INT (integrering) parallelt eller sekvensielt. Antall distribusjonsfaser avhenger av miljøene som er i bruk og distribusjonsflyten.

Trinn 3: Godkjenn og publiser

Dette stadiet støtter kontinuerlig leveranse gjennom kontrollerte releaser.

  1. Klassiske versjoner bruker artefaktene som ble produsert av den forrige pipelinen, og kan konfigureres til å kreve autorisasjon før distribusjon. Bruk dem for de mest kontrollerte miljøene, for eksempel UAT og produksjon.

    Bruk godkjenningskontroller før distribusjon når du distribuerer til produksjonsmiljøer for å sikre at utrullinger er riktig autorisert. For å forhindre utilsiktede produksjonsdistribusjoner må du kreve godkjenning fra et forhåndsdefinert antall brukere og autentisere på nytt før distribusjonen kan fortsette.

  2. I dette scenarioet kan du bruke godkjenningsporter før distribusjon for CD (kontinuerlig levering) for å sikre at bare fullstendig utviklede og testede funksjoner distribueres gjennom trinnvis utrulling med godkjenningsporter. Den forrige fasen støtter CI/CD (kontinuerlig integrasjon og kontinuerlig utrulling), der endringer automatisk fremmes gjennom miljøene.

Trinn 4: Distribuer og synkroniser hurtigrettinger

Dette trinnet støtter hotfix-distribusjoner til produksjons- og utviklingsmiljøer.

En utvikler utløser dette Azure Pipeline manuelt og oppgir det logiske navnet på patchløsningen. Pipeline:

  1. Trekker ut patchen som både uadministrert og administrert fra et hurtigfiksingsmiljø.

  2. Utruller den administrerte patchen til produksjonsmiljøet.

  3. Distribuerer den uadministrerte patchen til utviklingsmiljøet.

    1. Kjører et PowerShell-skript som bruker Dataverse-handlingen AddSolutionComponent og slår sammen oppdateringspakke-komponenter til den overordnede løsningen. Som det siste trinnet sletter skriptet patchen fra utviklingsmiljøet.

    2. Neste gang løsningene trekkes ut, sendes rettingen til kildekontroll gjennom hovedprosessen, da den nå er en del av hovedløsningsstrukturen som distribueres. Denne prosessen skjer også ved planlagt sikkerhetskopiering. Du kan kjøre denne pipelinen ved behov, slik at teamene ikke trenger å vente på timeren.

    3. Når løsningene distribueres til produksjon med en høyere versjon enn patchene, fjerner oppgraderingen patchene.

Trinn 5: Sikkerhetskopiere utviklingsløsninger

Dette Azure Pipeline kjører på en tidsplan for å sikkerhetskopiere utviklingsløsninger til et eget Git-repositorium.

Pipeline:

  1. Trekker ut både uadministrerte og administrerte løsninger.

  2. Pakker ut løsningene.

  3. Bekrefter endringer i sikkerhetskopirepositoriene.

  4. Holder hovedrepositoriet oppdatert med ferdige funksjoner som teamet committer, mens sikkerhetskopirepositoriet inneholder den nyeste versjonen på tidspunktet for den planlagte kjøringen. Denne fremgangsmåten gir deg mer kontroll over utrullingen til hovedlinjen.

Komponenter

Denne referansearkitekturen bruker følgende komponenter:

  • Visual Studio Code for:

    • Lokal avdelingsledelse.
    • Godkjenningsprofilbehandling med Power Platform Extension.
    • Løsningsuthenting med Power Platform CLI.
    • Selektiv inkludering av endringer i Git-commits.

  • Git-repositorier for:

    • Versjonskontroll.
    • Fagfellevurdering av pull requests.

  • Azure Boards for:

    • Backlog management.
    • Sporbarhet for arbeidselementer og utgivelsers utrullingspipeline.

  • Azure DevOps pipelines for å implementere CI/CD for distribusjon av løsningen.

  • Azure-releaser for kontrollert distribusjon av testede artefakter til de øverste miljøene.

Scenariodetaljer

Denne løsningen kombinerer Azure DevOps pipeliner og Git-basert administrasjon av repositorium med Power Platform og Dynamics 365 implementeringer. Resultatet er en skalerbar ALM-tilnærming som støtter team med flere utviklere, distribusjoner på tvers av flere miljøer og fagfellevurderinger. Den skaleres med størrelsen på implementeringen og antall Dataverse-løsninger samtidig som den tar for seg styring, endringssporing og parallell utvikling.

Du kan bruke denne fremgangsmåten på mange bransjer med komplekse, store Power Platform og Dynamics 365 løsninger som bruker Dataverse. Eksempler er detaljhandel, finans, produksjon, helsetjenester, offentlig sektor, energi, telekommunikasjon, utdanning, bilindustrien, ideelle organisasjoner, spill, media og underholdning, reiseliv og hotell- og serveringsbransjen, fasiliteter og fast eiendom, luftfart, landbruk og sport. Bruk denne fremgangsmåten til å etablere en distribusjons- og gjennomgangsprosess som skalerer i takt med utviklingsteamet og arbeidsbelastningen.

Denne tilnærmingen fokuserer på endringskontroll gjennom Git-forgrenings- og fagfellevurderingsfaser for Dynamics 365 og Dataverse, fra tilpasninger til kodebasert utvikling. Den gir mulighet for parametrisering av data i én enkelt pakke som inneholder Dataverse-løsninger, noe som gir teamene mulighet til å tilpasse distribusjonstilnærmingen gjennom utvidbar kode i pakken, for eksempel før distribusjon eller aktiviteter etter distribusjon.

Vurder denne tilnærmingen når du definerer en miljøstrategi i kartleggingsfasen av et prosjekt.

Denne løsningen er mest aktuell for:

  • Store Dataverse implementeringer med flere utviklere på tvers av ulike bransjer.
  • Organisasjoner som krever sterk endringskontroll, sporbarhet og støtte for parallell utvikling.

Primærinteressenter inkluderer:

  • IT-team
  • Tekniske team
  • Prosjektledere

Du kan bruke denne løsningen til å:

  • Unngå å distribuere uferdige funksjoner.
  • Legge til rette for parallell utvikling.
  • Forbedre sporbarheten for endringer.
  • Implementer en prosess for fagfellevurdering før distribusjon.
  • Behold én enkelt jobb ved å administrere én enkelt distribuerbar pakke.
  • Lagre artefakter med mer detaljerte endringer og distribuer dem ofte for å redusere risikoen for distribusjonsfeil.

Vurderinger

Disse hensynene tar i bruk prinsippene i Power Platform Well-Architected, et sett med veiledende prinsipper som forbedrer kvaliteten på en arbeidsbelastning. Finn ut mer i Microsoft Power Platform Well-Architected.

Reliability

Denne arkitekturen muliggjør forutsigbare distribusjoner, støtter kontrollerte utgivelser og reduserer nedetid ved å flytte risikoen til tidligere automatiserte faser.

  • Flertrinnspipelines: Reduser distribusjonsrisikoen ved å validere i hvert trinn.

  • Dedikert CI-miljø: Sørg for tidlig feilgjenkjenning uten å påvirke andre miljøer.

  • Pakkedistribusjon: Garanterer konsekvent distribusjon og løsningsrekkefølge gjennom ImportConfig.xml.

  • hurtigfiks-pipeline: Gi en strukturert prosess for å bruke hurtigfikser på både produksjons- og utviklingsmiljøer.

  • Sikkerhetskopieringspipeline: Oppretthold planlagte øyeblikksbilder av DEV-løsninger for å sikre gjenopprettingsmuligheter.

Security

Fremtving sterk atskillelse av oppgaver, reviderte godkjenninger og sikre automatiserte interaksjoner, noe som reduserer risikoen for uautoriserte eller utilsiktede utrullinger.

  • Tjenestetilkoblinger med tjenestehovedobjekter: Beskytt med rollebasert tilgangskontroll og med kontrollert sikkerhet i Dataverse.

  • Autentiseringsport: Tving reautentisering og godkjenninger før distribusjoner til produksjon.

  • Retningslinjer for grener: Krev fagfellevurdering før du fletter endringer inn i beskyttede grener.

  • ADO-tillatelser: Begrense tilgang til pipelines og releaser til autoriserte brukere.

Driftskvalitet

Støtter optimaliserte operasjoner gjennom automatiserte rørledninger, sporbare endringer og styringsvennlige prosesser som skaleres med team- og løsningskompleksitet.

  • Azure Boards integrasjon: Gir full sporbarhet fra arbeidsoppgave til pull request, bygg og utgivelse.

  • Strategi for fagfellevurdering og branchestrategi: Forbedrer kodekvaliteten og reduserer regresjonsrisikoen.

  • Trinnvis distribusjon med godkjenningsporter: Sikrer kontrollert distribusjon av nye funksjoner.

  • Automatisering for sikkerhetskopier, hurtigrettinger og utrullinger til hovedgren: Reduserer manuelle feil og forbedrer konsekvens.

Ytelseseffektivitet

Leverer oppdateringer raskere, behandler høyere mengder endringer og skalerer effektivt utviklings- og distribusjonskapasiteten på tvers av flere miljøer.

  • Parallelle utrullinger: Øker utrullingsgjennomstrømmingen og reduserer ventetiden.

  • Power Platform CLI og cherry-picking av endringer: Optimaliserer løsningsekstrahering og kontroll over innsjekkede endringer.

  • Dedikerte YAML-maler for pipeline: Støtter gjenbruk og reduserer administrasjon.

  • CI-miljø: Akselererer valideringer uavhengig av menneskelige kontroller.

Opplevelsesoptimalisering

Teams har en mer strømlinjeformet, gjennomsiktig og konsekvent opplevelse gjennom utviklings- og distribusjonssykluser.

  • Visual Studio Code og Power Platform Tools Visual Studio Code utvidelse: Bruk moderne verktøy og gi mulighet for en sømløs opplevelse mellom IDE og Dataverse.

  • Pull request: Forbedre samarbeid og kunnskapsdeling.

  • Utvidbarhet for Package Deployer (før- eller ettertrinn): Legg til ekstra distribusjonstrinn, for eksempel dataimport, oppdatering av poster og distribusjonsvalidering.

  • arbeidselement koblet til utrullingslogg: Gir en fortelling om endringer.

Neste trinn

Når du har implementert ALM-tilnærmingen, kan du konfigurere en strukturert prosess for å generere versjonsmerknader som tydelig kommuniserer endringer og oppdateringer.

Du kan for eksempel bruke:

  • Skripting for å lese koblede arbeidselementer og bygge et sammendrag.
  • En Microsoft Copilot Studio-agent for å hente detaljer fra Azure DevOps API-en gjennom en MCP-server (Model Context Protocol) og automatisk generere versjonsmerknader.

Bidragsytere

Microsoft vedlikeholder denne artikkelen. Følgende bidragsytere skrev denne artikkelen.

Hovedforfattere:

  • Sist oppdatert