Vælg den bedste Indstilling for Fabric CI/CD-arbejdsproces for dig

Denne artikel præsenterer Fabric-udviklere for forskellige muligheder for at bygge CI/CD-processer i Fabric, baseret på almindelige kundescenarier. I denne artikel fokuseres der mere på den kontinuerlige udrulning (CD) af CI/CD-processen. For en diskussion om den kontinuerlige integration (CI)-delen, se Udviklingsproces i Microsoft Fabric.

I denne artikel beskrives flere forskellige muligheder, men mange organisationer benytter en hybrid tilgang.

Forudsætninger

For at bygge en CI/CD-proces ved hjælp af mulighederne i denne artikel, har du brug for:

• Et Microsoft Fabric-abonnement

• Et Fabric-arbejdsområde (du skal være workspace-administrator for at konfigurere deployment)

• For Git-baserede muligheder (1, 2 og 4) er en understøttet Git-udbyder (Azure DevOps eller GitHub) forbundet via Git-integration

Udviklingsproces

Udviklingsprocessen er den samme i alle installationsscenarier og er uafhængig af, hvordan nye opdateringer udgives i produktion. Når udviklere arbejder med kildestyring, skal de arbejde i et isoleret miljø. I Fabric kan dette miljø enten være en IDE på din lokale maskine (f.eks. Power BI Desktop eller VS Code) eller et andet arbejdsområde i Fabric. Du kan finde information om de forskellige overvejelser i udviklingsprocessen i Microsoft Fabric.

Git sync understøtter både at committe workspace-ændringer til Git og opdatering af et workspace fra Git. PR-pilen viser, hvilken retning du samler funktionsændringer i den delte udviklingsgren, ikke en tovejs synkroniseringsoperation.

Frigivelsesproces

Udgivelsesprocessen starter, når nye opdateringer er fuldført, og pullanmodningen flettes med teamets delte forgrening (f.eks . Main, Dev osv.). Fra nu af er der forskellige muligheder for at bygge en udgivelsesproces i Fabric.

Følgende tabel opsummerer de muligheder, der kan hjælpe dig med at vælge. Mange hold kombinerer mere end ét.

¹ I mulighed 2 er kun Dev-arbejdsområdet forbundet til Git. Test- og produktionsarbejdsområderne er ikke forbundet til Git. At sende et release-tag på Main udløser en pipeline, der deployer den version til Test. Efter vellykket validering og godkendelse deployerer pipelinen det samme tag og commit SHA til Prod.

Disse muligheder kræver ikke en specifik forgreningsstrategi, såsom Gitflow eller trunk-baseret udvikling. Det, der betyder noget, er, at hvert trin deployer en kendt, versioneret commit, og at Prod modtager det samme indhold, som du testede.

Muligheder 1 og 2 adskiller sig i, hvordan du organiserer og promoverer udgivelser, ikke i et eksklusivt valg af værktøjer. Begge muligheder kan bruge fabric-cicd eller Fabric Items API'er og miljøspecifik parameterisering. Mulighed 1 fremmer ændringer gennem separate stage-grene. Mulighed 2 bruger et release-tag på Main til at udløse udrulning af samme commit til Test og, efter validering og godkendelse, til Prod.

En implementeringsplan er ikke en separat arbejdsgangsmulighed. Du kan bruge en plan med understøttede Git-operationer i mulighed 1, med deployment-pipelines i mulighed 3, eller ved at kalde Bulk Import Item Definitions API direkte i muligheder 1, 2 og 4. Biblioteket fabric-cicd understøtter ikke deployeringsplaner, heller ikke når du bruger dets bulkimport-tilstand. Planen styrer udrulningsrækkefølge, afhængigheder og handlinger, mens den valgte arbejdsgang fortsætter med at definere sandhedskilden, hvad hvert trin deployerer, og fasekonfiguration.

Mulighed 1 - Definitionsbaserede udrulninger fra per-trins Git-grene

