🚀 CI/CD dla Microsoft Fabric przy użyciu Azure DevOps i fabric-cicd pakietu Python

W tym samouczku użyj biblioteki fabric-cicd Python, aby promować zmienione elementy (np. konkretny notatnik) z przestrzeni roboczej dewelopera do przestrzeni testowej, a następnie do prodowania.

1. Omówienie scenariusza

Poznaj Alexa — lidera deweloperskiego współpracującego z Fabric.

Zespół Alexa tworzy notesy, potoki danych, modele semantyczne i raporty w deweloperskim obszarze roboczym Fabric. Gdy funkcje będą gotowe, Alex musi promować zmienione elementy (np. konkretny notes) z przestrzeni roboczej deweloperskiej do przestrzeni testowej, a ostatecznie do produkcji.

Wyzwanie

Notatniki Alexa używają magicznej komendy %%configure do przyczepienia się do konkretnego domku nad jeziorem. To polecenie oznacza, że definicje notesników zawierają zakodowane na stałe identyfikatory GUID — identyfikatory obszaru roboczego, identyfikatory obiektów Lakehouse oraz identyfikatory punktów końcowych analityki SQL — które są różne w każdym środowisku.

Czego oczekuje Alex

Narzędzia

2. Diagram architektury

Na poniższym schemacie przedstawiono przepływ samouczka.

3. Wymagania wstępne

Przed rozpoczęciem upewnij się, że masz następujące elementy:

💡 Wskazówka: Aby włączyć dostęp jednostki usługi w Fabric, administrator Fabric musi włączyć opcję "Service principals can use Fabric APIs" w obszarze OneLake catalog>>>.

Pobieranie plików źródłowych

1. Sforkuj repozytorium Fabric-samples na swoim koncie GitHub.
2. Sklonuj fork na maszynę lokalną:

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

4. Początkowa konfiguracja usługi Azure DevOps

Ta sekcja opisuje wszystkie zasoby usługi Azure DevOps, które należy skonfigurować przed uruchomieniem potoku.

4.1 Integracja usługi Azure Key Vault

Poświadczenia jednostki usługi (identyfikator dzierżawy, identyfikator klienta i tajny klucz) nigdy nie powinny być przechowywane w postaci zwykłego tekstu. Zamiast tego przechowuj je w usłudze Azure Key Vault.

Kroki konfigurowania usługi Azure Key Vault

1. Utwórz usługę Key Vault w witrynie Azure Portal (lub użyj istniejącej).
2. Dodaj trzy wpisy tajne:

3. Udziel dostępu: Połączenie usługi ADO (lub tożsamość projektu ADO) musi mieć uprawnienia Uzyskiwanie i wyświetlanie listy wpisów tajnych w zasadach dostępu usługi Key Vault (lub roli Key Vault Secrets UserRBAC).

   

4.2 Grupa zmiennych: fabric_cicd_group_sensitive

Ta grupa zmiennych jest połączona z usługą Azure Key Vault, co oznacza, że wartości wpisów tajnych są pobierane w czasie wykonywania i nigdy nie są widoczne w interfejsie użytkownika ADO.

Kroki tworzenia

1. Przejdź do sekcji Pipelines → Library w projekcie ADO.
2. Kliknij pozycję + Grupa zmiennych.
3. Nadaj mu nazwę: fabric_cicd_group_sensitive
4. Przełącz pozycję Połącz wpisy tajne z usługi Azure Key Vault jako zmienne.
5. Wybierz subskrypcję platformy Azure i usługę Key Vault.
6. Kliknij pozycję + Dodaj i wybierz trzy sekrety.

• aztenantid
• azclientid
• azspnsecret

7. Kliknij przycisk Zapisz.

4.3 Grupa zmiennych: fabric_cicd_group_non_sensitive

Ta grupa zmiennych przechowuje wartości konfiguracji innych niż tajne, w szczególności ścieżkę katalogu Git i nazwy obszarów roboczych dla każdego środowiska.

