Velg det beste alternativet for fabric CI/CD-arbeidsflyt for deg

Denne artikkelen presenterer Fabric-utviklere ulike alternativer for å bygge CI/CD-prosesser i Fabric, basert på vanlige kundescenarier. Denne artikkelen fokuserer mer på kontinuerlig distribusjon (CD) av CI/CD-prosessen. For en diskusjon om kontinuerlig integrasjon (CI), se Utviklingsprosess i Microsoft Fabric.

Selv om denne artikkelen beskriver flere forskjellige alternativer, tar mange organisasjoner en hybrid tilnærming.

Forutsetning

For å bygge en CI/CD-prosess ved å bruke alternativene i denne artikkelen, trenger du:

• Et Microsoft Fabric-abonnement

• Et Fabric-arbeidsområde (du må være arbeidsområde-administrator for å konfigurere distribusjon)

• For Git-baserte alternativer (1, 2 og 4) er en støttet Git-leverandør (Azure DevOps eller GitHub) koblet til via Git-integrasjon

Utviklingsprosess

Utviklingsprosessen er den samme i alle distribusjonsscenarioer, og er uavhengig av hvordan du lanserer nye oppdateringer i produksjon. Når utviklere arbeider med kildekontroll, må de arbeide i et isolert miljø. I Fabric kan dette miljøet enten være en IDE på den lokale maskinen (for eksempel Power BI Desktop eller VS Code), eller et annet arbeidsområde i Fabric. Du kan finne informasjon om de ulike hensynene for utviklingsprosessen i utviklingsprosessen i Microsoft Fabric.

Git-synkronisering støtter både å committe arbeidsområdeendringer i Git og oppdatere et arbeidsområde fra Git. PR-pilen viser retningen du slår sammen funksjonsendringer i den delte utviklingsgrenen, ikke en toveis synkroniseringsoperasjon.

Frigivelsesprosess

Lanseringsprosessen starter når nye oppdateringer er fullført, og pull-forespørselen (PR) flettes inn i teamets delte gren (for eksempel Main, Dev osv.). Fra dette punktet finnes det ulike alternativer for å bygge en utgivelsesprosess i Fabric.

Tabellen nedenfor oppsummerer alternativene som kan hjelpe deg å velge. Mange lag kombinerer mer enn ett.

¹ I alternativ 2 er det kun Dev-arbeidsområdet som er koblet til Git. Test- og produksjonsarbeidsområdene er ikke koblet til Git. Å pushe en release-tag på Main utløser en pipeline som distribuerer den versjonen til Test. Etter vellykket validering og godkjenning distribuerer pipelinen samme tag og commit SHA til Prod.

Disse alternativene krever ikke en spesifikk forgreningsstrategi, som Gitflow eller trunk-basert utvikling. Det som betyr noe er at hvert trinn distribuerer en kjent, versjonert commit, og at Prod mottar det samme innholdet som du testet.

Alternativ 1 og 2 varierer i hvordan du organiserer og promoterer utgivelser, ikke i et eksklusivt valg av verktøy. Begge alternativene kan bruke fabric-cicd eller Fabric Items API-er og miljøspesifikk parameterisering. Alternativ 1 fremmer endringer gjennom separate stage-grener. Alternativ 2 bruker en release-tag på Main for å utløse distribusjon av samme commit til Test og, etter validering og godkjenning, til Prod.

En distribusjonsplan er ikke et separat arbeidsflytalternativ. Du kan bruke en plan med støttede Git-operasjoner i alternativ 1, med distribusjonspipelines i alternativ 3, eller ved å kalle Bulk Import Item Definitions API direkte i valg 1, 2 og 4. Biblioteket fabric-cicd støtter ikke distribusjonsplaner, inkludert når du bruker bulkimportmodus. Planen styrer distribusjonsrekkefølge, avhengigheter og handlinger, mens den valgte arbeidsflyten fortsetter å definere kilden til sannheten, hva hvert trinn deployerer, og fasekonfigurasjon.

Alternativ 1 - Definisjonsbaserte distribusjoner fra per-trinns Git-grener