Med denne mulighed starter alle udrulninger fra Git. Hver fase har en dedikeret primær gren: Dev, Test og Prod i dette eksempel. PR'er fremmer ændringer mellem disse branches, og hvert arbejdsområde modtager definitionerne fra sin stages branch. Du kan deploye med Git-integration, fabric-cicd eller Fabric Items API'er. Når du bruger fabric-cicd eller Items API'er, behøver målarbejdsområdet ikke en Git-forbindelse. Den definerende funktion er den separate gren for hvert trin, ikke udrulningsværktøjet.

Når en pullanmodning til forgreningen Udvikling er godkendt og flettet:

1. Opdater Dev-arbejdsområdet fra Dev-branchen , for eksempel med Git-integration. Kør enhedstests og eventuelle nødvendige operationer efter udsendelsen.
2. Opret en PR til Test-afdelingen med de ændringer, du ønsker at promovere. Du kan bruge en release-gren til at plukke de ændringer ud. Anvend dit teams gennemgangs- og godkendelsesprocesser.
3. Deploy et specifikt commit fra Test-grenen til Test-arbejdsområdet ved at bruge Git-integration, fabric-cicd eller Fabric Items API'er. Påfør stage-specifik konfiguration og kør automatiserede eller manuelle tests.
4. Opret en PR til produktionsafdelingen , der promoverer de validerede ændringer. Gennemgå de resulterende definitioner for at sikre, at de matcher den testede frigivelse, undtagen for bevidst stage-specifik konfiguration. Hvis du tilføjer andre ændringer, så valider dem i Test før forfremmelse.
5. Efter godkendelse skal du udrulle Prod-grenen til Prod-arbejdsområdet ved at bruge dit valgte deployment-værktøj. Kør de nødvendige kontroller efter udrulning og dataindlæsning.

Nogle vareafhængigheder binder automatisk gennem logiske ID'er. Andre har brug for parameterisering eller opdateringer efter udrulning. For detaljer, se Forstå afhængighedsbinding i tværarbejdsområde-implementering.

Hvilke komponenter kan bruges til at implementere mulighed #1?

• Git-integration: Forbind hvert arbejdsområde til dets stage-gren. Opdater det via Fabric UI eller automatiser opdateringer med Fabric Git API'erne.
• fabric-cicd: Tjek stage-grenen og udgiv dens item-definitioner med miljøspecifikke parametre. Målarbejdsområdet behøver ikke en Git-forbindelse.
• Fabric Items API'er: Udrul definitioner fra stagets gren ved at kalde Opret item og Opdater varedefinition, eller Bulk Import Item Definitions API. Når du kalder API'er direkte, forbereder din automatisering definitionerne og den fasespecifikke konfiguration.

For eksempler på implementering, se fabric-cicd og Azure DevOps-tutorialen eller Fabric CI/CD med Bulk Import Item Definitions API.

Hvornår skal du overveje at bruge indstillingen #1?

• Når du vil bruge dit Git-lager som den eneste kilde til sandhed og oprindelsen af alle udrulninger.
• Når du ønsker en separat primær afdeling for hvert trin, med PR-baseret gennemgang og forfremmelse mellem stadier.
• Når du vil administrere stage-specifikke definitioner i Git, eller anvende miljøspecifik konfiguration med dit valgte deployment-værktøj.

Mulighed 2 - Definitionsbaserede udrulninger fra en delt release-commit

Med denne mulighed arbejder udviklerne på en udviklingsgren , der er forbundet til udviklingsarbejdsområdet . Hovedgrenen er release-grenen: den indeholder kun de ændringer, du vælger at frigive. Test- og produktionsarbejdsområderne er ikke forbundet til Git. At skubbe et release-tag på Main udløser en GitHub Actions-arbejdsgang eller Azure DevOps-pipeline. Den deployerer den taggede version til Test, kører validering og venter på produktionsgodkendelse, før den deployer det samme tag og commit SHA til Prod. Pipelinen kan bruge et build-miljø til at køre enhedstests og justere varedefinitioner, før de uploades. For eksempel kan du ændre datakildeforbindelser, referencer til andre elementer eller parameterværdier for målstadiet. Ikke alle item-afhængigheder kræver disse ændringer. Nogle binder automatisk gennem logiske ID'er, når de implementeres i et nyt arbejdsområde. For detaljer, se Forstå afhængighedsbinding i tværarbejdsområde-implementering.