Kroki tworzenia

1. Przejdź do sekcji Pipelines → Library w projekcie ADO.
2. Kliknij pozycję + Grupa zmiennych.
3. Nadaj mu nazwę: fabric_cicd_group_non_sensitive
4. Dodaj następujące zmienne:

5. Kliknij przycisk Zapisz.

   

💡 Jak to działa w kodzie: Skrypt języka Python odczytuje te wartości przy użyciu polecenia os.environ. Na przykład podczas wdrażania w test programie skrypt konstruuje nazwę testWorkspaceName zmiennej, konwertuje ją na wielkie litery (TESTWORKSPACENAME) i odczytuje je ze środowiska, ponieważ ADO automatycznie wprowadza niewrażliwe wartości grupy zmiennych jako zmienne środowiskowe w postaci wielkich liter.

4.4 Środowiska ADO i bramy zatwierdzania

Środowiska ADO umożliwiają dodawanie ręcznych kontroli zatwierdzania przed kontynuowaniem wdrożeń. Ma to kluczowe znaczenie dla promowania usług test i prod.

Kroki tworzenia środowisk

1. Przejdź do obszaru Potoki → Środowiska w projekcie ADO.
2. Utwórz trzy środowiska z dokładnymi nazwami pasującymi do nazw gałęzi:

3. Dla test i prod, kliknij na środowisko → ⋮ (więcej opcji) → Zatwierdzenia i sprawdzenia → + Dodaj sprawdzenie → Zatwierdzenia.

4. Dodaj wymagane osoby zatwierdzające.

   

Przykładowy widok stanu środowiska:

💡 Dlaczego środowiska? Pipeline YAML używa deployment zadań z użyciem environment: $(target_env). Gdy target_env jest test lub prod, ADO wstrzymuje potok i czeka na zatwierdzenie skonfigurowanych osób zatwierdzających przed kontynuowaniem.

4.5 Strategia gałęzi Git

Strategia rozgałęziania jest kluczowa dla tej konfiguracji CI/CD. Potrzebne są trzy długotrwałe gałęzie:

Kwestie kluczowe

Dlaczego tylko dev jest połączony?

• Integracja Fabric z Git synchronizuje elementy obszaru roboczego dwukierunkowo z gałęzią Git.
• Gałęzie test i prodnie są połączone z obszarami roboczymi, ponieważ pakiet fabric-cicd realizuje wdrażanie bezpośrednio za pośrednictwem interfejsu Fabric REST API.
• Te gałęzie służą jako dokładny zapis, które wersje elementów zostały wdrożone w każdym środowisku.

4.6 Instalacja potoku ADO

Utwórz pipeline w usłudze ADO, który odwołuje się do pliku YAML w repozytorium.

Steps

1. Przejdź do pozycji Potoki → Potoki → nowy potok.
2. Wybierz pozycję Azure Repos Git i wybierz repozytorium.
3. Wybierz Istniejący plik YAML Azure Pipelines.
4. Wskaż ścieżkę: Deploy-To-Fabric.yml (lub tam, gdzie ją umieściłeś).
5. Nadaj potokowi nazwę: fabric_cicd_pipeline.
6. W obszarze Uprawnienia potoku upewnij się, że ma dostęp do:

• Obie grupy zmiennych (fabric_cicd_group_sensitive i fabric_cicd_group_non_sensitive)
• Wszystkie trzy środowiska (dev, test, prod)

7. Zapisz (jeszcze nie uruchamiaj).

⚠✔ Porada dotycząca uprawnień: Przy pierwszym uruchomieniu potoku ADO może pojawić się monit o autoryzowanie dostępu do grup zmiennych i środowisk. Administrator ADO może wstępnie autoryzować te opcje w obszarze Potok → Ustawienia.

5. Szczegółowe omówienie kodu: ADO Pipeline YAML

Plik:Deploy-To-Fabric.yml- znajdujący się w repozytorium GitHub pobranym wcześniej.