Med dette alternativet starter alle distribusjoner fra Git. Hvert trinn har en dedikert primær gren: Dev, Test og Prod i dette eksempelet. PR-er fremmer endringer mellom disse avdelingene, og hvert arbeidsområde mottar definisjonene fra sin trinns gren. Du kan distribuere med Git-integrasjon, fabric-cicd eller Fabric Items API-er. Når du bruker fabric-cicd eller Items API-er, trenger ikke målarbeidsområdet en Git-tilkobling. Den definerende egenskapen er den separate grenen for hvert trinn, ikke distribusjonsverktøyet.

Når en PR til Utvikling-grenen er godkjent og slått sammen:

1. Oppdater Dev-arbeidsområdet fra Dev-grenen , for eksempel med Git-integrasjon. Kjør enhetstester og eventuelle nødvendige operasjoner etter utplassering.
2. Lag en PR til testavdelingen med endringene du ønsker å promotere. Du kan bruke en release-gren for å plukke ut disse endringene. Bruk teamets gjennomgangs- og godkjenningsprosesser.
3. Distribuer en spesifikk commit fra Test-grenen til Test-arbeidsområdet ved å bruke Git-integrasjon, fabric-cicd eller Fabric Items API-er. Bruk trinn-spesifikk konfigurasjon og kjør automatiserte eller manuelle tester.
4. Opprett en PR til produksjonsavdelingen som promoterer de validerte endringene. Gå gjennom de resulterende definisjonene for å sikre at de samsvarer med den testede utgivelsen, bortsett fra intensjonell fase-spesifikk konfigurasjon. Hvis du legger til andre endringer, valider dem i Test før forfremmelse.
5. Etter godkjenning distribuerer du Prod-grenen til produksjonsarbeidsområdet ved å bruke det valgte distribusjonsverktøyet. Kjør nødvendige kontroller etter utrulling og datainntaksoperasjoner.

Noen vareavhengigheter bindes automatisk gjennom logiske ID-er. Andre trenger parameterisering eller oppdateringer etter utrulling. For detaljer, se Forstå avhengighetsbinding i utrulling på tvers av arbeidsområder.

Hvilke komponenter kan brukes til å implementere alternativ #1?

• Git-integrasjon: Koble hvert arbeidsområde til sin stage-gren. Oppdater det via Fabric UI eller automatiser oppdateringer med Fabric Git-API-ene.
• fabric-cicd: Sjekk ut stage-grenen og publiser produktdefinisjonene med miljøspesifikke parametere. Målarbeidsområdet trenger ikke en Git-tilkobling.
• Fabric Items API-er: Distribuer definisjoner fra trinnets gren ved å kalle Create item og Update item definition, eller Bulk Import Item Definitions API. Når du kaller API-er direkte, forbereder automatiseringen definisjonene og den trinnspesifikke konfigurasjonen.

For implementeringseksempler, se fabric-cicd og Azure DevOps-veiledningen eller Fabric CI/CD med Bulk Import Item Definitions API.

Når bør du vurdere å bruke alternativ #1?

• Når du vil bruke Git-repositoriet som den eneste kilden til sannheten, og opprinnelsen til alle distribusjoner.
• Når du ønsker en egen primær avdeling for hvert trinn, med PR-basert gjennomgang og forfremmelse mellom stadiene.
• Når du vil administrere nivåspesifikke definisjoner i Git, eller anvende miljøspesifikk konfigurasjon med det valgte distribusjonsverktøyet du har valgt.

Alternativ 2 – Definisjonsbaserte distribusjoner fra en delt release-commit

Med dette alternativet jobber utviklerne på en Dev-gren som er koblet til Dev-arbeidsområdet. Hovedgrenen er release-grenen: den inneholder kun de endringene du velger å slippe. Test- og produksjonsarbeidsområdene er ikke koblet til Git. Å pushe en release-tagg på Main utløser en GitHub Actions-arbeidsflyt eller Azure DevOps-pipeline. Den distribuerer den merkede versjonen til Test, kjører validering, og venter på produksjonsgodkjenning før den samme taggen distribueres og commiter SHA til produksjon. Pipelinen kan bruke et byggemiljø for å kjøre enhetstester og justere varedefinisjoner før de lastes opp. For eksempel kan du endre datakildetilkoblinger, referanser til andre elementer, eller parameterverdier for måltrinnet. Ikke alle gjenstandsavhengigheter krever disse endringene. Noen binder automatisk gjennom logiske ID-er når de distribueres til et nytt arbeidsområde. For detaljer, se Forstå avhengighetsbinding i utrulling på tvers av arbeidsområder.

