🚀 CI/CD Microsoft Fabricille Azure DevOpsin ja Python-paketin fabric-cicd avulla

Tässä opastuaalissa käytä fabric-cicd Python-kirjastoa edistääksesi muutettuja kohteita (kuten tiettyä muistikirjaa) dev-työtilasta testityötilaan ja lopulta prodiin.

1. Skenaarion yleiskatsaus

Tapaa Alex — kehittäjä, joka työskentelee Fabric:n kanssa.

Alexin tiimi rakentaa muistikirjoja, dataputkia, semanttisia malleja ja raportteja kehitystyötilassa Fabric -työtilassa. Kun ominaisuudet ovat valmiita, Alexin täytyy edistää muuttuneita kohteita (kuten tietty muistikirja) dev-työtilasta testityötilaan ja lopulta prodiin.

Haaste

Alexin muistikirjat käyttävät %%configure taikakomentoa kiinnittääkseen ne tiettyyn järvenmökkiin. Tämä komento tarkoittaa, että muistikirjan määrittelyt sisältävät kovakoodattuja GUID-tiedostoja — työtilan ID:t, Lakehouse-ID:t ja SQL-päätepisteiden ID:t — jotka vaihtelevat eri ympäristöissä.

Mitä Alex odottaa

Työkalut

2. Arkkitehtuurikaavio

Seuraava kaavio havainnollistaa tutoriaalin kulkua.

3. Ennakkovaatimukset

Ennen kuin aloitat, varmista, että sinulla on seuraavat asiat kunnossa:

💡 Vinkki: Jotta Service Principal -pääsy voidaan ottaa käyttöön Fabricissa, Fabric-ylläpitäjän on otettava käyttöön "Service Principals can use Fabric-rajapintoja " Fabric Admin Portalissa Tenant Settings -kohdassa.

Lataa lähdetiedostot

1. Forkkaa Fabric-sample-varasto GitHub-tilillesi.
2. Kloonaa haarukkasi paikalliseen koneeseen:

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

4. Alkuperäinen Azure DevOps -asetus

Tässä osiossa käydään läpi kaikki Azure DevOps -resurssit, jotka sinun täytyy konfiguroida ennen kuin putki voi käynnistyä.

4.1 Azure Key Vault Integration

Service Principal -tunnuksiasi (Tenant ID, Client ID ja Secret) ei koskaan tulisi tallentaa tavallisena tekstinä. Sen sijaan tallenna ne Azure Key Vaultiin.

Azure Key Vaultin perustamisen vaiheet

1. Luo avainholvi Azure-portaalissa (tai käytä olemassa olevaa).
2. Lisää kolme salaisuutta:

3. Apurahan saatavuus: ADO-palveluyhteydellä (tai ADO-projektin identiteetillä) täytyy olla Get ja List -oikeudet salaisuuksiin Key Vaultin pääsykäytännöissä (tai RBAC-roolissa Key Vault Secrets User).

   

4.2 Muuttuva ryhmä: fabric_cicd_group_sensitive

Tämä muuttujaryhmä on linkitetty Azure Key Vaultiin, mikä tarkoittaa, että salaiset arvot haetaan ajonaikaisesti eivätkä koskaan paljastu ADO UI:ssa.

Luomisen vaiheet

1. Siirry ADO-projektisi Pipelines → Libraryyn .
2. Klikkaa + Muuttujaryhmä.
3. Nimeä se: fabric_cicd_group_sensitive
4. Kytke päälle Linkin salaisuudet Azure-avainholvista muuttujina.
5. Valitse Azure-tilauksesi ja Key Vault.
6. Klikkaa + Lisää ja valitse kolme salaisuutta:

• aztenantid
• azclientid
• azspnsecret

7. Valitse Tallenna.

4.3 Muuttujaryhmä: fabric_cicd_group_non_sensitive

Tämä muuttujaryhmä tallentaa ei-salaiset konfiguraatioarvot – erityisesti työtilan nimet ympäristökohtaisesti ja Git-hakemistopolun.

Luomisen vaiheet

1. Siirry ADO-projektisi Pipelines → Libraryyn .
2. Klikkaa + Muuttujaryhmä.
3. Nimeä se: fabric_cicd_group_non_sensitive
4. Lisää seuraavat muuttujat:

5. Valitse Tallenna.

   

💡 Miten se toimii koodissa: Python-skripti lukee nämä arvot käyttäen os.environ. Esimerkiksi, kun skripti otetaan käyttöön , testse rakentaa muuttujan nimen testWorkspaceName, muuntaa sen isoksi (TESTWORKSPACENAME), ja lukee sen ympäristöstä – koska ADO injektoi automaattisesti ei-herkkiä muuttujaryhmäarvoja ympäristömuuttujina isolla kirjaimella.