Udløsningsflowet fungerer som følger:

1. Udviklere samler godkendte PR'er i Dev-branchen, og Dev-arbejdsområdet opdateres fra Git.
2. For at forberede en udgivelse, lav en PR, der udvælger de ændringer, du vil udgive fra Dev til Main. PR'en bør inkludere de samme gennemgangs- og godkendelsesprocesser som enhver anden PR i dit team eller din organisation.
3. Opret et release-tag på det valgte commit på Main, for eksempel v1.5.0. Skub tagget for at udløse en GitHub Actions-arbejdsgang eller en Azure DevOps-pipeline, der er konfigureret til release-tags.
4. Pipelinen løser tagget til en commit SHA, registrerer begge, tjekker den commit, kører enhedstests og justerer konfigurationen for testen. Den uploader disse varedefinitioner til Test-arbejdsområdet ved at bruge fabric-cicd eller Bulk Import Item Definitions API'en. For detaljer, se Hvilke komponenter kan bruges til at implementere mulighed #2?. Kør automatiserede eller manuelle tests efter udrulning. Hvis valideringen fejler, stop forfremmelsen til produktion.
5. Efter valideringen er lykkedes, venter pipelinen ved en konfigureret produktionsgodkendelsesport. Brug en GitHub-miljøgodkendelse eller en Azure DevOps-miljøgodkendelseskontrol.
6. Efter godkendelse udrul det samme release-tag og registrerede commit SHA til Prod. Kun konfiguration pr. trin, såsom værdisæt i variabelbiblioteket eller parameterfiler, adskiller sig fra Test. Kør produktionsspecifikke kontroller og udløs enhver dataindlæsning, som ændringen kræver, for at minimere utilgængelighed for forbrugerne.

Hvis valideringen fejler, laver du rettelsen først i Dev , og plukker den derefter ud i Main. Opret et nyt frigivelsestag og gentag pipelinen, inklusive testvalidering. Denne tilgang sikrer også, at fremtidige udgivelser fra Dev inkluderer rettelsen.

For sporbarhed kan du konfigurere deployment-jobs, der målretter de tilsvarende GitHub- eller Azure DevOps-miljøer. Inkluder release-tagget og resolved commit SHA i hver deployment-post, så du kan identificere, hvilken version der nåede Test og Prod. Et Git-tag alene registrerer ikke, hvor en version blev deployet.

Hvilke komponenter kan bruges til at implementere mulighed #2?

• Fabric-cicd - et Python-bibliotek designet til brug med Microsoft Fabric-arbejdsområder. Dette bibliotek understøtter kode-først Continuous Integration / Continuous Deployment (CI/CD) automatiseringer for problemfrit at integrere arbejdsområder i en deployment-ramme. For et komplet end-to-end eksempel, følg vores fabric-cicd og Azure DevOps tutorial. Fabric-CICD understøtter to publiceringstilstande:
  • Item definition API'er (standard): Udgiver elementer ét ad gangen ved at bruge Fabric Create item og Update item definition API'erne.
  • Bulk import (eksperimentel): Offentliggør alle elementer i et enkelt kald ved at bruge Bulk Import Item Definitions API. For at bruge denne tilstand, aktiver enable_experimental_features og enable_bulk_publish funktionsflagene. For mere information, se fabric-cicd bulk publish.
• Bulk-Import-Item-Definitions-API - API'en understøtter både oprettelse af nye varer og opdatering af eksisterende elementer, samtidig med at Fabrics indbyggede afhængighedshåndtering er afhængig for at sikre, at items implementeres i den korrekte rækkefølge. Dette muliggør konsistente, gentagelige implementeringer i test- og produktionsmiljøer uden manuel indgriben. For et eksempel på en tutorial følger du vores Fabric CI/CD med Bulk Import Item Definitions API.