Utløsningsflyten fungerer som følger:

1. Utviklere slår sammen godkjente PR-er med Dev-grenen, og Dev-arbeidsområdet oppdateres fra Git.
2. For å forberede en utgivelse, lag en PR som plukker ut endringene du vil slippe fra Dev til Main. PR-en bør inkludere de samme gjennomgangs- og godkjenningsprosessene som enhver annen PR i teamet eller organisasjonen din.
3. Lag en release-tagg på den valgte commit på Main, for eksempel v1.5.0. Press taggen for å utløse en GitHub Actions-arbeidsflyt eller Azure DevOps-pipeline konfigurert for release-tagger.
4. Pipelinen løser taggen til en commit SHA, registrerer begge, sjekker ut commiten, kjører enhetstester og justerer konfigurasjonen for testen. Den laster opp disse varedefinisjonene til testarbeidsområdet ved å bruke fabric-cicd eller Bulk Import Item Definitions API. For detaljer, se Hvilke komponenter kan brukes til å implementere alternativ #2?. Kjør automatiserte eller manuelle tester etter utrulling. Hvis valideringen feiler, stopp opprykk til produksjon.
5. Etter at valideringen lykkes, venter pipelinen ved en konfigurert produksjonsgodkjenningsgate. Bruk en GitHub-miljøgodkjenning eller en Azure DevOps-miljøgodkjenningssjekk.
6. Etter godkjenning, distribuer samme release-tag og registrert commit SHA til Prod. Kun per trinn-konfigurasjon, som verdisett i variabelbibliotek eller parameterfiler, skiller seg fra Test. Kjør produksjonsspesifikke sjekker og utløs eventuell datainnsamling som endringen krever for å minimere utilgjengelighet for forbrukere.

Hvis valideringen feiler, gjør løsningen i Dev først, og plukk den deretter ut i Main. Lag en ny release-tagg og gjenta pipelinen, inkludert testvalidering. Denne tilnærmingen sikrer også at fremtidige utgivelser fra Dev inkluderer rettelsen.

For sporbarhet, konfigurer distribusjonsjobber til å rette seg mot de tilsvarende GitHub- eller Azure DevOps-miljøene. Inkluder release-taggen og resolved commit SHA i hver distribusjonspost slik at du kan identifisere hvilken versjon som nådde Test og Prod. En Git-tag alene registrerer ikke hvor en versjon ble distribuert.

Hvilke komponenter kan brukes til å implementere alternativ #2?

• Fabric-cicd – et Python-bibliotek designet for bruk med Microsoft Fabric-arbeidsområder. Dette biblioteket støtter kode-først Continuous Integration / Continuous Deployment (CI/CD)-automatiseringer for sømløst å integrere arbeidsområder i et distribusjonsrammeverk. For et komplett ende-til-ende-eksempel, følg vår tutorial for fabric-cicd og Azure DevOps. Fabric-CICD støtter to publiseringsmoduser:
  • Item definition APIs (standard): Publiserer elementer ett om gangen ved å bruke Fabric Create item og Update item definition API-ene.
  • Bulk import (eksperimentell): Publiserer alle elementer i ett enkelt kall ved å bruke Bulk Import Item Definitions API. For å bruke denne modusen, aktiver enable_experimental_features og enable_bulk_publish funksjonsflaggene. For mer informasjon, se fabric-cicd bulk publish.
• Bulk-Import-Item-Definitions-API - API-et støtter både å lage nye elementer og oppdatere eksisterende elementer, samtidig som det er avhengig av Fabrics innebygde avhengighetshåndtering for å sikre at elementene distribueres i riktig rekkefølge. Dette muliggjør konsistente, repeterbare utrullinger i test- og produksjonsmiljøer uten manuell inngripen. For et eksempel på en veiledning, følg vårt Fabric CI/CD med Bulk Import Item Definitions API.