4.4 ADO-ympäristöt ja hyväksyntäportit

ADO Environments mahdollistaa manuaalisten hyväksyntätarkistusten lisäämisen ennen käyttöönottoa. Tämä on ratkaisevaa markkinoinnissa test ja prod.

Ympäristöjen luomisen vaiheet

1. Siirry ADO-projektissasi Pipelines → Environments -kohtaan.
2. Luo kolme ympäristöä , joiden nimet vastaavat tarkasti haaranimiäsi:

3. Ja testprod, klikkaa ympäristöä → ⋮ (Lisää vaihtoehtoja) → Hyväksynnät ja tarkistukset → + Lisää, tarkista → Hyväksynnät.

4. Lisää vaaditut hyväksyjät.

   

Esimerkkiympäristön tilanäkymä:

💡 Miksi ympäristöt? Pipeline YAML käyttää deployment töitä, joissa environment: $(target_env)on . Kun target_env on test tai prod, ADO pysäyttää putken ja odottaa konfiguroidun hyväksyjän hyväksyntää ennen etenemistä.

4.5 Git-haaran strategia

Haarautumisstrategia on keskeinen tässä CI/CD-järjestelmässä. Tarvitset kolme pitkäikäistä haaraa:

Keskeiset kohdat

Miksi vain dev on yhteydessä

• Fabricin Git Integration synkronoi työtilan alukset kaksisuuntaisesti Git-haaran kanssa.
• Ja-haarat testprodeivät ole yhteydessä työtiloihin, koska fabric-cicd paketti hoitaa käyttöönoton suoraan Fabric REST API:n kautta.
• Nämä haarat toimivat tallenteena siitä, mitkä tuoteversiot on ylennetty kuhunkin ympäristöön.

4.6 ADO Pipeline Setup

Luo ADO:ssa putkisto, joka viittaa YAML-tiedostoon repositasi.

Vaiheet

1. Siirry kohtaan Pipelines → Pipelines → New pipeline.
2. Valitse Azure Repos Git ja valitse oma repositoriosi.
3. Valitse Existing Azure Pipelines YAML -tiedosto.
4. Osoita polkua: Deploy-To-Fabric.yml (tai mihin ikinä olet sen sijoittanut).
5. Nimeä putkisto: fabric_cicd_pipeline.
6. Putkikäyttöoikeuksien kohdalla varmista, että sillä on pääsy seuraaviin:

• Molemmat muuttujaryhmät (fabric_cicd_group_sensitive ja fabric_cicd_group_non_sensitive)
• Kaikki kolme ympäristöä (dev, test, prod)

7. Tallenna (älä vielä juokse).

⚠️ Käyttöoikeusvinkki: Ensimmäisellä kerralla, kun putki käynnistyy, ADO saattaa pyytää sinua valtuuttamaan pääsyn muuttujaryhmiin ja ympäristöihin. ADO-ylläpitäjä voi ennakkovaltuuttaa nämä Pipeline → Settings -osiossa.

5. Code Deep Dive: ADO Pipeline YAML

Tiedosto:Deploy-To-Fabric.yml- sijaitsee aiemmin ladattu GitHubin reposito.

Alla on koko tuotantoputki rivikohtaisine merkintöineen.

# ──────────────────────────────────────────────────────────────
# 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

• Putki käynnistyy automaattisesti commit-toimintojen yhteydessä tai testprod haarautumiseen. Se ei käynnisty dev-koska dev lähdehaara on yhdistetty Fabric Git -integraatioon.
• Suodatin paths varmistaa, että se aktivoituu vain , kun hakemiston tiedostoja fabric/ muutetaan, estäen tarpeettomat suoritukset dokumentaatioiden, skriptien ym. muutoksissa.
• Käytännössä: kun PR yhdistetään dev → test:stä, yhdistämiscommitus päätyy haarautumiseen test , jolloin putki kohdistuu TEST-ympäristöön.

# ──────────────────────────────────────────────────────────────
# 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

• Tämä määrittelee ajonaikaisen parametrin , joka säätelee, mitkä Fabric-elementityypit kuuluvat käyttöönoton piiriin.
• Jos tätä parametria ei ole määritelty, kaikki paketin tukemat fabric-cicd alkiotyypit otetaan käyttöön.
• Tämä parametri toimii myös vaihtoehtona valikoivaan käyttöönottoon. Esimerkiksi voisit läpäistä vain ["Notebook"] pelkkien muistikirjojen käyttöönoton.