Hvornår skal du overveje at bruge indstillingen #2?

• Når du har brug for miljøspecifik parameterisering af varedefinitioner før implementering. Fabric-cicd-parameteriseringsfunktionen bruger en parameter.yml fil til at erstatte værdier for hvert målmiljø, inklusive forbindelses-ID'er og lakehouse-ID'er, uden at opretholde separate varedefinitioner for hvert trin. Den understøtter find-and-restore-operationer, udskiftning af værdier valgt af JSON-stier og dynamisk opløsning af mål-workspace item ID'er. Denne funktion er også tilgængelig i mulighed 1, når du bruger fabric-cicd. Git-integration alene giver ikke denne udrulningstids-substitution.
• Når du vil bruge Git som din eneste kilde til sandhed og oprindelsen af alle udrulninger.
• Når du vil vælge, hvilke ændringer der skal ind i hver udgivelse, og deploy en tagget, testet version til Prod.

Mulighed 3 – Udrul ved hjælp af Fabric-udrulningspipelines

Med denne indstilling er Git kun forbundet indtil udviklingsfasen . Fra udviklingsfasen sker udrulninger direkte mellem arbejdsområderne i Dev/Test/Prod ved hjælp af Fabric-udrulningspipelines. Du kan deploye mellem trin direkte fra Fabric UI eller bruge deployment pipelines API'erne til at orkestrere deploymenten som en del af din Azure release pipeline eller en GitHub-workflow. Disse API'er gør det muligt for teamet at oprette en lignende build- og udgivelsesproces som i andre indstillinger ved hjælp af automatiserede test (der kan udføres i selve arbejdsområdet eller før udviklingsfasen), godkendelser osv.

Når udrulningen kræver en specifik rækkefølge, relaterede elementer eller handlinger, kan du vedhæfte en udrulningsplan til en udrulning mellem faserne. Udrulningsregler og autobinding fortsætter med at styre fase-specifik konfiguration.

Når du godkender og sammenfletter en PR med grenen, der er forbundet til udviklingsarbejdsområdet :

1. Opdater Dev-arbejdsområdet fra Git ved at bruge Fabric UI eller Fabric Git API'erne. Kør alle nødvendige operationer og tests efter opdateringen.
2. Udrul ændringerne fra Dev til Test ved at bruge Fabric deployment pipelines, enten fra Fabric UI eller gennem deployment pipelines API'erne. Kør automatiserede eller manuelle tests i Test , før du promoverer ændringerne til Prod.
3. Når testene er bestået, og release manageren godkender, skal du deployere det validerede indhold fra Test til Prod. Opdater ikke det valgte indhold i Test mellem validering og deployment til Prod uden at teste det igen.

Du kan udføre disse trin fra Fabric UI eller automatisere dem med API'er i Azure Pipelines eller GitHub Actions. Du behøver ikke eksterne build- og release-pipelines til UI-baserede workflows.

Hvornår skal du overveje at bruge indstillingen #3?

• Når dit team foretrækker Fabric's indbyggede implementeringsoplevelse, og dets kapaciteter opfylder dine implementeringsbehov. Du kan deploye mellem arbejdsområder fra Fabric UI uden at vedligeholde eksterne release-pipelines og bruge API'er til automatisering, når det er nødvendigt. Denne tilgang kan også passe til teams med begrænset erfaring med DevOps-værktøjer, såsom Azure Pipelines eller GitHub Actions.
• Når du kun bruger kildestyring til udviklingsformål og foretrækker at udrulle ændringer direkte mellem faserne i udgivelsespipelinen.
• Når installationsregler er autobinding og andre tilgængelige API'er tilstrækkelige til at administrere konfigurationerne mellem faserne i udgivelsespipelinen.
• Når du vil bruge andre funktioner i Fabric-udrulningspipelines, f.eks. få vist ændringer i Fabric, udrulningshistorik osv.
• Overvej også, at udrulninger i Fabric-udrulningspipelines har en lineær struktur og kræver andre tilladelser til at oprette og administrere pipelinen.

