Del via

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

  • Artikkel

Målet med denne artikkelen er å presentere Fabric-utviklere med ulike alternativer for bygging av CI/CD-prosesser i Fabric, basert på vanlige kundescenarioer. Denne artikkelen fokuserer mer på kontinuerlig distribusjon (CD) av CI/CD-prosessen. Hvis du vil ha en diskusjon om delen for kontinuerlig integrasjon (CI), kan du se Behandle Git-grener.

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

Forutsetning

Hvis du vil ha tilgang til funksjonen for utrullingssamlebånd, må du oppfylle følgende betingelser:

  • Du har et Microsoft Fabric-abonnement

  • Du er administrator for et Fabric-arbeidsområde

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 finner informasjon om de ulike vurderingene for utviklingsprosessen i Behandle Git-grener

Diagram som viser hvordan utviklingsprosessen fungerer.

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.

Alternativ 1 – Git-baserte distribusjoner

Diagram som viser hvordan den Git-baserte distribusjonen fungerer.

Med dette alternativet kommer alle distribusjoner fra Git-repositoriet. Hvert trinn i utgivelsessamlebåndet har en dedikert primærgren (i diagrammet er disse fasene Utvikling, Test og Prod), som mater det aktuelle arbeidsområdet i Fabric.

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

  1. Et utgivelsessamlebånd utløses for å oppdatere innholdet i Utvikling-arbeidsområdet . Denne prosessen kan også inkludere et bygg-datasamlebånd for å kjøre enhetstester, men den faktiske opplastingen av filer gjøres direkte fra repositoriet til arbeidsområdet ved hjelp av Fabric Git API-er. Det kan hende du må ringe andre Fabric-API-er for operasjoner etter distribusjon som angir bestemte konfigurasjoner for dette arbeidsområdet eller inntar data.
  2. En PR opprettes deretter i testgrenen. I de fleste tilfeller opprettes PR ved hjelp av en utgivelsesgren som kan velge innholdet for å flytte inn i neste fase. Pr bør inkludere de samme gjennomgangs- og godkjenningsprosessene som alle andre i teamet eller organisasjonen.
  3. Et annet kompilerings - og utgivelsessamlebånd utløses for å oppdatere testarbeidsområdet ved hjelp av en prosess som ligner på den som er beskrevet i det første trinnet.
  4. En PR opprettes til Prod-gren ved hjelp av en prosess som ligner på den som er beskrevet i trinn #2.
  5. Et annet bygg - og utgivelsessamlebånd utløses for å oppdatere Prod-arbeidsområdet ved hjelp av en prosess som ligner på den som er beskrevet i det første trinnet.

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 teamet følger Gitflow som forgreningsstrategi, inkludert flere primære grener.
  • Opplastingen fra repo går direkte inn i arbeidsområdet, da vi ikke trenger byggmiljøer for å endre filene før distribusjoner. Du kan endre dette ved å ringe API-er eller kjøre elementer i arbeidsområdet etter distribusjon.

Alternativ 2 – Git-baserte distribusjoner ved hjelp av byggmiljøer

Diagram som viser flyten av Git-basert distribusjon ved hjelp av byggmiljøer.

Med dette alternativet kommer alle distribusjoner fra samme gren av Git-repositoriet (hoved). Hvert trinn i utgivelsessamlebåndet har et dedikert samlebånd for bygg og utgivelse . Disse datasamlebåndene kan bruke et byggmiljø til å kjøre enhetstester og skript som endrer noen av definisjonene i elementene før de lastes opp til arbeidsområdet. Du kan for eksempel endre datakildetilkoblingen, tilkoblingene mellom elementer i arbeidsområdet eller verdiene til parameterne for å justere konfigurasjonen for riktig fase.