⚠️ Selective Deployment Warning: Jos items_in_scope rajaat valikoivan käyttöönoton, älä kutsu unpublish_all_orphan_items() Python-skriptiä. Tämä funktio poistaa ne tyypit items_in_scope , jotka on määritelty työtilassa, mutta joita ei ole julkaisuhaarassa. Esimerkiksi, jos otat vain ["Notebook"] käyttöön ja työtilassa on muistikirjoja, jotka eivät ole haarautumassa, funktio poistaa ne – vaikka ne saattavat silti olla voimassa. Se ei poista muiden tyyppien kohteita (kuten putkistoja, raportteja ja muita tyyppejä). Käytä unpublish_all_orphan_items() vain, kun haara edustaa koko haluttua tilaa kohdetyyppien alkiotyypeille.

# ──────────────────────────────────────────────────────────────
# 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

# ──────────────────────────────────────────────────────────────
# 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 Työ

    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

⚠️ Turvallisuushuomautus: , $(aztenantid)$(azclientid), ja $(azspnsecret) arvot haetaan Key Vaultiin sidottu muuttujaryhmästä. Ne peitetään automaattisesti putkilokeihin — *** näet arvot todellisten arvojen sijaan.

6. Koodin syväsukellus: Pythonin käyttöönottoskripti

Tiedosto:.deploy/deploy-to-fabric.py — joka sijaitsee aiemmin ladatussa GitHub-repositoissa.

Tämä on komennuksen ydin. Käydään läpi jokainen osio.

6.1 Tuonnit ja riippuvuudet

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

6.2 Työtilan ID-hakutoiminto

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}"

Mitä tämä tekee:

1. Kutsuu Fabric REST API :n (GET /v1/workspaces) listaamaan kaikki työtilat, joihin SPN:llä on pääsy.
2. Etsii työtilan, joka displayName vastaa kohdetyötilan nimeä.
3. Palauttaa työtilan GUID , jos se löytyy, tai virheilmoituksen, jos ei.

💡 Miksi et kovakoodaisi työtilan ID:tä? Kun skripti etsitään dynaamisesti nimellä, skripti on kestävämpi työtilan uudelleenluomiselle ja välttää GUID-tiedostojen tallentamisen muuttujaryhmään.

6.3 Ominaisuusliput ja lokitus

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

6.4 Argumenttien jäsentäminen

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

Nämä argumentit välitetään putkiston YAML-vaiheesta. Jäsentäjä tekee ne saataville muodossa args.aztenantid, args.azclientid, jne.

6.5 Todennus

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

Tämä luo Azure-tunnistetiedoston käyttäen Service Principalin asiakas-ID:tä, salaisuutta ja tenant-ID:tä. Tätä tunnistetta käytetään molempiin:

1. Fabric REST API:n kutsuminen (workspace lookup)
2. Siirtyminen FabricWorkspace sijoitukseen fabric-cicd

6.6 Dynaaminen työtilan resoluutio

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

Nerokas osa: Muuttujaryhmä fabric_cicd_group_non_sensitive sisältää muuttujia kuten devWorkspaceName, testWorkspaceName, jne. ADO injektoi nämä isona ympäristömuuttujina. Skripti rakentaa muuttujan nimen dynaamisesti kohdeympäristön perusteella.

# 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 Alusta FabricWorkspace ja ota käyttöön

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)

⚠️ TÄRKEÄÄ — Ymmärtäminen unpublish_all_orphan_items(): Tämä menetelmä poistaa kohdetyötilasta määritellyt kohteet items_in_scope , joita ei ole julkaisuhaarassa (eli haara, jota käytetään paketin lähteenä fabric-cicd ). Se ei koske muihin esineisiin. Tässä opastuaalissa haara testsisältää kaikki TEST-työtilaan tarkoitetut alit, joten sitä voi turvallisesti kutsua unpublish_all_orphan_items() — se poistaa vain haarautumisesta tarkoituksella poistetut kohteet.

Kuitenkin, jos teet valikoivan käyttöönoton (esimerkiksi otat käyttöön vain muistikirjoja kaventuneen items_in_scopekautta), ole varovainen .unpublish_all_orphan_items() Se poistaa kaikki työtilassa olevat muistikirjat, jotka eivät ole haarauksessa, vaikka ne olisivat edelleen voimassa eivätkä olleet osa valikoivaa julkaisua.

💡 Vinkki:unpublish_all_orphan_items() tukee tiettyjen kohteiden poistamista siirtämällä regex-malli. Kaikki kohteet, joiden nimet vastaavat regexiä, säilytetään työtilassa, vaikka ne eivät olisikaan lähdehaarassa. Lisätietoja ja käyttöesimerkkejä löytyy virallisesta API-viitteestä.

