Del via


Power BI Project (PBIP) og Azure DevOps bygger datasamlebånd for validering

Ved å kombinere Fabric Git Integration med Azure DevOps kan du koble et arbeidsområde til en gren i et Azure DevOps-repositorium og automatisk synkronisere mellom dem.

Hvis du integrerer PBIP-formatet med Azure DevOps, kan du bruke Azure Pipelines til å automatisere pipeliner for kontinuerlig integrering/kontinuerlig distribusjon (CI/CD). Disse datasamlebåndene behandler PBIP-metadatafilene og bruker en rekke kvalitetskontroller på utviklingen før du distribuerer dem til produksjonssystemet.

I denne artikkelen fokuserer vi på kontinuerlig integrering og beskriver hvordan du oppretter et Azure DevOps-datasamlebånd som garanterer anbefalte fremgangsmåter for alle semantiske modeller og rapporter i et Fabric-arbeidsområde. Ved å implementere automatiserte kvalitetstester kan du forhindre vanlige feil og forbedre teamets effektivitet. Denne fremgangsmåten sikrer for eksempel at nye teammedlemmer overholder etablerte standarder for semantisk modell- og rapportutvikling.

Mer informasjon om PBIP og Fabric Git Integration i oversikt over prosjektet og oversikt over Fabric Git-integrering.

Diagrammet nedenfor illustrerer ende-til-ende-scenarioet med to utviklingsarbeidsflyter som utløser Azure DevOps-datasamlebåndet for å validere utviklingskvaliteten. Datasamlebåndet utfører følgende handlinger:

Diagram som viser arbeidsflyten for DevOps-datasamlebånd.

  1. Bruker 1 utvikler seg ved hjelp av Power BI Desktop.

    1. Opprett en gren fra hoveddelen ved hjelp av VS Code (funksjon/datasetchange)
    2. Gjøre endringer i semantisk modell ved hjelp av Power BI Desktop
    3. Utføre endringer i ekstern repositoriumgren ved hjelp av VS Code
    4. Opprett pull-forespørsel til hovedgrenen ved hjelp av Azure DevOps
  2. Samtidig utvikler Bruker 2 seg ved hjelp av et annet Fabric-arbeidsområde.

    1. Opprett gren fra hoveddelen ved hjelp av Fabric Git (funksjon/reportchange)
    2. Gjøre rapportendringer i Fabric-arbeidsområdet
    3. Utføre endringer i ekstern repositoriumgren ved hjelp av Fabric Git
    4. Opprett pull-forespørsel til hovedgrenen ved hjelp av Azure DevOps
  3. Gruppeleder ser gjennom Pull-forespørslene og synkroniserer endringene i gruppearbeidsområdet ved hjelp av Fabric Git.

  4. Pull-forespørselen utløser Azure DevOps-datasamlebåndet for å undersøke semantisk modell- og rapportutviklingskvalitet.

Merk

I dette eksemplet bruker datasamlebåndet to verktøy for åpen kildekode-fellesskap som gjør det mulig for en utvikler å bruke (tilpassbare) anbefalte fremgangsmåter for metadataene for semantiske modeller og rapporter i en Power BI Project-mappe:

En tilnærming som ligner på eksemplet i denne artikkelen, gjelder for andre fellesskapsverktøy. Denne artikkelen fordyper seg ikke i detaljene i fellesskapsverktøyene, og heller ikke regeloppretting og redigering. Hvis du vil ha detaljert informasjon om disse emnene, kan du se koblingene som er angitt. Fokuset i denne artikkelen er på prosessen å etablere en kvalitetsport mellom kildekontroll og et stoffarbeidsområde. Det er viktig å være oppmerksom på at de henviste fellesskapsverktøyene utvikles av tredjepartsbidragsytere, og Microsoft tilbyr ikke støtte eller dokumentasjon for dem.

Trinn 1 – Koble Fabric-arbeidsområdet til Azure DevOps

Koble Fabric-arbeidsområdet til Azure DevOps:

Skjermbilde som viser Git-tilkoblingen til DevOps.

Når Fabric Git-integreringen er ferdig med å eksportere arbeidsområdeelementene, inneholder Azure DevOps-grenen en mappe for hvert element i arbeidsområdet:

Skjermbilde som viser Azure DevOps-grenen med mapper for ulike arbeidsområdeelementer.

Trinn 2 – Opprett og kjør et Azure DevOps-datasamlebånd