Mulighed 4 – CI/CD til ISV'er i Fabric (administration af flere kunder/løsninger)

Denne indstilling er forskellig fra de andre. Det er mest relevant for ISV (Independent Software Vendors), der bygger SaaS-programmer til deres kunder oven på Fabric. ISV'er har normalt et separat arbejdsområde for hver kunde og kan have op til flere hundrede eller tusindvis af arbejdsområder. Når strukturen af de analyser, der leveres til hver kunde, er den samme og standardiserede, anbefaler vi, at du har en centraliseret udviklings- og testproces, der kun opdeles til hver kunde i fasen Prod .

Denne mulighed er baseret på mulighed #2:

1. Udviklere arbejder på Dev-grenen og Dev-arbejdsområdet og udvælger de ændringer, de vil frigive fra Dev til Main, som beskrevet i mulighed #2.
2. Opret og skub et release-tag på det valgte commit på Main, for eksempel v1.5.0. Tagget udløser en GitHub Actions-arbejdsgang eller Azure DevOps-pipeline.
3. Pipelinen løser tagget til en commit SHA, registrerer begge, kører enhedstests og justerer de taggede definitioner for delt test. Den deployerer dem ved at bruge fabric-cicd eller Bulk Import Item Definitions API, som beskrevet i mulighed #2. Kør automatiserede eller manuelle tests efter udrulning. Hvis valideringen fejler, stop promoveringen, fix problemet i Dev, bring rettelsen ind i Main og lav et nyt tag til et nyt run.
4. Når valideringen lykkes, og den konfigurerede produktionsgodkendelse er givet, udrul det samme tag og registrerede commit SHA til hver kundes produktionsområde . Anvend kundespecifikke parametre og forbindelser før implementering eller gennem API'er efter implementering. Uafhængige kundeimplementeringer kan køre parallelt. Registrer tagget, commmit SHA og kundemål i miljøimplementeringshistorikken, så hver kundes deployerede version kan spores.

Hvornår skal du overveje at bruge indstillingen #4?

• Du er en ISV-byggeapplikationer oven på Fabric.
• Du bruger forskellige arbejdsområder for hver kunde til at administrere dit programs flerlejemål
• Hvis du vil have mere adskillelse eller specifikke test for forskellige kunder, kan det være en god idé at have flere lejere i tidligere udviklings- eller testfaser. I dette tilfælde skal du overveje, at antallet af påkrævede arbejdsområder vokser betydeligt med flere lejere.

Resumé

I denne artikel opsummeres de vigtigste CI/CD-muligheder for et team, der ønsker at bygge en automatiseret CI/CD-proces i Fabric. Selvom vi skitserer fire muligheder, kan begrænsningerne i det virkelige liv og løsningsarkitekturen være velegnet til hybride muligheder eller helt forskellige. Du kan bruge denne artikel til at guide dig gennem forskellige indstillinger, og hvordan du opretter dem, men du er ikke tvunget til kun at vælge en af indstillingerne.

Nogle scenarier eller specifikke elementer kan have begrænsninger, der kan forhindre dig i at anvende nogen af disse scenarier.

Det samme gælder for værktøj. Selvom vi nævner forskellige værktøjer her, kan du vælge andre værktøjer, der kan levere samme funktionalitetsniveau. Tænk på, at Fabric har bedre integration med nogle værktøjer, så hvis du vælger andre, resulterer det i flere begrænsninger, der kræver forskellige løsninger.

Relateret indhold

• Udviklingsproces i Microsoft Fabric
• Automatiser Git-integration ved hjælp af API'er og Azure DevOps
• Automatiser udrulningspipeline ved hjælp af Fabric API'er
• Forstå afhængighedsbinding i tværarbejdsområde-implementering
• Hvad er en implementeringsplan i Microsoft Fabric?