Poniżej znajduje się pełny pipeline z adnotacjami linie-po-linii.

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

🔍 Wyzwalacz-Wyjaśnienia

• Potok jest automatycznie uruchamiany przy zatwierdzaniu zmian w gałęziach test lub prod. Nie jest on wyzwalany na dev- ponieważ dev jest gałęzią źródłową połączoną z integracją usługi Git z siecią szkieletową.
• Filtr paths zapewnia, że wyzwala tylko wtedy, gdy pliki w fabric/ katalogu są zmieniane, uniemożliwiając niepotrzebne uruchomienia ze zmian w dokumentacji, skryptach itp.
• W praktyce: gdy żądanie ściągnięcia jest scalane z dev → test, zatwierdzenie scalania ląduje w test gałęzi, wyzwalając potok przeznaczony dla środowiska TEST.

# ──────────────────────────────────────────────────────────────
# 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"]'

🔍 Wyjaśnienie-Parametry

• Definiuje parametr środowiska uruchomieniowego, który kontroluje, które typy elementów Fabric znajdują się w zakresie wdrażania.
• Jeśli ten parametr nie zostanie określony, zostaną wdrożone wszystkie typy elementów obsługiwane przez fabric-cicd pakiet.
• Ten parametr służy również jako opcja selektywnego wdrożenia. Na przykład można było przepuścić tylko ["Notebook"] po to, by wdrożyć tylko notebooki.

⚠️ Ostrzeżenie dotyczące wdrożenia selektywnego: Jeśli zawężasz items_in_scope na potrzeby wdrożenia selektywnego, nie wywołuj unpublish_all_orphan_items() w skrypcie Python. Ta funkcja usuwa elementy typów określonych w items_in_scope, które istnieją w przestrzeni roboczej, ale nie są obecne w gałęzi wydania. Na przykład jeśli wdrożysz tylko ["Notebook"], a w obszarze roboczym znajdują się notatniki, których nie ma w gałęzi, funkcja je usunie — mimo że mogą nadal być prawidłowe. Nie usuwa elementów innych typów (takich jak potoki danych, raporty i inne rodzaje elementów). Użyj unpublish_all_orphan_items() tylko wtedy, gdy gałąź reprezentuje pełny żądany stan dla typów elementów w zakresie.

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

🔍 Wyjaśnienie — zmienne

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

🔍 Zadanie Eksplanacyjno-Wdrożeniowe

    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'

🔍 Kroki wyjaśnienia

⚠✔ Uwaga dotycząca zabezpieczeń: Wartości $(aztenantid), $(azclientid) i $(azspnsecret) są pobierane z grupy zmiennych powiązanej z usługą Key Vault. Są automatycznie maskowane w dziennikach potoku — będziesz widzieć *** zamiast rzeczywistych wartości.

6. Szczegółowe omówienie kodu: skrypt wdrażania języka Python

Plik:.deploy/deploy-to-fabric.py — znajdujący się w repozytorium GitHub pobranym wcześniej.

Jest to serce wdrożenia. Omówimy poszczególne sekcje.

6.1 Import i zależności

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

Funkcja wyszukiwania identyfikatora obszaru roboczego 6.2

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

Co robi:

1. Wywołuje interfejs API REST sieci szkieletowej (GET /v1/workspaces), aby wyświetlić listę wszystkich obszarów roboczych, do których ma dostęp główna nazwa usługi.
2. Wyszukuje obszar roboczy, którego displayName nazwa odpowiada docelowej nazwie obszaru roboczego.
3. Zwraca identyfikator GUID obszaru roboczego, jeśli zostanie znaleziony, lub komunikat o błędzie, jeśli nie.

💡 Dlaczego identyfikator obszaru roboczego nie jest zakodowany na stałe? Wyszukując go dynamicznie według nazwy, skrypt jest bardziej odporny na rekreację obszaru roboczego i unika przechowywania identyfikatorów GUID w grupie zmiennych.