Når bør du vurdere å bruke alternativ nr. 2?

• Når du trenger miljøspesifikk parameterisering av varedefinisjoner før utrulling. Fabric-cicd-parameteriseringsfunksjonen bruker en parameter.yml fil for å erstatte verdier for hvert målmiljø, inkludert tilkoblings-ID-er og lakehouse-IDer, uten å opprettholde separate varedefinisjoner for hvert trinn. Den støtter søk-og-erstatt-operasjoner, erstatning av verdier valgt av JSON-stier, og dynamisk oppløsning av mål-arbeidsområde-objekt-IDer. Denne funksjonen er også tilgjengelig i alternativ 1 når du bruker fabric-cicd. Git-integrasjon alene gir ikke denne utrullingstiden.
• Når du vil bruke Git som en enkelt kilde til sannhet, og opprinnelsen til alle distribusjoner.
• Når du vil velge hvilke endringer som skal inn i hver utgivelse, og distribuere en tagget, testet versjon til Prod.

Alternativ 3 – Distribuer ved hjelp av datasamlebånd for stoffdistribusjon

Med dette alternativet er Git bare koblet til til utviklingsnivå. Fra utvikling-fasen skjer distribusjoner direkte mellom arbeidsområdene i Utvikling/Test/Prod, ved hjelp av utrullingssamlebånd for stoff. Du kan distribuere mellom trinnene direkte fra Fabric UI, eller bruke distribusjonspipeline-API-ene for å orkestrere distribusjonen som en del av Azure-release-pipelinen din, eller en GitHub-arbeidsflyt. Disse API-ene gjør det mulig for teamet å bygge en lignende bygg - og utgivelsesprosess som i andre alternativer, ved hjelp av automatiserte tester (som kan gjøres i selve arbeidsområdet, eller før utvikling ), godkjenninger osv.

Når utrullingen krever en spesifikk rekkefølge, relaterte elementer eller handlinger, kan du legge ved en utplasseringsplan til en utplassering mellom stadier. Distribusjonsregler og autobinding fortsetter å administrere fase-spesifikk konfigurasjon.

Når du godkjenner og slår sammen en PR til grenen som er koblet til Dev-arbeidsområdet:

1. Oppdater Dev-arbeidsområdet fra Git ved å bruke Fabric UI eller Fabric Git API-ene. Kjør nødvendige operasjoner og tester etter oppdateringen.
2. Distribuer endringene fra Dev til Test ved å bruke Fabric-distribusjonspipelines, enten fra Fabric-grensesnittet eller gjennom distribusjonspipeline-API-ene. Kjør automatiserte eller manuelle tester i Test før du promoterer endringene til Prod.
3. Etter at testene er bestått og release manager godkjenner, distribuer det validerte innholdet fra Test til Prod. Ikke oppdater det valgte innholdet i Test mellom validering og distribusjon til Prod uten å teste det på nytt.

Du kan utføre disse stegene fra Fabric UI eller automatisere dem med API-er i Azure Pipelines eller GitHub Actions. Du trenger ikke eksterne bygge- og release-pipelines for den UI-baserte arbeidsflyten.

Når bør du vurdere å bruke alternativ nr. 3?

• Når teamet ditt foretrekker Fabric sin innebygde implementeringsopplevelse og dets kapasiteter møter dine utrullingsbehov. Du kan distribuere mellom arbeidsområder fra Fabric UI uten å vedlikeholde eksterne release-pipelines, og bruke API-er for automatisering når det trengs. Denne tilnærmingen kan også passe team med begrenset erfaring med DevOps-verktøy, som Azure Pipelines eller GitHub Actions.
• Når du bruker kildekontroll bare til utviklingsformål, og foretrekker å distribuere endringer direkte mellom faser av utgivelsesforløpet.
• Når distribusjonsregler, autobinding og andre tilgjengelige API-er er tilstrekkelige til å administrere konfigurasjonene mellom fasene av utgivelsesforløpet.
• Når du vil bruke andre funksjoner i fabric-distribusjonssamlebånd, for eksempel visning av endringer i Stoff, distribusjonslogg osv.
• Vurder også at distribusjoner i datasamlebånd for stoffdistribusjon har en lineær struktur og krever andre tillatelser for å opprette og administrere datasamlebåndet.