Når en PR til utviklergrenen er godkjent og slått sammen:

  1. En byggsamlebånd utløses for å sette opp et nytt byggmiljø og kjøre enhetstester for utvikling-fasen . Deretter utløses et utgivelsessamlebånd for å laste opp innholdet til et byggmiljø, kjøre skript for å endre noe av konfigurasjonen, justere konfigurasjonen til utviklingsnivå og bruke fabric's Update item definition API-er til å laste opp filene til arbeidsområdet.
  2. Når denne prosessen er fullført, inkludert inntak av data og godkjenning fra utgivelsesledere, kan du opprette neste bygg- og utgivelsessamlebånd for testfasen. Disse fasene opprettes i en prosess som ligner på den som er beskrevet i det første trinnet. For testfasen kan andre automatiserte eller manuelle tester være nødvendige etter distribusjonen, for å validere endringene er klare til å bli utgitt til Prod-fasen .
  3. Når alle automatiserte og manuelle tester er fullført, kan utgivelsesansvarlig godkjenne og starte bygge- og utgivelsessamlebåndet til Prod-fasen . Siden Prod-fasen vanligvis har andre konfigurasjoner enn test-/utvikling-faser, er det viktig å også teste ut endringene etter distribusjonen. Distribusjonen bør også utløse mer inntak av data, basert på endringen, for å minimere potensiell manglende tilgjengelighet for forbrukerne.

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

  • Når du vil bruke Git som en enkelt kilde til sannhet, og opprinnelsen til alle distribusjoner.
  • Når teamet følger Trunk-basert arbeidsflyt som forgreningsstrategi.
  • Du trenger et byggmiljø (med et egendefinert skript) for å endre arbeidsområdespesifikke attributter, for eksempel connectionId og lakehouseId, før distribusjon.
  • Du trenger et utgivelsessamlebånd (egendefinert skript) for å hente elementinnhold fra git og kalle tilsvarende API for stoffelement for å opprette, oppdatere eller slette endrede stoffelementer.

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

Diagram som viser flyten av Git-basert distribusjon ved hjelp av utrullingssamlebånd.

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. Selv om selve verktøyet er internt i Fabric, kan utviklere bruke API-ene for distribusjonssamlebånd til å organisere distribusjonen som en del av azure-utgivelsesforløpet, 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 pr til hovedgrenen er godkjent og slått sammen:

  1. Et byggforløp utløses som laster opp endringene i utvikling-fasen ved hjelp av Fabric Git API-er. Om nødvendig kan datasamlebåndet utløse andre API-er for å starte operasjoner/tester etter distribusjon i utviklingsnivå .
  2. Når utviklingsdistribusjonen er fullført, starter et utgivelsessamlebånd for å distribuere endringene fra utviklingsnivå til testfase. Automatiserte og manuelle tester bør finne sted etter distribusjonen, for å sikre at endringene er godt testet før de når produksjonen.
  3. Når testene er fullført og utgivelsesbehandlingen godkjenner distribusjonen til Prod-fasen , starter utgivelsen til Prod og fullfører distribusjonen.

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

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

Diagram som viser flyten av Git-basert distribusjon for ISV-er.

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 nr. 2. Når pr til hoveddelen er godkjent og slått sammen:

  1. En byggsamlebånd utløses for å sette opp et nytt byggmiljø og kjøre enhetstester for utviklingsnivå . Når testene er fullført, utløses et utgivelsessamlebånd . Dette datasamlebåndet kan laste opp innholdet til et byggmiljø, kjøre skript for å endre noe av konfigurasjonen, justere konfigurasjonen til utviklingsnivå , og deretter bruke Fabric's Update-elementdefinisjons-API-er til å laste opp filene til arbeidsområdet.
  2. Etter at denne prosessen er fullført, inkludert inntak av data og godkjenning fra utgivelsesledere, kan neste bygg - og utgivelsessamlebånd for testfasen starte. Denne prosessen ligner på den som er beskrevet i det første trinnet. For testfasen kan andre automatiserte eller manuelle tester være nødvendige etter distribusjonen, for å validere at endringene er klare til å lanseres til Prod-fasen i høy kvalitet.
  3. Når alle testene består og godkjenningsprosessen er fullført, kan distribusjonen til Prod-kunder starte. Hver kunde har sin egen utgivelse med sine egne parametere, slik at den spesifikke konfigurasjonen og datatilkoblingen kan finne sted i den aktuelle kundens arbeidsområde. Konfigurasjonsendringen kan skje gjennom skript i et byggmiljø , eller ved hjelp av API-er etter distribusjon. Alle utgivelser kan skje parallelt fordi de ikke er relatert eller avhengige av hverandre.

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