7. Code Deep Dive: Parametritiedostot (GUID-korvaus)

Tässä tapahtuu taika — miten %%configure käyttöliittymät vaihtuvat ympäristön mukaan.

Miten se toimii

Paketti fabric-cicd etsii tiedostoa, joka on parameter.yml nimetty .deploy hakemistosta (tai arkiston juuresta). Tämä tiedosto määrittelee etsi-ja-korvaa -säännöt , joita sovelletaan alkioiden määrittelyihin ennen käyttöönottoa.

💡 Vinkki: Etsi parameter.yml ja korvaa -ominaisuus tukee monia lähestymistapoja tämän tutoriaalin ulkopuolella — mukaan lukien regex-mallit, tiedostolaajuiset korvaukset ja paljon muuta. Täydellisen listan vaihtoehdoista ja edistyneestä käytöstä löytyy virallisesta dokumentaatiosta: 👉fabric-cicd Parameter File Documentation

💡 Vinkki — Muuttujakirjasto: On suositeltavaa hyödyntää Variable Librarya aina kun mahdollista ympäristökohtaisten arvojen hallintaan, sen sijaan että luottaisi pelkästään find_replace parametritiedostoihin. Muuttujakirjastot tarjoavat keskitetyn, uudelleenkäytettävän tavan hallita konfiguraatioita eri ympäristöissä. Lisätietoja löytyy kohdasta Aloita muuttujakirjastojen käytöstä.

Tiedosto:parameter.yml — joka sijaitsee aiemmin ladatussa GitHub-repositoissa.

7.1 Parametritiedostorakenne

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

🔍 Jokaisen merkinmän ymmärtäminen

Merkintä 1 — Työtilan ID:n korvaaminen

- 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: Muistikirjan %%configure komennossa löytyvä GUID — tämä on DEV-työtilan tunnus.
• replace_value: Se $workspace.$id on sisäänrakennettu tokenfabric-cicd, joka automaattisesti ratkaisee kohdetyötilan ID:n käyttöönoton yhteydessä.
• Koska dev sitä ei ole listattu , replace_valueGUID korvataan vain, kun se otetaan käyttöön tai testprod.

Merkintä 2 — Lakehouse-henkilökortin korvaaminen

- 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 on dynaaminen token, joka etsii kohdetyötilassa nimettyä järvitaloa DemoLakehouse ja palauttaa sen ID:n.
• Kuvio:$items.<ItemType>.<ItemName>.$id