Slik oppretter du et nytt datasamlebånd:

  1. Velg Opprett datasamlebånd i kategorien Forløp i venstre navigasjonsmeny:

    Skjermbilde som viser hvordan du oppretter et datasamlebånd.

  2. Velg Azure Repos Git, og velg det første repositoriet (repositoriet som er koblet til Fabric-arbeidsområdet):

    Skjermbilde som viser Azure Repo Git valgt som kodekilde for datasamlebåndet.

    Skjermbilde som viser demo-ADObuild-repo valgt.

  3. Velg Starter-datasamlebånd.

    Skjermbilde som viser ikonet for startforløp valgt.

    Følgende YAML-kode vises i redigeringsprogrammet:

    Skjermbilde som viser standard YAML-kode.

  4. Kopier og lim inn YAML-koden fra datasamlebåndet for Power BI-utviklermodus i datasamlebåndet du opprettet:

    Skjermbilde som viser YAML-kode som skal legges til.

    Skjermbilde som viser andre del av YAML-kode.

  5. Velg Lagre og kjør for å overføre det nye datasamlebåndet til repositoriet.

    Skjermbilde av en gjennomgang av YAML-koden.

    Skjermbilde som viser lagre og kjøre merket område.

Azure DevOps kjører datasamlebåndet og starter to byggjobber parallelt:

Skjermbilde som viser Azure DevOps som kjører et datasamlebånd.

  • Build_Datasets
    • Laster ned binærfiler for tabellredigering.
    • Last ned standardregler for anbefalt fremgangsmåteanalyse. Hvis du vil tilpasse reglene, legger du til en Rules-Dataset.json i roten av repositoriet.
    • Bla gjennom alle de semantiske modellelementmappene, og kjør BPA-regler for tabellredigering.
  • Build_Reports
    • Last ned binærfiler for PBI-inspeksjon.
    • Last ned standardregler for PBI-inspeksjon. Hvis du vil tilpasse reglene, legger du til en Rules-Report.json i roten av repositoriet.
    • Bla gjennom alle rapportelementmappene, og kjør regler for Power BI-inspeksjon.

Når den er ferdig, oppretter Azure DevOps en rapport over alle advarslene og feilene som oppstod:

Skjermbilde som viser feilrapport.

Velg koblingen for å åpne en mer detaljert visning av de to jobbene:

Skjermbilde som viser visningsloggknappen.

Skjermbilde som viser utvidet feillogg.

Hvis rapporten eller den semantiske modellen mislykkes med en regel med høyere alvorlighetsgrad, mislykkes bygget, og feilen er uthevet:

Skjermbilde som viser merkepennfeil.

Trinn 3 – Definer grenpolicyer

Når datasamlebåndet er oppe og går, aktiverer du Avdelingspolicyer på hovedgrenen. Dette trinnet sikrer at ingen utføringer kan gjøres direkte inn i hoveddelen. En «pull-forespørsel» er alltid nødvendig for å slå sammen endringer tilbake til hoveddelen , og du kan konfigurere datasamlebåndet til å kjøre med hver pull-forespørsel.

  1. Velg avdelingspolicyer> for grener:>

    Skjermbilde som viser grenpolicyer.

  2. Konfigurer det opprettede datasamlebåndet som en byggpolicy for grenen:

    Skjermbilde som viser grensesnittet for byggpolicy.

    Skjermbilde som viser andre del av grensesnittet for byggpolicy.

Trinn 4 – Opprett pull-forespørsel

Hvis du går tilbake til Fabric Workspace, gjør en endring i en av rapportene eller semantiske modeller og prøver å utføre endringen, får du følgende feil:

Skjermbilde som viser endringsfeilen som ikke kan utføres.

Du kan bare gjøre endringer i hovedgrenen gjennom en pull-forespørsel. Slik oppretter du en pull-forespørselsutsjekking av en ny gren for å gjøre endringene på:

Opprett en gren direkte fra Fabric Workspace:

  1. Velg på Checkout new branch i kildekontrollruten, og angi et navn for grenen.

    Skjermbilde som viser kildekontrollskjermen for å sjekke ut en ny gren.

    Skjermbilde som viser hvordan du sjekker ut en ny gren.

    Alternativt kan du velge å utvikle deg i et eget, isolert arbeidsområde eller i Power BI Desktop. Hvis du vil ha mer informasjon, kan du se Behandle Git-grener

  2. Utfør endringene i denne nye grenen.

    Skjermbilde som viser utføringsendringer i gren.

  3. Opprett en pull-forespørsel i hovedgrenen fra Azure DevOps-portalen etter utføringen.

    Skjermbilde som viser en ny pull-forespørsel som er opprettet.

    Skjermbilde som viser opprettet pull-forespørsel.

Arbeidsflyten for pull-forespørsel lar deg ikke bare validere og se gjennom endringene, men utløser også datasamlebåndet automatisk.

Skjermbilde som viser rapportendring.

Hvis det er en alvorlighetsgradsfeil i én av reglene, kan du ikke fullføre pull-forespørselen og slå sammen endringene tilbake til hovedgrenen.

Skjermbilde fullført pull-forespørsel.