Behandle grener i Microsoft Fabric-arbeidsområder
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å den kontinuerlige integreringsdelen (CI) i CI/CD-prosessen. Hvis du vil ha en diskusjon om den kontinuerlige leveringsdelen (CD), kan du se behandle utrullingssamlebånd.
Denne artikkelen beskriver noen få forskjellige integreringsalternativer, men mange organisasjoner bruker en kombinasjon av dem.
Forutsetning
Hvis du vil integrere Git med Microsoft Fabric-arbeidsområdet, må du konfigurere følgende forutsetninger for både Fabric og Git.
Forutsetninger for stoff
Hvis du vil ha tilgang til Git-integreringsfunksjonen, trenger du en Fabric-kapasitet. En stoffkapasitet kreves for å bruke alle støttede stoffelementer. Hvis du ikke har en ennå, kan du registrere deg for en gratis prøveversjon. Kunder som allerede har en Power BI Premium-kapasitet, kan bruke denne kapasiteten, men husk at bestemte Power BI-SKU-er bare støtter Power BI-elementer.
I tillegg må følgende leierbrytere være aktivert fra administrasjonsportalen:
- Brukere kan opprette Fabric-elementer
- Brukere kan synkronisere arbeidsområdeelementer med Git-repositoriene sine
- Bare For GitHub-brukere: Brukere kan synkronisere arbeidsområdeelementer med GitHub-repositorier
Disse bryterne kan aktiveres av leieradministrator, kapasitetsadministrator eller arbeidsområdeadministrator, avhengig av organisasjonens innstillinger.
Git-forutsetninger
Git-integrasjon støttes for øyeblikket for Azure DevOps og GitHub. Hvis du vil bruke Git-integrering med Fabric-arbeidsområdet, trenger du følgende i Azure DevOps eller GitHub:
- En aktiv Azure-konto registrert til samme bruker som bruker Fabric-arbeidsområdet. Opprett en gratis konto.
- Tilgang til et eksisterende repositorium.
Utviklingsprosess
Fabric-arbeidsområdet er et delt miljø som får tilgang til levende elementer. Eventuelle endringer som gjøres direkte i arbeidsområdet overstyrer og påvirker alle andre brukere av arbeidsområdet. Git anbefalte fremgangsmåte er derfor at utviklere arbeider isolert utenfor de delte arbeidsområdene. Det finnes to måter en utvikler kan arbeide i sitt eget beskyttede arbeidsområde på.
- Utvikle ved hjelp av klientverktøy, for eksempel Power BI Desktop for rapporter og semantiske modeller, eller VS Code for notebooks.
- Utvikle i et eget stoffarbeidsområde. Hver utvikler har sitt eget arbeidsområde der de kobler til sin egen separate gren, synkroniserer innholdet i arbeidsområdet og går deretter tilbake til grenen.
Hvis du vil arbeide med grener ved hjelp av Git-integrasjon, må du først koble det delte utviklingsteamets arbeidsområde til én enkelt delt gren. Hvis gruppen for eksempel bruker ett delt arbeidsområde, kobler du det til hovedgrenen i teamets repositorium og synkroniserer mellom arbeidsområdet og repositoriet. Hvis gruppens arbeidsflyt har flere delte grener som Utvikling/Test/Prod-grener , kan hver gren kobles til et annet arbeidsområde.
Deretter kan hver utvikler velge det isolerte miljøet du vil arbeide i.
Scenario 1 – Utvikle ved hjelp av klientverktøy
Hvis elementene du utvikler, er tilgjengelige i andre verktøy, kan du arbeide med disse elementene direkte i klientverktøyet. Ikke alle elementer er tilgjengelige i alle verktøy. Elementer som bare er tilgjengelige i Fabric må utvikles i Fabric.
Arbeidsflyten for utviklere som bruker et klientverktøy som Power BI Desktop, skal se omtrent slik ut:
Klon repo til en lokal maskin. (Du trenger bare å gjøre dette trinnet én gang.)
Åpne prosjektet i Power BI Desktop ved hjelp av den lokale kopien av PBIProj.
Gjør endringer og lagre de oppdaterte filene lokalt. Utfør til det lokale repoet.
Når du er klar, skyver du grenen og forplikter seg til eksternt repo.
Test endringene mot andre elementer eller flere data ved å koble den nye grenen til et eget arbeidsområde, og laste opp semantisk modell og rapporter ved hjelp av oppdater alle-knappen i kildekontrollpanelet. Gjør eventuelle tester eller konfigurasjonsendringer der før du slår sammen til hovedgrenen.
Hvis det ikke kreves noen tester i arbeidsområdet, kan utvikleren slå sammen endringer direkte til hovedgrenen, uten behov for et annet arbeidsområde.
Når endringene er slått sammen, blir det delte teamets arbeidsområde bedt om å godta den nye utførelsen. Endringene oppdateres til det delte arbeidsområdet, og alle kan se endringene i disse semantiske modellene og rapportene.
Hvis du vil ha en spesifikk veiledning om hvordan du bruker det nye Power BI Desktop-filformatet i git, kan du se Kildekodeformat.
Scenario 2 – Utvikle ved hjelp av et annet arbeidsområde
For en utvikler som jobber på nettet, vil flyten være som følger:
Velg Gren ut til nytt arbeidsområde på Fanen Forgreninger på kildekontrollmenyen.
Angi navnene på grenen og arbeidsområdet. Den nye grenen ble opprettet basert på grenen som er koblet til gjeldende arbeidsområde.
Velg Gren ut.
Fabric oppretter det nye arbeidsområdet og grenen. Du blir automatisk tatt med til det nye arbeidsområdet.
Arbeidsområdet synkroniseres med funksjonsgrenen, og blir et isolert miljø å arbeide i, som illustrert. Du kan nå arbeide i dette nye isolerte miljøet. Synkroniseringen kan ta noen minutter. Se feilsøkingstips for mer informasjon om forgrening.
Lagre endringene, og utfør dem i funksjonsgrenen.
Når du er klar, oppretter du en PR til hovedgrenen. Gjennomgangs- og fletteprosessene utføres via Azure Repos basert på konfigurasjonen teamet ditt definerte for dette repositoriet.
Når gjennomgangen og flettingen er fullført, opprettes en ny utføring til hovedgrenen. Denne utføringen ber brukeren om å oppdatere innholdet i Utvikling-teamets arbeidsområde med de flettede endringene.
Se begrensninger for forgrening for mer informasjon.
Frigivelsesprosess
Lanseringsprosessen begynner når nye oppdateringer fullfører en Pull Request-prosess og flettes inn i teamets delte gren (for eksempel Hoved, Utvikling osv.). Fra nå av skal vi skissere de ulike alternativene for å bygge en utgivelsesprosess i Fabric. Du kan finne de ulike vurderingene for utgivelsesprosessen i behandle utrullingssamlebånd.
Bytt grener
Hvis arbeidsområdet er koblet til en Git-gren og du vil bytte til en annen gren, kan du gjøre det raskt fra kildekontrollruten uten å koble fra og koble til på nytt.
Når du bytter grener, blir arbeidsområdet synkronisert med den nye grenen, og alle elementene i arbeidsområdet overstyres. Hvis det finnes forskjellige versjoner av samme element i hver gren, erstattes elementet. Hvis et element er i den gamle grenen, men ikke det nye, slettes det.
Følg disse trinnene for å bytte mellom grener:
Velg Bytt gren på Fanen Grener på kildekontrollmenyen.
Angi grenen du vil koble til, eller opprett en ny gren. Denne grenen må inneholde samme katalog som gjeldende gren.
Velg Bytt gren.
Du kan ikke bytte grener hvis du har eventuelle uforpliktende endringer i arbeidsområdet. Velg Avbryt for å gå tilbake og utføre endringene før du bytter grener.
Hvis du vil koble gjeldende arbeidsområde til en ny gren mens du beholder den eksisterende arbeidsområdestatusen, velger du Utsjekk ny gren. Mer informasjon om å sjekke ut en ny gren på Løs konflikter i Git.