Del via

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

  • Artikel

Målet med denne artikel er at præsentere Fabric-udviklere med 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. Du kan få en diskussion om den kontinuerlige integrationsdel (CI) under Administrer Git-forgreninger.

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

Forudsætninger

Hvis du vil have adgang til funktionen udrulningspipelines, skal du opfylde følgende betingelser:

  • Du har et Microsoft Fabric-abonnement

  • Du er administrator af et Fabric-arbejdsområde

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 oplysninger om de forskellige overvejelser i forbindelse med udviklingsprocessen i Administrer Git-forgreninger

Diagram, der viser, hvordan udviklingsprocessen fungerer.

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.

Mulighed 1 – Git-baserede udrulninger

Diagram, der viser, hvordan den Git-baserede udrulning fungerer.

Med denne indstilling stammer alle udrulninger fra Git-lageret. Hver fase i udgivelsespipelinen har en dedikeret primær forgrening (i diagrammet er disse faser Dev, Test og Prod), som føder det relevante arbejdsområde i Fabric.

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

  1. En udgivelsespipeline udløses for at opdatere indholdet af udviklerarbejdsområdet. Denne proces kan også omfatte en Build-pipeline til kørsel af enhedstest, men den faktiske upload af filer udføres direkte fra lageret til arbejdsområdet ved hjælp af Fabric Git-API'er. Du skal muligvis kalde andre Fabric-API'er for handlinger efter udrulning, der angiver specifikke konfigurationer for dette arbejdsområde, eller indfødningsdata.
  2. Der oprettes derefter en pullanmodning i forgreningen Test . I de fleste tilfælde oprettes pullanmodningen ved hjælp af en udgivelsesgren, der kan vælge det indhold, der skal flyttes til næste fase. Pullanmodningen skal omfatte de samme korrektur- og godkendelsesprocesser som andre i dit team eller din organisation.
  3. En anden build- og udgivelsespipeline udløses for at opdatere testarbejdsområdet ved hjælp af en proces, der ligner den, der er beskrevet i det første trin.
  4. Der oprettes en pullanmodning for forgreningen Prod ved hjælp af en proces, der ligner den, der er beskrevet i trin 2.
  5. En anden build- og udgivelsespipeline udløses for at opdatere prod-arbejdsområdet ved hjælp af en proces, der ligner den, der er beskrevet i det første trin.

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 dit team følger Gitflow som forgreningsstrategi, herunder flere primære forgreninger.
  • Overførslen fra lageret går direkte til arbejdsområdet, da vi ikke behøver at bygge miljøer for at ændre filerne før udrulninger. Du kan ændre dette ved at kalde API'er eller køre elementer i arbejdsområdet efter udrulningen.

Mulighed 2 – Git-baserede udrulninger ved hjælp af Build-miljøer

Diagram, der viser flowet for Git-baseret udrulning ved hjælp af buildmiljøer.