Alternativ 4 – CI/CD for ISV-er i Fabric (administrere flere kunder/løsninger)

Dette alternativet er forskjellig fra de andre. Det er mest relevant for uavhengige programvareleverandører (ISV) som bygger SaaS-programmer for sine kunder på toppen av Fabric. Uavhengige programvareleverandører har vanligvis et eget arbeidsområde for hver kunde og kan ha så mange som flere hundre eller tusen arbeidsområder. Når strukturen i analysene som leveres til hver kunde er lik og utenfor boksen, anbefaler vi at du har en sentralisert utviklings- og testprosess som deler seg til hver kunde bare i Prod-fasen .

Dette alternativet er basert på alternativ #2:

1. Utviklere jobber med Dev-grenen og Dev-arbeidsområdet , og plukker ut endringene de vil slippe fra Dev til Main, som beskrevet i alternativ #2.
2. Lag og send en release-tagg på den valgte commiten på Main, for eksempel v1.5.0. Taggen utløser en GitHub Actions-arbeidsflyt eller Azure DevOps-pipeline.
3. Pipelinen løser taggen til en commit SHA, registrerer begge, kjører enhetstester og justerer de taggede definisjonene for delt test. Den distribuerer dem ved å bruke fabric-cicd eller Bulk Import Item Definitions API, som beskrevet i alternativ #2. Kjør automatiserte eller manuelle tester etter utrulling. Hvis valideringen feiler, stopp promotering, fiks problemet i utviklingen, hent fiksen til Main, og lag en ny tagg for en ny kjøring.
4. Etter at valideringen lykkes og den konfigurerte produksjonsgodkjenningen er gitt, distribuerer du samme tag og registrert commit SHA til hver kundes produksjonsarbeidsområde . Bruk kundespesifikke parametere og tilkoblinger før utrulling eller gjennom API-er etter utrulling. Uavhengige kundedistribusjoner kan kjøre parallelt. Registrer taggen, commit SHA og kundemål i miljødistribusjonshistorikken slik at hver kundes distribuerte versjon kan spores.

Når bør du vurdere å bruke alternativet #4?

• Du er en ISV bygge programmer på toppen av Fabric.
• Du bruker forskjellige arbeidsområder for hver kunde til å administrere flerleieforholdet i programmet
• Hvis du vil ha mer fordeling, eller for bestemte tester for forskjellige kunder, kan det være lurt å ha flere leiere i tidligere faser av utvikling eller test. I så fall bør du vurdere at med flere leier øker antallet arbeidsområder som kreves, betydelig.

Sammendrag

Denne artikkelen oppsummerer de viktigste CI/CD-alternativene for et team som ønsker å bygge en automatisert CI/CD-prosess i Fabric. Selv om vi skisserer fire alternativer, kan de virkelige begrensningene og løsningsarkitekturen gi seg til hybridalternativer eller helt forskjellige. Du kan bruke denne artikkelen til å veilede deg gjennom ulike alternativer og hvordan du bygger dem, men du er ikke tvunget til å velge bare ett av alternativene.

Noen scenarioer eller bestemte elementer kan ha begrensninger som kan hindre deg i å ta i bruk noen av disse scenarioene.

Det samme gjelder verktøy. Selv om vi nevner forskjellige verktøy her, kan du velge andre verktøy som kan gi samme funksjonalitetsnivå. Tenk at Fabric har bedre integrering med noen verktøy, så å velge andre resulterer i flere begrensninger som trenger ulike løsninger.

Relatert innhold

• Utviklingsprosess i Microsoft Fabric
• Automatiser Git-integrering ved hjelp av API-er og Azure DevOps
• Automatiser utrullingssamlebånd ved hjelp av Fabric API-er
• Forstå avhengighetsbinding i tverrarbeidsområde-distribusjon
• Hva er en distribusjonsplan i Microsoft Fabric?