Merkintä 3 — SQL Endpoint ID Replacement (Dynamic 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

• Sen sijaan, että SQL-päätepisteen GUID olisi kovakoodattu jokaiselle ympäristölle (esim. 204fd20c-e34c-4bef-9dce-4ecf53b0e878 TEST tai 29bda5ec-ebc7-466e-a618-ef5bbea75e13 PROD), tämä merkintä käyttää dynaamista merkintää — $items.Lakehouse.DemoLakehouse.$sqlendpointid.
• Paketti fabric-cicd ratkaisee tämän käyttöönoton yhteydessä etsimällä järvenrakennuksen SQL-päätepisteen ID DemoLakehouse :n kohdetyötilassa. Tämä poistaa tarpeen etsiä ja ylläpitää SQL-päätepisteiden GUID-tiedostoja manuaalisesti eri ympäristöissä.

7.2 Dynaamisten tokenien yhteenveto

7.3 Ominaisuushaaraparametritiedosto (edistynyt)

Tiimeille, jotka käyttävät ominaisuushaaroja (ei pelkästään dev), on olemassa varianttiparametritiedosto, jossa kaikilla kolmella ympäristöllä (kehitys, testi, tuotanto) on korvaajat:

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

Tämä on hyödyllistä, kun kehittäjät työskentelevät omissa Fabric-työtiloissaan ja tarvitsevat GUID-tiedostojen vaihtoa, vaikka ne otettaisiin käyttöön DEV:iin.

8. Käyttöönottokulku: Kokonaisvaltainen läpikäynti

Tässä on koko prosessi, kun Alex haluaa ylentää muistikirjan kehittäjästä testiin:

Vaihe 1: 🔧 Kehittäjä tekee muutoksia kehitystyöhön

Alex muokkaa IngestApiData muistikirjaa DEV Fabric -työtilassa (esimerkiksi lisää uuden solun). Fabricin Git Integration synkronoi tämän muutoksen automaattisesti haarautumiseen dev (tai manuaalisen commitin kautta).

Vaihe 2: 📋 Luo Pull Request (kehittäjä → testi)

Alex luo Pull Request -pyynnön ADO:ssa:

• Lähdehaara:dev
• Kohdehaara:test
• Otsikko: "Ylennä muutetut muistikirjan kohteet Testiksi"

PR sisältää kaikki muutetut alitteet, jotka Alex haluaa ottaa käyttöön TEST-ympäristössä.

Vaihe 3: ✅ PR-hyväksyntä ja yhdistyminen

Arvioija (tai Alexin ylläpitäjä) tarkistaa PR:n:

• Tarkastaa muutokset muistikirjan määrittelytiedostoihin
• Hyväksyy PR:n
• Yhdistäminen päättyy → Muutokset ovat nyt test haaralla

Vaihe 4: 🚀 Putkiston automaattiset laukaisimet

Haaran yhdistämiscommitus test laukaisee , fabric_cicd_pipeline koska:

• Haara test on laukaisijoiden include listalla
• Muutokset ovat polun sisällä fabric/

Putki aloittaa toteutuksen:

Pipeline Variable: target_env = "test"

Vaihe 5: ⏸️ Hyväksyntäportti

Koska putki käyttää environment: $(target_env) jatarget_env = test , ADO tarkistaa testiympäristön hyväksyntäporttien varalta.

• Putki pysähtyy ja lähettää ilmoituksen konfiguroiduille hyväksyjille.
• Ylläpitäjä tarkistaa ja klikkaa Hyväksy.

Vaihe 6: ⚡ Käsikirjoituksen toteutus

Hyväksynnän jälkeen putkisto:

1. ⚙️ Asettaa Python 3.12:n
2. 📦 Asennukset fabric-cicd
3. ▶️ Pelaa deploy-to-fabric.py seuraavilla mukana:

• SPN-tunnukset Key Vaultista
• --target_env test
• --items_in_scope ["Notebook","Lakehouse",...]

Python-skripti:

1. 🔐 Tunnistautuu SPN:llä
2. 🔍 Ratkaisee testWorkspaceName → etsii työtilan ID:n
3. 📄 Lataa parameter.yml ja soveltaa GUID-korvaamia
4. 📤 Julkaisee kohteita TEST-työtilassa
5. 🧹 Siivoaa orvoksi jääneet esineet

Vaihe 7: ✅ Käyttöönotto suoritettu

Muistikirja on nyt asennettu TEST-työtilaan seuraavilla toiminnoilla:

• ✅ Uusi solu on mukana
• ✅ Kaikki GUID:t %%configure on korvattu TEST-ympäristöarvoilla

9. Validointi: Onnistuneen komennuksen vahvistaminen

Kun putki on valmis, varmista, että käyttöönotto onnistui:

Tarkistus 1: Putkiston tila

ADO:ssa → Pipelines → Runsissa varmista, että putkiston suoritus näyttää ✅ Onnistunut ympäristössä test .

Tarkista 2: Muistikirjan sisältö TEST-työtilassa

Avaa IngestApiData muistikirja TEST Fabric -työtilassa ja varmista:

1. Uusi solu on läsnä: Juuri lisätty solu, joka kehitettiin DEV:ssä, pitäisi nyt näkyä muistikirjan TEST-versiossa.

2. GUID:t korvataan solussa 1: Komennossa %%configure (tyypillisesti solussa 1) varmista, että:

✅ Onnistui! Solu %%configure osoittaa nyt TEST-järventaloja, ja uusi kehitystyö on edistetty selkeästi.

10. Vianmääritys ja yleiset sudenkuopat

11. Yhteenveto

Tämä opastus esitteli tuotantotason CI/CD-työnkulun Fabric-ohjelmalle Azure DevOps:n avulla:

Tärkeimmät huomiot

1. Vain haara dev on yhdistetty Fabric-työtilaan — test ja prod haarat toimivat käyttöönottotietueina.
2. fabric-cicd parametritiedostot korvaavat automaattisesti GUID:t käyttämällä dynaamisia tokeneita, kuten $workspace.$id ja $items.Lakehouse.<name>.id.
3. ADO Environments, jolla on hyväksynnät , tarjoavat hallinnan — ei käyttöönottoa korkeampiin ympäristöihin ilman nimenomaista hyväksyntää.
4. Service Principal -tunnistautuminen Azure Key Vaultin kautta varmistaa, ettei tunnistetiedot koskaan paljastu koodissa tai lokitiedostoissa.

📚 Lisälukemista:

• fabric-cicd Dokumentaatio
• Fabric Git -integraatio
• Azure DevOps Environments & Hyväksynnät
• Azure Key Vault linked Variable Groups