Med denne indstilling stammer alle udrulninger fra den samme gren af Git-lageret (Main). Hver fase i udgivelsespipelinen har en dedikeret build - og udgivelsespipeline . Disse pipelines kan bruge et Build-miljø til at køre enhedstests og scripts, der ændrer nogle af definitionerne i elementerne, før de uploades til arbejdsområdet. Det kan f.eks. være, at du vil ændre datakildeforbindelsen, forbindelserne mellem elementer i arbejdsområdet eller værdierne for parametre for at justere konfigurationen for den rette fase.

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

  1. En buildpipeline udløses for at spinde et nyt buildmiljø op og køre enhedstest for udviklingsfasen . Derefter udløses en udgivelsespipeline for at uploade indholdet til et Build-miljø, køre scripts for at ændre noget af konfigurationen, justere konfigurationen til udviklingsfasen og bruge Fabric's API'er til definition af opdateringselementer til at uploade filerne til arbejdsområdet.
  2. Når denne proces er fuldført, herunder indtagelse af data og godkendelse fra udgivelsesadministratorer, kan den næste build - og udgivelsespipelines til testfasen oprettes. Disse faser oprettes i en proces, der ligner den, der er beskrevet i det første trin. I forbindelse med testfasen kan der være behov for andre automatiserede eller manuelle test efter udrulningen for at validere, at ændringerne er klar til at blive frigivet til fasen Prod.
  3. Når alle automatiserede og manuelle test er fuldført, kan udgivelsesadministratoren godkende og starte build- og udgivelsespipelines til Prod-fasen. Da fasen Prod har forskellige konfigurationer end test-/udviklingsfaser, er det vigtigt også at teste ændringerne efter udrulningen. Udrulningen bør også udløse mere indtagelse af data baseret på ændringen for at minimere den potentielle manglende tilgængelighed for forbrugerne.

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

  • Når du vil bruge Git som din eneste kilde til sandhed og oprindelsen af alle udrulninger.
  • Når dit team følger Trunk-baseret arbejdsproces som sin forgreningsstrategi.
  • Du skal bruge et buildmiljø (med et brugerdefineret script) for at ændre arbejdsområdespecifikke attributter, f.eks . connectionId og lakehouseId, før udrulningen.
  • Du skal bruge en udgivelsespipeline (brugerdefineret script) for at hente elementindhold fra git og kalde den tilsvarende Fabric Item API for at oprette, opdatere eller slette ændrede Fabric Items.

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

Diagram, der viser flowet for Git-baseret udrulning ved hjælp af 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. Selvom selve værktøjet er internt for Fabric, kan udviklere bruge API'erne til udrulningspipelines til at orkestrere udrulningen som en del af deres Azure-udgivelsespipeline eller en GitHub-arbejdsproces. 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 pullanmodningen til hovedgrenen er godkendt og flettet:

  1. En buildpipeline udløses, der uploader ændringerne til udviklingsfasen ved hjælp af Fabric Git-API'er. Hvis det er nødvendigt, kan pipelinen udløse andre API'er for at starte handlinger/test efter udrulning i udviklingsfasen .
  2. Når udrulningen af udvikling er fuldført, startes en udgivelsespipeline for at udrulle ændringerne fra udviklingsfasen til testfasen. Automatiserede og manuelle test skal udføres efter udrulningen for at sikre, at ændringerne er veltestede, før de når produktionen.
  3. Når testene er fuldført, og udgivelsesadministratoren godkender udrulningen til Prod-fasen , starter udgivelsen til Prod og fuldfører udrulningen.

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

  • 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)

Diagram, der viser flowet for Git-baseret udrulning for ISV'er.

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 indstilling er baseret på indstilling #2. Når pullanmodningen til hoved er godkendt og flettet:

  1. En buildpipeline udløses for at spinde et nyt Build-miljø og køre enhedstest for udviklingsfasen . Når testene er fuldført, udløses en udgivelsespipeline . Denne pipeline kan uploade indholdet til et Build-miljø, køre scripts for at ændre noget af konfigurationen, justere konfigurationen til udviklingsfasen og derefter bruge Fabric's API'er til opdatering af elementdefinitioner til at uploade filerne til arbejdsområdet.
  2. Når denne proces er fuldført, herunder indtagelse af data og godkendelse fra udgivelsesadministratorer, kan næste build - og udgivelsespipelines til testfase starte. Denne proces ligner den, der er beskrevet i det første trin. I forbindelse med testfasen kan andre automatiserede eller manuelle test være påkrævet efter udrulningen for at validere, at ændringerne er klar til at blive frigivet til Prod-fasen i høj kvalitet.
  3. Når alle test er bestået, og godkendelsesprocessen er fuldført, kan udrulningen til Prod-kunder starte. Hver kunde har sin egen udgivelse med sine egne parametre, så dens specifikke konfiguration og dataforbindelse kan foregå i den relevante kundes arbejdsområde. Konfigurationsændringen kan ske via scripts i et buildmiljø eller ved hjælp af API'er efter installation. Alle udgivelser kan ske parallelt, da de ikke er relaterede eller afhængige af hinanden.

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