6.3 Flagi funkcji i logowanie

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

Parsowanie argumentów

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

Te argumenty są przekazywane z kroku potoku YAML. Analizator udostępnia je jako args.aztenantid, args.azclientiditp.

6.5 Uwierzytelnianie

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

Spowoduje to utworzenie obiektu poświadczeń platformy Azure przy użyciu identyfikatora klienta, tajnego klucza i identyfikatora dzierżawy aplikacji/usługi. To poświadczenie jest używane zarówno do:

1. Wywoływanie interfejsu API REST dla usługi Fabric (wyszukiwanie zasobów w obszarze roboczym)
2. Przekazywanie do FabricWorkspace w celu fabric-cicd wdrożenia

6.6 Dynamiczne rozwiązanie obszaru roboczego

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

Sprytna część: Grupa fabric_cicd_group_non_sensitive zmiennych zawiera zmienne, takie jak devWorkspaceName, testWorkspaceName, itp., wprowadza je jako wielkie zmienne środowiskowe. Skrypt dynamicznie konstruuje nazwę zmiennej na podstawie środowiska docelowego.

# 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 Inicjowanie FabricWorkspace & Wdrażanie

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)

✔ WAŻNE — zrozumienie : ta metoda spowoduje usunięcie elementów typów określonych w z docelowego obszaru roboczego, które nie znajdują się w gałęzi wydania (tzn. gałęzi używanej jako źródło pakietu). Nie będzie dotykać elementów innych typów. W tym samouczku test gałąź zawiera wszystkie elementy przeznaczone dla środowiska roboczego TEST, więc można bezpiecznie wywołać unpublish_all_orphan_items() — spowoduje to usunięcie tylko elementów, które zostały celowo usunięte z gałęzi.

Jednak jeśli wykonujesz wdrożenie selektywne (na przykład wdrażając tylko notesy za pomocą zawężonego items_in_scope), zachowaj ostrożność z unpublish_all_orphan_items(). Usuwa wszystkie notatniki w obszarze roboczym, których nie ma w gałęzi, nawet jeśli są nadal prawidłowe i po prostu nie były częścią selektywnego wdrożenia.

💡 Wskazówka:unpublish_all_orphan_items() obsługuje wykluczanie określonych elementów z usuwania przez przekazanie wzorca wyrażeń regularnych. Wszystkie elementy, których nazwy pasują do wyrażenia regularnego, zostaną zachowane w obszarze roboczym, nawet jeśli nie znajdują się w gałęzi źródłowej. Aby uzyskać więcej szczegółów i przykładów użycia, zobacz oficjalną dokumentację interfejsu API.

7. Dogłębna analiza kodu: pliki parametrów (zastąpienie GUID)

W tym miejscu dzieje się magia — jak identyfikatory GUID są zamieniane dla każdego środowiska.

Jak to działa

Pakiet fabric-cicd szuka pliku o nazwie parameter.yml w katalogu .deploy (lub w katalogu głównym repozytorium). Ten plik definiuje reguły znajdowania i zastępowania , które są stosowane do definicji elementów przed wdrożeniem.

💡 Wskazówka:parameter.yml Funkcja znajdowania i zastępowania obsługuje wiele podejść wykraczających poza to, co pokazano w tym samouczku — w tym wzorce wyrażeń regularnych, zastępowanie w zakresie plików i nie tylko. Aby uzyskać pełną listę opcji i zaawansowanego użycia, zobacz oficjalną dokumentację: 👉fabric-cicd Parameter File Documentation

💡 Porada — biblioteka zmiennych: Zaleca się korzystanie z biblioteki zmiennych zawsze, gdy jest to możliwe do zarządzania wartościami specyficznymi dla środowiska, a nie poleganie wyłącznie na find_replace plikach parametrów. Biblioteki zmiennych zapewniają scentralizowany, wielokrotnego użytku sposób zarządzania konfiguracją w różnych środowiskach. Aby uzyskać więcej informacji, zobacz Wprowadzenie do bibliotek zmiennych.

