🚀CI/CD for Microsoft Fabric ved brug af Azure DevOps og Python-pakken `fabric-cicd`

I denne tutorial bruger du fabric-cicd python-biblioteket til at promovere ændrede elementer (f.eks. en specifik Notebook) fra udviklingsarbejdsområdet til testarbejdsområdet og til sidst til produktion.

1. Scenarieoversigt

Mød Alex — en Dev Lead, der arbejder med Microsoft Fabric.

Alex' team bygger notebooks, datapipelines, semantiske modeller og rapporter i et udviklings-Fabric-arbejdsområde. Når funktionerne er klar, skal Alex promovere ændrede elementer (f.eks. en specifik notesbog) fra udviklingsarbejdsområdet til testarbejdsområdet og til sidst til produktion.

Udfordringen

Alex' notesbøger bruger magikommandoen %%configure til at fastgøre sig til et bestemt søhus. Det betyder, at Notebook-definitionerne indeholder hardkodede GUID'er — workspace IDs, Lakehouse ID's og SQL endpoint IDs — som er forskellige i hvert miljø.

Hvad Alex forventer

Krav	Løsning
Udsendelsesændrede varer fusioneret til filialen	`fabric-cicd` `publish_all_items()` udruller alle objekttyper i scope
Eksplicit item type-afgrænselse	Pipeline-parameter `items_in_scope` — du skal angive, hvilke itemtyper der skal implementeres,
Godkendelsesworkflow før udrulning til test/produktion	ADO-miljøer med godkendelsesporte
Automatisk udskiftning af GUID (udvikler → test/produktion)	`fabric-cicd` Parameterfiler (`parameter.yml`)
Sikker legitimationsstyring	Azure Key Vault + ADO Variable Groups
Automatisk udløser ved sammenfletning til gren	ADO Pipeline med branch triggers

Værktøjerne

Værktøjet	Formål
Azure DevOps (ADO)	CI/CD-orkestrering, Git-hosting, godkendelser
`fabric-cicd` Python-pakke	Microsofts open source-bibliotek til udrulning af Fabric-elementer
Azure Key Vault	Opbevarer sikkert Service Principal-legitimationsoplysninger
Serviceleder (SPN)	Autentificerer mod Fabric REST API'en

2. Arkitekturdiagram

Følgende diagram illustrerer forløbet af tutorialen.

3. Forudsætninger

Før du begynder, skal du sikre dig, at du har følgende på plads:

#	Forudsætning	Oplysninger
1	Azure DevOps Organization & Project	Et projekt med Repos og Pipelines aktiveret
2	Microsoft Fabric Workspaces	Tre arbejdsområder — ét til udvikling, testog produktion
3	Serviceleder (SPN)	An Entra ID (Azure AD) App Registration med en klienthemmelighed
4	SPN-tilladelser i Fabric	SPN'en skal tilføjes som medlem eller administrator på hvert mål-Fabric-arbejdsområde
5	Azure Key Vault	Et nøglehvælv med tre hemmeligheder: Lejer-ID, Klient-ID og Klienthemmelighed
6	Fabric Git-integration	Dev workspace skal være forbundet til grenen `dev` i dit ADO-repo
7	Python 3.12+	Bruges i pipeline-agenten til at køre deployment-scriptet
8	`fabric-cicd` Python-pakke	Microsofts open source implementeringsbibliotek (PyPI)
9	Fabric Admin-indstilling for SPN	En Fabric Admin skal aktivere "Service Principals can use Fabric APIs" i Fabric Admin Portal under Lejerindstillinger

💡 Tip: For at aktivere Service Principal-adgang i Fabric skal en Fabric Admin aktivere "Service Principals can use Fabric APIs" i Fabric Admin Portal under Tenant Settings.

Download kildefilerne

Fork Fabric-samples repository til din GitHub-konto.
Klon din fork til din lokale maskine:

git clone https://github.com/<your-account>/fabric-samples.git
cd fabric-samples

4. Initial Azure DevOps Setup

Dette afsnit gennemgår alle Azure DevOps-ressourcer, du skal konfigurere, før pipelinen kan køre.

4.1 Azure Key Vault Integration

Dine Service Principal-legitimationsoplysninger (Tenant ID, Client ID og Secret) bør aldrig gemmes i klartekst. I stedet skal du opbevare dem i Azure Key Vault.

Steps to Set Up Azure Key Vault

Opret et Key Vault i Azure-portalen (eller brug et eksisterende).
Tilføj tre hemmeligheder:

Hemmeligt navn	Beskrivelse	Eksempelværdi
`aztenantid`	Your Azure AD / Entra ID Tenant ID	`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
`azclientid`	Service Principals applikations-ID (klient-ID)	`xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`
`azspnsecret`	Service Principals klienthemmelighedsværdi	`your-secret-value`

Adgang til tilskud: ADO-serviceforbindelsen (eller ADO-projektidentiteten) skal have Hent- og Liste-tilladelser på hemmeligheder i Key Vaults adgangspolitikker (eller RBAC-rolle Key Vault Secrets User).

4.2 Variabelgruppe: `fabric_cicd_group_sensitive`

Denne variabelgruppe er knyttet til Azure Key Vault, hvilket betyder, at de hemmelige værdier hentes under kørsel og aldrig eksponeres i ADO-brugerfladen.

Trin til oprettelse

Navigér til Pipelines → Library i dit ADO-projekt.
Klik + Variabel gruppe.
Nævn det: fabric_cicd_group_sensitive
Tænd for Link-hemmeligheder fra et Azure-nøglevault som variabler.
Vælg dit Azure-abonnement og Key Vault.
Klik + Tilføj og vælg de tre hemmeligheder:

aztenantid
azclientid
azspnsecret

Klik på Gem.

Variabel	Kilde	Følsom?
`aztenantid`	Azure Key Vault	✅ Ja
`azclientid`	Azure Key Vault	✅ Ja
`azspnsecret`	Azure Key Vault	✅ Ja

Vigtigt!

Fordi disse variabler er knyttet til Key Vault, tilgås de i pipeline-YAML som $(aztenantid), $(azclientid), og $(azspnsecret). De er automatisk skjult i logs.

4.3 Variabelgruppe: `fabric_cicd_group_non_sensitive`

Denne variabelgruppe gemmer ikke-hemmelige konfigurationsværdier – specifikt arbejdsområdenavnene pr. miljø og Git-mappestien.

Trin til oprettelse

Navigér til Pipelines → Library i dit ADO-projekt.
Klik + Variabel gruppe.
Nævn det: fabric_cicd_group_non_sensitive
Tilføj følgende variable:

Variabelnavn	Værdi	Beskrivelse
`devWorkspaceName`	`MyProject-Dev`	Navnet på DEV Fabric-arbejdsområdet
`testWorkspaceName`	`MyProject-Test`	Navn på TEST Fabric-arbejdsområdet
`prodWorkspaceName`	`MyProject-Prod`	Navnet på PROD Fabric-arbejdsområdet
`gitDirectory`	`fabric`	Mappen i dit repo indeholder Fabric-item definitionerne

Klik på Gem.

💡 Sådan fungerer det i kode: Python-scriptet læser disse værdier ved hjælp af os.environ. For eksempel, når man deployerer til test, konstruerer scriptet variabelnavnet testWorkspaceName, konverterer det til store bogstaver (TESTWORKSPACENAME), og læser det fra miljøet – fordi ADO automatisk injicerer ikke-følsomme variabelgruppeværdier som miljøvariabler med store bogstaver.

4.4 ADO-miljøer og godkendelsesporte

ADO Environments giver dig mulighed for at tilføje manuelle godkendelsestjek, før udrulninger fortsætter. Dette er afgørende for at promovere til test og prod.

Trin til at skabe miljøer

Navigér til Pipelines → Miljøer i dit ADO-projekt.
Opret tre miljøer med de nøjagtige navne , der matcher dine grennavne:

Navn på miljø	Kræver godkendelse?	Godkendere
`dev`	❌ Nej (auto-deploy)	—
`test`	✅ Ja	Administrationsteam / Leder
`prod`	✅ Ja	Administrationsteam / Leder

For test og prod, klik på miljøet → ⋮ (Flere muligheder) → Godkendelser og marker → + Tilføj tjek → Godkendelser.
Tilføj de nødvendige godkendere.

Eksempel på miljøstatusvisning:

Environment	Status
udvikler	✅ #20260211.1 på fabric_cicd_pipeline
test	✅ #20260216.8 på fabric_cicd_pipeline
stikke	✅ #20260131.12 på fabric_cicd_pipeline

💡 Hvorfor miljøer? Pipeline-YAML bruger deployment jobs med environment: $(target_env). Når target_env er test eller prod, pauser ADO pipelinen og venter på, at den konfigurerede godkender(e) godkender, før den fortsætter.

4.5 Git Branch-strategi

Forgreningsstrategien er central i dette CI/CD-setup. Du har brug for tre langlivede forgrene:

Nøglepunkter

Gren	Forbundet til Fabric Workspace?	Formål
`dev`	✅ Ja-synkroniseret med DEV-arbejdsområdet	Sandhedens kilde. Ændringer foretaget i DEV-arbejdsområdet er udført her.
`test`	❌ Nej	Modtager forfremmede varer via PR-sammenfletning. Sporer, hvad der er deployeret til TEST.
`prod`	❌ Nej	Modtager forfremmede varer via PR-sammenfletning. Sporer, hvad der er deployeret til PROD.

Hvorfor kun `dev` er forbundet

Fabrics Git-integration synkroniserer arbejdsområde-elementer tovejs-mæssigt med en Git-gren.
Og-grenene testprod er ikke forbundet til arbejdsområder, fordi fabric-cicd pakken håndterer deployment direkte via Fabric REST API'en.
Disse brancher fungerer som en registrering af, hvilke produktversioner der er blevet promoveret til hvert miljø.

4.6 ADO Pipeline Opsætning

Opret en pipeline i ADO, der refererer til YAML-filen i dit repo.

Trin

Navigér til Pipelines → Pipelines → Ny pipeline.
Vælg Azure Repos Git og vælg dit repository.
Vælg Existing Azure Pipelines YAML file.
Peg på stien: Deploy-To-Fabric.yml (eller hvor du har placeret den).
Navngiv rørledningen: fabric_cicd_pipeline.
Under pipeline-tilladelser skal du sikre at den har adgang til:

Begge variable grupper (fabric_cicd_group_sensitive og fabric_cicd_group_non_sensitive)
Alle tre miljøer (dev, test, ) prod

Gem (løb ikke endnu).

⚠️ Tilladelsestip: Første gang pipelinen kører, kan ADO bede dig om at autorisere adgang til variablegrupperne og miljøerne. En ADO-administrator kan forhåndsgodkende disse under Pipeline → Settings.

5. Code Deep Dive: ADO Pipeline YAML

Fil:Deploy-To-Fabric.yml-placeret i GitHub-repoet, der blev downloadet tidligere.

Nedenfor er hele pipelinen med linje-for-linje annotationer.

# ──────────────────────────────────────────────────────────────
# TRIGGER: Runs automatically when code is pushed to dev, test, or prod
# Only triggers when changes are in the "fabric/" folder
# ──────────────────────────────────────────────────────────────
trigger:
 branches:
 include: [test, prod]
 paths:
 include:
  - fabric/**

🔍 Explanation-Trigger

Pipelinen udløses automatisk på commits til test OR-grenene prod . Den udløses ikke på dev-fordi dev kilde-grenen er forbundet til Fabric Git-integration.
Filteret paths sikrer, at det kun udløses , når filer i fabric/ mappen ændres, hvilket forhindrer unødvendige kørsler fra ændringer i dokumentation, scripts osv.
I praksis: når en PR er merged fra dev → test, lander merge commit på grenen test og udløser pipelinen, der målretter TEST-miljøet.

# ──────────────────────────────────────────────────────────────
# PARAMETERS: Runtime input-which Fabric item types to deploy
# ──────────────────────────────────────────────────────────────
parameters:
 - name: items_in_scope
 displayName: Enter Fabric items to be deployed
 type: string
 default: '["Notebook","DataPipeline","Lakehouse","SemanticModel","Report","VariableLibrary"]'

🔍 Explanation-Parameters

Dette definerer en runtime-parameter , der styrer, hvilke Fabric-items typer der er inden for deployeringens område.
Hvis denne parameter ikke er specificeret, vil alle objekttyper, der understøttes af pakken, fabric-cicd blive udrullet.
Dette fungerer også som en mulighed for selektiv udrulning – for eksempel kan du kun ["Notebook"] udrulle Notebooks.

⚠️ Advarsel om selektiv udrulning: Hvis du indsnævrer items_in_scope til en selektiv udrulning, bør du ikke kalde unpublish_all_orphan_items() Python-scriptet – da det vil fjerne elementer af de typeritems_in_scope, der findes i arbejdsområdet, men ikke er til stede i udgivelsesgrenen. For eksempel, hvis du kun ["Notebook"] deployer, og der er Notebooks i arbejdsområdet, som ikke er i branchen, vil de blive slettet – selvom de måske stadig er gyldige. Den fjerner ikke elementer af andre typer (som pipelines, rapporter osv.). Brug unpublish_all_orphan_items() kun, når grenen repræsenterer den komplette ønskede tilstand for de varetyper i omfanget.

# ──────────────────────────────────────────────────────────────
# VARIABLES: Environment-specific config & secrets
# ──────────────────────────────────────────────────────────────
variables:
 - name: target_env
 value: ${{ replace(variables['Build.SourceBranch'], 'refs/heads/', '') }}
 - group: fabric_cicd_group_sensitive
 - group: fabric_cicd_group_non_sensitive

🔍 Explanation-Variables

Variabel	Sådan fungerer det
`target_env`	Udtrækker dynamisk grennavnet fra `Build.SourceBranch`. For eksempel → `refs/heads/testtest`. Denne ene variabel driver hele den miljøbevidste adfærd.
`fabric_cicd_group_sensitive`	Trækker `aztenantid`, `azclientid`, `azspnsecret` fra Azure Key Vault under kørsel.
`fabric_cicd_group_non_sensitive`	Henter arbejdsområdenavne og `gitDirectory` som almindelige miljøvariabler.

# ──────────────────────────────────────────────────────────────
# STAGES & JOBS: Single deployment stage
# ──────────────────────────────────────────────────────────────
stages:
 - stage: DeployToFabric
 displayName: "Deploy to Fabric Workspace"
 jobs:
  - deployment: Deployment
  displayName: "Deploy Resources"
  environment: $(target_env)  # ◀── THIS triggers the approval gate!
  pool:
   name: Azure Pipelines
  strategy:
   runOnce:
   deploy:
    steps:

🔍 Explanation-Deployment Job

Element	Formål
`deployment:` (ikke `job:`)	Et deployment-job er nødvendigt for at bruge ADO-miljøer. Det muliggør godkendelsesporte, implementeringshistorik og revisionsspor.
`environment: $(target_env)`	Kortlægges til ADO-miljøet, der matcher grenens navn (`dev`, `test`, eller `prod`). Hvis godkendelser er konfigureret i det miljø, pauser pipelinen her, indtil den er godkendt.
`strategy: runOnce`	Udfører udrulningstrinene præcis én gang (i modsætning til kanarie- eller rullestrategier).

    steps:
    # Step 1: Checkout the source code
    - checkout: self

    # Step 2: Set up Python 3.12
    - task: UsePythonVersion@0
     inputs:
     versionSpec: '3.12'
     addToPath: true
     displayName: "Set up Python Environment"

    # Step 3: Install dependencies
    - script: |
     python -m pip install --upgrade pip
     pip install fabric-cicd
     displayName: "Install Fabric CICD Library"

    # Step 4: Run the deployment script
    - task: PythonScript@0
     inputs:
     scriptSource: 'filePath'
     scriptPath: '.deploy/deploy-to-fabric.py'
     arguments: >-
      --aztenantid $(aztenantid)
      --azclientid $(azclientid)
      --azspsecret $(azspnsecret)
      --items_in_scope ${{ parameters.items_in_scope }}
      --target_env $(target_env)
     displayName: 'Run deployment using fabric-cicd'

🔍 Explanation-Steps

Trin	Hvad det gør
Tjek ud	Klone repositoryet, så pipelinen har adgang til Fabric-item definitionerne i `fabric/` mappen og deployment-scriptet.
Python-opsætning	Installerer Python 3.12 på build-agenten. Pakken `fabric-cicd` kræver Python 3.10+.
Installationsafhængigheder	Installerer `fabric-cicd` pakken fra PyPI. Dette er Microsofts officielle bibliotek for automatiserede Fabric-implementeringer.
Kør script	Udfører Python-implementeringsscriptet og sender alle nødvendige argumenter: SPN-legitimationsoplysninger (fra Key Vault), listen over itemtyper der skal deployes, og målmiljøets navn.

⚠️ Sikkerhedsnote: , $(aztenantid)$(azclientid), og $(azspnsecret) værdierne hentes fra Key Vault-linkede variabelgruppen. De er automatisk skjult i pipeline-logs — du vil se *** det i stedet for faktiske værdier.

6. Code Deep Dive: Python Deployment Script

Fil:.deploy/deploy-to-fabric.py — placeret i GitHub-repoet, der blev downloadet tidligere.

Dette er kernen i udsendelsen. Lad os gennemgå hver sektion.

6.1 Import og afhængigheder

import os, argparse, requests, ast
from fabric_cicd import (
 FabricWorkspace,
 publish_all_items,
 unpublish_all_orphan_items,
 change_log_level,
 append_feature_flag,
)
from azure.identity import ClientSecretCredential

Importér	Formål
`os`	Adgangsmiljøvariabler (ikke-følsomme variabelgruppeværdier)
`argparse`	Parse kommandolinjeargumenter, der blev sendt fra pipelinen
`requests`	Lav HTTP-kald til Fabric REST API'en (til opslag af arbejdsområde-ID'er)
`fabric_cicd`	Microsofts bibliotek — håndterer det tunge arbejde med at implementere Fabric-elementer
`ClientSecretCredential`	Azure Identity library — autentificerer ved hjælp af SPN-legitimationsoplysninger

6.2 Workspace ID opslagsfunktion

def get_workspace_id(p_ws_name, p_token):
 url = "https://api.fabric.microsoft.com/v1/workspaces"
 headers = {
  "Authorization": f"Bearer {p_token.token}",
  "Content-Type": "application/json"
 }
 response = requests.get(url, headers=headers)
 ws_id = ''
 if response.status_code == 200:
  workspaces = response.json()["value"]
  for workspace in workspaces:
   if workspace["displayName"] == p_ws_name:
    ws_id = workspace["id"]
    return workspace["id"]
  if ws_id == '':
   return f"Error: Workspace {p_ws_name} could not found."
 else:
  return f"Error: {response.status_code}, {response.text}"

Hvad dette gør:

Kalder Fabric REST API (GET /v1/workspaces) for at liste alle arbejdsområder, som SPN har adgang til.
Søger efter et arbejdsområde, der displayName matcher navnet på målarbejdsområdet.
Returnerer arbejdsområdets GUID , hvis det findes, eller en fejlmeddelelse, hvis ikke.

💡 Hvorfor ikke hardkode arbejdsområde-ID'et? Ved dynamisk at slå det op efter navn er scriptet mere modstandsdygtigt over for arbejdsområde-rekreation og undgår at gemme GUID'er i variabelgruppen.

6.3 Funktionsflag & Logning

append_feature_flag("enable_shortcut_publish")
change_log_level("DEBUG")

Indstilling	Formål
`enable_shortcut_publish`	Muliggør implementering af Lakehouse-genveje — en funktion, der kan vælges via feature-flag i `fabric-cicd`.
`DEBUG` log-niveau	Leverer omfattende output under udrulning — meget hjælpsomt til fejlfinding. Argumentet `"DEBUG"` er valgfrit — kald `change_log_level()` uden det muliggør mere ordrig logning. Fjern change_log_level(), hvis debug-logs ikke er nødvendige.

6.4 Argumentparsing

parser = argparse.ArgumentParser(description='Process Azure Pipeline arguments.')
parser.add_argument('--aztenantid', type=str, help='tenant ID')
parser.add_argument('--azclientid', type=str, help='SP client ID')
parser.add_argument('--azspsecret', type=str, help='SP secret')
parser.add_argument('--target_env', type=str, help='target environment')
parser.add_argument('--items_in_scope', type=str, help='Defines the item types to be deployed')
args = parser.parse_args()

Disse argumenter overføres fra pipeline YAML-trinnet. Parseren gør dem tilgængelige som args.aztenantid, args.azclientid, osv.

6.5 Autentificering

token_credential = ClientSecretCredential(
 client_id=args.azclientid,
 client_secret=args.azspsecret,
 tenant_id=args.aztenantid,
)

Dette opretter et Azure-legitimationsobjekt ved brug af Service Principals klient-ID, hemmelighed og lejer-ID. Denne legitimation bruges begge til:

Kald af Fabric REST API (workspace lookup)
Aflevering til FabricWorkspace udsendelsen fabric-cicd

6.6 Dynamisk arbejdsområdeopløsning

tgtenv = args.target_env       # e.g., "test"
ws_name = f'{tgtenv}WorkspaceName'    # e.g., "testWorkspaceName"
workspace_name = os.environ[ws_name.upper()]  # reads TESTWORKSPACENAME from env vars

Den smarte del: Variabelgruppen fabric_cicd_group_non_sensitive indeholder variabler som devWorkspaceName, testWorkspaceName, osv. ADO indsætter disse som store miljøvariabler. Scriptet konstruerer dynamisk variabelnavnet baseret på målmiljøet.

# Generate a token and look up the workspace ID
resource = 'https://api.fabric.microsoft.com/'
scope = f'{resource}.default'
token = token_credential.get_token(scope)

lookup_response = get_workspace_id(workspace_name, token)
if lookup_response.startswith("Error"):
 raise ValueError(f"{lookup_response}. Perhaps workspace name is set incorrectly...")
else:
 wks_id = lookup_response

6.7 Initialiser FabricWorkspace & Udrul

repository_directory = os.environ["GITDIRECTORY"] # e.g., "fabric"

item_types = args.items_in_scope.strip("[]").split(",") # Convert string to list

target_workspace = FabricWorkspace(
 workspace_id=wks_id,
 environment=tgtenv,
 repository_directory=repository_directory,
 item_type_in_scope=item_types,
 token_credential=token_credential,
)

# Deploy!
publish_all_items(target_workspace)
unpublish_all_orphan_items(target_workspace)

Metode	Hvad det gør
`FabricWorkspace(...)`	Initialiserer deployment-konteksten — læser itemdefinitioner fra Git-repoet, indlæser parameterfiler til GUID-udskiftning og forbereder deploymentplanen.
`publish_all_items()`	Udruler alle elementer i scope til målarbejdsområdet. Håndterer oprettelse af nye elementer og opdatering af eksisterende.
`unpublish_all_orphan_items()`	Fjerner elementer fra målarbejdsområdet, som ikke længere er til stede i Git-grenen — og holder arbejdsområdet rent.

⚠️ VIGTIGT — Forståelse unpublish_all_orphan_items(): Denne metode vil slette elementer af de typer, der er angivet i items_in_scope fra målarbejdsområdet, som ikke er til stede i release-grenen (dvs. den gren, der bruges som kildekode for fabric-cicd pakken). Den vil ikke røre genstande af andre typer. I denne vejledning indeholder grenen testalle elementer, der er beregnet til TEST-arbejdsområdet, så det er sikkert at kalde unpublish_all_orphan_items() — den fjerner kun elementer, der bevidst er blevet slettet fra grenen.

Men hvis du laver en selektiv udrulning (f.eks. kun udrulning af Notebooks via en indsnævret udrulning items_in_scope), skal du være forsigtig med unpublish_all_orphan_items() — det vil slette alle Notebooks i arbejdsområdet, som ikke er i branchen, selvom de stadig er gyldige og simpelthen ikke var en del af den selektive frigivelse.

💡 Tip:unpublish_all_orphan_items() Understøtter at udelukke specifikke genstande fra fjernelse ved at passere et regex-mønster. Alle elementer, hvis navne matcher regexen, vil blive bevaret i arbejdsområdet, selvom de ikke er i kilde-grenen. For flere detaljer og brugseksempler, se den officielle API-reference.

7. Code Deep Dive: Parameterfiler (GUID-erstatning)

Her sker magien — hvordan %%configure GUID'er byttes om i hvert miljø.

Sådan fungerer det

Pakken fabric-cicd leder efter en fil, der er navngivet parameter.yml i mappen (eller roden i .deploy repositoryet). Denne fil definerer find-og-erstat-regler , der anvendes på varedefinitioner før implementering.

💡 Tip: Find-and-placer-funktionen parameter.yml understøtter mange tilgange ud over det, der vises i denne vejledning — herunder regex-mønstre, filbaserede udskiftninger og mere. For den fulde liste over muligheder og avanceret brug, se den officielle dokumentation: 👉fabric-cicd Parameter File Documentation

💡 Tip — variabelbibliotek: Det anbefales at udnytte variabelbiblioteket , når det er muligt, til at håndtere miljøspecifikke værdier frem for udelukkende at stole på find_replace parameterfiler. Variable Libraries giver en centraliseret, genanvendelig måde at håndtere konfiguration på tværs af miljøer. For mere information, se Kom i gang med variable biblioteker.

Fil:`parameter.yml` — placeret i GitHub-repoet, der blev downloadet tidligere.

7.1 Parameterfilstruktur

find_replace:
 - find_value: "bfddf0b6-5b74-461a-a963-e89ddc32f852"  # DEV Workspace ID
 replace_value:
  test: " $workspace.$id"         # Replaced with TEST workspace ID
  prod: " $workspace.$id"         # Replaced with PROD workspace ID

🔍 Forståelse af hver indgang

Indgang 1 — Udskiftning af arbejdsområde-ID

- find_value: "bfddf0b6-5b74-461a-a963-e89ddc32f852" # DEV Workspace ID
 replace_value:
 test: " $workspace.$id" # Auto-resolves to the TEST workspace's actual ID
 prod: " $workspace.$id" # Auto-resolves to the PROD workspace's actual ID

find_value: GUID'en i notesbogens %%configure kommando — dette er DEV-arbejdsområde-ID'et.
replace_value: Der $workspace.$id er et indbygget tokenfabric-cicd, der automatisk bliver løst til målarbejdsområdets ID ved udrulning.
Da dev ikke er opført i replace_value, erstattes GUID'en kun, når man deployerer til test eller prod.

Indgang 2 — Udskiftning af Lakehouse ID

- find_value: "981f2f9a-0436-4942-b158-019bd73cdf1c" # DEV DemoLakehouse GUID
 replace_value:
 test: "$items.Lakehouse.DemoLakehouse.$id" # Resolves to TEST Lakehouse ID
 prod: "$items.Lakehouse.DemoLakehouse.$id" # Resolves to PROD Lakehouse ID

$items.Lakehouse.DemoLakehouse.$id er et dynamisk token, der slår navnet Lakehouse DemoLakehouse op i målarbejdsområdet og returnerer dets ID.
Mønster:$items.<ItemType>.<ItemName>.$id

Entry 3 — SQL Endpoint ID Udskiftning (Dynamisk Notation)

- find_value: "91280ad0-b76e-4c98-a656-95d8f09a5e28" # DEV SQL Endpoint GUID
 replace_value:
 test: $items.Lakehouse.DemoLakehouse.$sqlendpointid # Resolved dynamically at deploy time
 prod: $items.Lakehouse.DemoLakehouse.$sqlendpointid # Resolved dynamically at deploy time

I stedet for at hardkode SQL-endpointets GUID for hvert miljø (f.eks. 204fd20c-e34c-4bef-9dce-4ecf53b0e878 for TEST eller 29bda5ec-ebc7-466e-a618-ef5bbea75e13 for PROD), bruger denne post dynamisk notation — $items.Lakehouse.DemoLakehouse.$sqlendpointid.
Pakken fabric-cicd løser dette ved udrulning ved at slå SQL-endpoint-ID'et for DemoLakehouse Lakehouse op i målarbejdsområdet. Dette eliminerer behovet for manuelt at finde og vedligeholde SQL-endpoint-GUID'er på tværs af miljøer.

7.2 Dynamisk Tokens Oversigt

Token	Beslutter sig for at
`$workspace.$id`	Målarbejdsområdets GUID
`$items.Lakehouse.<name>.$id`	GUID for et søhus navngivet `<name>` i målarbejdsområdet
`$items.<ItemType>.<ItemName>.$id`	Generisk mønster for enhver varetype
`$items.Lakehouse.<name>.$sqlendpointid`	SQL-endpointets GUID for en Lakehouse (løst dynamisk)

7.3 Feature Branch Parameterfil (Avanceret)

For teams, der bruger feature branches (ikke kun dev), findes der en variant af parameterfiler, hvor alle tre miljøer (dev, test, prod) har erstatninger:

- find_value: "d34e3a2a-96ba-4461-9a80-496894ca4cda" # Feature branch Workspace ID
 replace_value:
 dev: " $workspace.$id"
 test: " $workspace.$id"
 prod: " $workspace.$id"

Dette er nyttigt, når udviklere arbejder i deres egne Fabric-arbejdsområder og har brug for udskiftning af GUIDs, selv når de deployer til DEV.

8. Udrulningsflow: Gennemgang fra ende til ende

Her er hele flowet, når Alex vil forfremme en notesbog fra udvikler til test:

Trin 1: 🔧 Udvikleren laver ændringer i DEV

Alex ændrer Notebooken IngestApiData i DEV Fabric-arbejdsområdet (f.eks. tilføjer en ny celle). Fabrics Git-integration synkroniserer denne ændring automatisk til grenen dev (eller via en manuel commit).

Trin 2: 📋 Opret en pull request (udvikler → test)

Alex opretter en pull request i ADO:

Kildeafdeling:dev
Mål-afdeling:test
Titel: "Promover ændrede notesbogselementer til test"

PR'en indeholder alle de ændrede elementer, som Alex ønsker at implementere i TEST-miljøet.

Trin 3: ✅ PR-godkendelse og fusion

En anmelder (eller Alex' administrator) gennemgår PR'en:

Inspicerer ændringerne i Notebook-definitionsfilerne
Godkender PR
Fuldfører sammenfletningen → Ændringerne er nu på grenen test

Trin 4: 🚀 Pipeline Auto-triggere

Merge-committet på grenen test udløser fordi fabric_cicd_pipeline :

Grenen test er i triggerens include liste
Ændringerne er inden for stien fabric/

Pipelinen begynder eksekveringen:

Pipeline Variable: target_env = "test"

Trin 5: ⏸️ Godkendelsesport

Fordi pipelinen bruger environment: $(target_env) ogtesttarget_env = , tjekker ADO testmiljøet for godkendelsesporte.

Pipelinen pauser og sender en notifikation til den konfigurerede godkender(e).
Administratoren gennemgår og klikker på Godkend.

Trin 6: ⚡ Scriptudførelse

Efter godkendelse følger pipelinen:

⚙️ Opsætter Python 3.12
📦 Installationer fabric-cicd
▶️ Kører deploy-to-fabric.py med:

SPN-legitimationsoplysninger fra Key Vault
--target_env test
--items_in_scope ["Notebook","Lakehouse",...]

Python-scriptet:

🔐 Autentificerer ved hjælp af SPN'en
🔍 Løser testWorkspaceName → slår arbejdsområdets ID op
📄 Indlæser parameter.yml og anvender GUID-erstatninger
📤 Publicerer elementer til TEST-arbejdsområdet
🧹 Rydder op i forældreløse genstande

Trin 7: ✅ Udsendelse fuldført

Notebooken er nu udrullet til TEST-arbejdsområdet med:

✅ Den nyligt tilføjede celle til stede
✅ Alle GUID'er er erstattet %%configure med TEST-miljøværdier

9. Validering: Bekræftelse af en vellykket udsendelse

Når pipelinen er færdig, valideres at implementeringen var succesfuld:

Tjek 1: Rørledningsstatus

I ADO → Pipelines → Runs, bekræft at pipeline-kørslen viser ✅ Succesfuld for test miljøet.

Tjek 2: Notesbogsindhold i TEST-arbejdsområdet

Åbn notesbogen IngestApiData i TEST Fabric-arbejdsområdet og bekræft:

Ny celle er til stede: Den nyligt tilføjede celle, der blev udviklet i DEV, burde nu optræde i TEST-versionen af notebooken.
GUID'er erstattes i celle 1: I kommandoen %%configure (typisk i Celle 1), verificér at:

GUID-type	Bør dukke op	Bør IKKE vises
Id for arbejdsområde	TEST arbejdsområde ID	~~DEV workspace ID~~
DemoLakehouse ID	TEST Lakehouse ID	~~DEV Lakehouse ID~~
SQL Endpoint ID	TEST SQL Endpoint ID (løst dynamisk)	~~DEV SQL Endpoint ID (`91280ad0-...`)~~

✅ Succes! Cellen %%configure peger nu på TEST-søhuse, og det nye udviklingsarbejde er blevet renligt promoveret.

10. Fejlfinding og almindelige faldgruber

Problem	Årsag	Løsning
Pipeline fejler med "Arbejdsområde ikke fundet"	Workspace-navnet i variabelgruppen matcher ikke Fabric	Dobbelttjek `testWorkspaceName` i `fabric_cicd_group_non_sensitive` variabelgruppen
GUID'er bliver ikke erstattet	`parameter.yml` ikke på det forventede sted	Sørg for, at filen ligger i `.deploy/` mappen sammen med scriptet eller i repository-roden
`Permission denied` fejl fra Fabric API	SPN mangler adgang til arbejdsområdet	Tilføj SPN'en som medlem eller administrator på det målrettede Fabric-arbejdsområde
Pipeline udløses ikke ved merge	Stifilter-mismatch	Sørg for, at dine Fabric-elementer er i `fabric/` mappen i repoet
`ModuleNotFoundError: fabric_cicd`	Pakke ikke installeret	Sørg for, at skridtet `pip install fabric-cicd` er til stede og lykkes
Godkendelsesmeddelelse ikke modtaget	Miljø ikke konfigureret	Kontroller at ADO-miljøets navn matcher `target_env` præcist (kasusfølsomt)
SQL Endpoint GUID ikke erstattet	Dynamisk notation forkert konfigureret	Sørg for, at `$items.Lakehouse.<name>.$sqlendpointid` syntaksen er korrekt, og at Lakehouse findes i målarbejdsområdet
`os.environ` Nøglefejl	Variabelgruppe ikke knyttet til pipeline	Autoriser pipelinen til adgang `fabric_cicd_group_non_sensitive`
Fejl i funktionsflag for genveje	`fabric-cicd` version for gammel	Opgrader `fabric-cicd` til den nyeste version: `pip install fabric-cicd --upgrade`

11. Resumé

Denne vejledning demonstrerede en produktionskvalitet CI/CD-arbejdsgang for Microsoft Fabric ved brug af Azure DevOps:

Komponent	Hvad vi har sat op
Azure Key Vault	Gemmer sikkert SPN-legitimationsoplysninger (Lejer-ID, Klient-ID, Hemmelig)
ADO variabelgrupper	Én Key Vault–linked (følsom), én almindelig (arbejdsområdenavne)
ADO-miljøer	`dev`, `test`, `prod` med godkendelsesporte på `test` og `prod`
Git-forgreninger	`dev` (forbundet til Fabric), `test` og `prod` (udrulningsmål)
Pipeline YAML	Auto-triggere ved grensammenfletning, parameteriseret udvælgelse af elementer
Python-script	Autentificerer via SPN, løser arbejdsområde, deployerer via `fabric-cicd`
Parameterfil	Bytter DEV GUIDs med miljøspecifikke værdier ved brug af dynamiske tokens

Vigtige takeaways

Kun grenen dev er forbundet til et Fabric-arbejdsområde — test og prod grenene fungerer som deployeringsposter.
fabric-cicd's parameterfiler håndterer automatisk udskiftning af GUID ved hjælp af dynamiske tokens som $workspace.$id og $items.Lakehouse.<name>.id.
ADO-miljøer med godkendelser giver governance — ingen udrulning til højere miljøer uden eksplicit godkendelse.
Service Principal-autentificering via Azure Key Vault sikrer, at legitimationsoplysninger aldrig bliver eksponeret i kode eller logfiler.

📚 Yderligere læsning:

fabric-cicd Dokumentation

Microsoft Fabric Git Integration

Azure DevOps Environments & Approvals

Azure Key Vault linked Variable Groups

Feedback

Var denne side nyttig?

Last updated on 2026-02-20

Del via

🚀CI/CD for Microsoft Fabric ved brug af Azure DevOps og Python-pakken fabric-cicd

1. Scenarieoversigt

Udfordringen

Hvad Alex forventer

Værktøjerne

2. Arkitekturdiagram

3. Forudsætninger

Download kildefilerne

4. Initial Azure DevOps Setup

4.1 Azure Key Vault Integration

Steps to Set Up Azure Key Vault

4.2 Variabelgruppe: fabric_cicd_group_sensitive

Trin til oprettelse

4.3 Variabelgruppe: fabric_cicd_group_non_sensitive

Trin til oprettelse

4.4 ADO-miljøer og godkendelsesporte

Trin til at skabe miljøer

4.5 Git Branch-strategi

Nøglepunkter

Hvorfor kun dev er forbundet

4.6 ADO Pipeline Opsætning

Trin

5. Code Deep Dive: ADO Pipeline YAML

🔍 Explanation-Trigger

🔍 Explanation-Parameters

🔍 Explanation-Variables

🔍 Explanation-Deployment Job

🔍 Explanation-Steps

6. Code Deep Dive: Python Deployment Script

6.1 Import og afhængigheder

6.2 Workspace ID opslagsfunktion

6.3 Funktionsflag & Logning

6.4 Argumentparsing

6.5 Autentificering

6.6 Dynamisk arbejdsområdeopløsning

6.7 Initialiser FabricWorkspace & Udrul

7. Code Deep Dive: Parameterfiler (GUID-erstatning)

Sådan fungerer det

Fil:parameter.yml — placeret i GitHub-repoet, der blev downloadet tidligere.

7.1 Parameterfilstruktur

🔍 Forståelse af hver indgang

Indgang 1 — Udskiftning af arbejdsområde-ID

Indgang 2 — Udskiftning af Lakehouse ID

Entry 3 — SQL Endpoint ID Udskiftning (Dynamisk Notation)

7.2 Dynamisk Tokens Oversigt

7.3 Feature Branch Parameterfil (Avanceret)

8. Udrulningsflow: Gennemgang fra ende til ende

Trin 1: 🔧 Udvikleren laver ændringer i DEV

Trin 2: 📋 Opret en pull request (udvikler → test)

Trin 3: ✅ PR-godkendelse og fusion

Trin 4: 🚀 Pipeline Auto-triggere

Trin 5: ⏸️ Godkendelsesport

Trin 6: ⚡ Scriptudførelse

Trin 7: ✅ Udsendelse fuldført

9. Validering: Bekræftelse af en vellykket udsendelse

Tjek 1: Rørledningsstatus

Tjek 2: Notesbogsindhold i TEST-arbejdsområdet

10. Fejlfinding og almindelige faldgruber

11. Resumé

Vigtige takeaways

Feedback

Yderligere ressourcer

🚀CI/CD for Microsoft Fabric ved brug af Azure DevOps og Python-pakken `fabric-cicd`

4.2 Variabelgruppe: `fabric_cicd_group_sensitive`

4.3 Variabelgruppe: `fabric_cicd_group_non_sensitive`

Hvorfor kun `dev` er forbundet

Fil:`parameter.yml` — placeret i GitHub-repoet, der blev downloadet tidligere.