Plik:parameter.yml — znajdujący się w repozytorium GitHub pobranym wcześniej.

Struktura plików parametrów 7.1

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

🔍 Opis każdego wpisu

Wpis 1 — zastąpienie identyfikatora obszaru roboczego

- 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: Identyfikator GUID znajdujący się w poleceniu notesu %%configure — jest to identyfikator obszaru roboczego DEV.
• replace_value: $workspace.$id jest wbudowanym tokenem w fabric-cicd, który automatycznie rozwiązuje się do identyfikatora docelowego obszaru roboczego w czasie wdrażania.
• Ponieważ dev nie jest wymieniony na liście replace_value, identyfikator GUID jest zastępowany tylko podczas wdrażania do test lub prod.

Wpis 2 — Zastąpienie identyfikatora Lakehouse

- 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 to token dynamiczny, który wyszukuje element lakehouse o nazwie DemoLakehouse w docelowym obszarze roboczym i zwraca jego identyfikator.
• Wzór:$items.<ItemType>.<ItemName>.$id

Wpis 3 — Zastępowanie identyfikatora punktu końcowego analityki SQL (notacja dynamiczna)

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

• Zamiast na sztywno wpisywać identyfikator GUID punktu końcowego analizy SQL dla każdego środowiska (np. 204fd20c-e34c-4bef-9dce-4ecf53b0e878 dla TEST lub 29bda5ec-ebc7-466e-a618-ef5bbea75e13 dla PROD), w tym wpisie użyto notacji dynamicznej — $items.Lakehouse.DemoLakehouse.$sqlendpointid.
• Pakiet fabric-cicd rozwiązuje ten problem podczas wdrażania, wyszukując identyfikator punktu końcowego analizy SQL obiektu lakehouse DemoLakehouse w docelowej przestrzeni roboczej. Eliminuje to konieczność ręcznego wyszukiwania identyfikatorów GUID punktów końcowych analizy SQL i zarządzania nimi w różnych środowiskach.

Podsumowanie tokenów dynamicznych 7.2

7.3 Plik parametrów gałęzi funkcji (zaawansowane)

W przypadku zespołów korzystających z gałęzi funkcji (nie tylko dev) istnieje plik parametrów wariantu, w którym wszystkie trzy środowiska (deweloperskie, testowe, prod) mają zamienniki:

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

Jest to przydatne, gdy deweloperzy pracują we własnych obszarach roboczych platformy Fabric i potrzebują zastąpienia GUID, nawet podczas wdrażania do DEV.

8. Przepływ wdrażania: kompleksowy przegląd krok po kroku

Oto cały proces, gdy Alex chce przenieść notatnik z dev do test:

Krok 1. 🔧 Deweloper wprowadza zmiany w usłudze DEV

Alex modyfikuje IngestApiData notes w przestrzeni roboczej DEV Fabric (na przykład dodaje nową komórkę). Integracja z usługą Git Fabric automatycznie synchronizuje tę zmianę z gałęzią dev (lub za pośrednictwem ręcznego zatwierdzenia).

Krok 2: 📋 Utwórz Pull Request (z deweloperskiego na testowy)

Alex tworzy Pull Request w ADO:

• Gałąź źródłowa:dev
• Gałąź docelowa:test
• Tytuł: "Awansuj zmienione elementy zeszytu do testu"

Pull request zawiera wszystkie zmienione elementy, które Alex chce wdrożyć do środowiska TEST.

Krok 3. ✅ Zatwierdzanie pull requestów i scalanie

Recenzent (lub administrator Alexa) przegląda żądanie ściągnięcia:

• Sprawdza zmiany w plikach definicji notatnika
• Zatwierdza żądanie ściągnięcia
• Kończy scalanie → Zmiany są teraz w test gałęzi

Krok 4. 🚀 Automatyczne wyzwalacze potoku

Zatwierdzenie scalania w gałęzi test wyzwala fabric_cicd_pipeline z następujących powodów:

• Gałąź test znajduje się na liście wyzwalacza include
• Zmiany znajdują się wewnątrz ścieżki fabric/

Potok przetwarzania rozpoczyna się wykonywanie:

Pipeline Variable: target_env = "test"

Krok 5. ⏸️ Brama zatwierdzenia

Ponieważ potok używa environment: $(target_env)target_env = test, ADO sprawdza środowisko test pod kątem bram zatwierdzania.

• Potok wstrzymuje się i wysyła powiadomienie do skonfigurowanych osób zatwierdzających.
• Administrator przegląda i klika Zatwierdź.

Krok 6. ⚡ Wykonywanie skryptu

Po zatwierdzeniu potok:

1. ⚙️ Konfiguruje Python 3.12
2. 📦 Instaluje fabric-cicd
3. ▶️ Uruchamia się deploy-to-fabric.py z:

• Poświadczenia SPN z usługi Key Vault
• --target_env test
• --items_in_scope ["Notebook","Lakehouse",...]

Skrypt języka Python:

1. 🔐 Uwierzytelnia przy użyciu SPN
2. 🔍 testWorkspaceName Rozwiązuje → wyszukuje identyfikator obszaru roboczego
3. 📄 Ładuje parameter.yml i aplikuje zamiany identyfikatora GUID
4. 📤 Publikuje elementy w obszarze roboczym TEST
5. 🧹 Czyści osierocone elementy

Krok 7. ✅ Zakończenie wdrażania

Notatnik został teraz wdrożony do przestrzeni roboczej TEST z:

• ✅ Nowo dodana komórka jest obecna
• ✅ Wszystkie identyfikatory GUID w %%configure zastąpiono wartościami środowiska TEST

9. Walidacja: potwierdzanie pomyślnego wdrożenia

Po zakończeniu potoku przetwarzania, sprawdź, czy wdrożenie zakończyło się pomyślnie.

Sprawdzanie 1. Stan potoku

W ADO → Potoki → Uruchomienia upewnij się, że uruchomienie potoku zakończyło się pomyślnie dla środowiska .

Kontrola 2: Zawartość notesu w obszarze roboczym TEST

Otwórz IngestApiData notes w przestrzeni roboczej TEST Fabric i sprawdź:

1. Nowa komórka jest obecna: Nowo dodana komórka, która została opracowana w środowisku DEV, powinna teraz być wyświetlana w wersji TEST notatnika.

2. Identyfikatory GUID są zastępowane w komórce 1: W poleceniu %%configure (zazwyczaj w komórce 1) sprawdź, czy:

✅ Sukces!%%configure Komórka teraz wskazuje na testowe lakehouse'y, a nowe prace rozwojowe zostały pomyślnie wdrożone.

10. Rozwiązywanie problemów i typowe pułapki

11. Podsumowanie

W tym samouczku przedstawiono przepływ pracy CI/CD klasy produkcyjnej dla platformy Fabric z wykorzystaniem usługi Azure DevOps:

Kluczowe wnioski

1. Tylko gałąź dev jest połączona z obszarem roboczym Fabric — gałęzie test i prod pełnią funkcję rejestrów wdrożenia.
2. fabric-cicd pliki parametrów automatycznie zastępują GUID za pomocą dynamicznych tokenów takich jak $workspace.$id i $items.Lakehouse.<name>.id.
3. Środowiska ADO z zatwierdzeniami zapewniają zarządzanie — brak wdrożenia do wyższych środowisk bez wyraźnego zatwierdzenia.
4. Uwierzytelnianie jednostki usługi za pośrednictwem usługi Azure Key Vault zapewnia, że poświadczenia nigdy nie są widoczne w kodzie lub dziennikach.

📚 Linki zewnętrzne:

• fabric-cicd dokumentacja
• Integracja Git w Fabric
• Środowiska i zatwierdzenia usługi Azure DevOps
• Połączone grupy zmiennych Azure Key Vault