บทเรียน: ระบบอัตโนมัติแบบครบวงจรใน Fabric

ในบทเรียนนี้ คุณจะสร้าง flow การปล่อยเวอร์ชันที่สมบูรณ์และทําซ้ําได้สําหรับ Microsoft Fabric โดยใช้โครงสร้างพื้นฐานเป็นโค้ด คุณจัดเตรียม workspace สองแห่ง (dev และ test) ด้วย Terraform, เชื่อมต่อ workspace ของ dev กับ Git, เขียนรายการใน dev แล้วโปรโมทให้ทดสอบด้วย Python library ของ fabric-cicd ทุกอย่างทํางานภายใต้หลักการบริการเดียว ดังนั้นกระบวนการเดียวกันนี้ใช้ได้กับแล็ปท็อปของคุณวันนี้และในสาย CI/CD ในอนาคต

ในบทช่วยสอนนี้ คุณ:

สองเครื่องบิน สองเครื่องมือ

การทํางานอัตโนมัติในการปล่อย Fabric มีสองประเด็นที่แตกต่างกัน และช่วยให้แยกจากกันได้: ระบบควบคุมที่เสถียร (โครงสร้างพื้นฐานที่เนื้อหาของคุณอยู่) และระบบข้อมูลที่เปลี่ยนแปลงได้ (เนื้อหาที่คุณแก้ไขทุกวัน) จับคู่เครื่องมือการติดตั้งให้ตรงกับความถี่ที่แต่ละสิ่งเปลี่ยนแปลง

• Control plane จะเก็บโครงสร้างพื้นฐานที่ไม่ลบเลือนซึ่งคุณจัดเตรียมเพียงครั้งเดียวและแทบไม่เปลี่ยนแปลง ได้แก่ ความจุ, พื้นที่ทํางานและการตั้งค่า, โดเมน, การเชื่อมต่อ, การตั้งค่า tenant และการเดินสาย RBAC และ Git บทเรียนนี้จัดเตรียม Terraform ไว้ให้
• Data plane เก็บเนื้อหาที่เปลี่ยนแปลงได้ทุกครั้งที่ sprint และไหลผ่าน Git: โน้ตบุ๊ก, บ้านพักและคลังสินค้า, โมเดลเชิงความหมายและรายงาน, pipeline และ dataflow, และค่าของ Variable Library บทเรียนนี้ช่วยขยับมันด้วย fabric-cicd

แนวคิดหลัก: จัดเตรียมแพลตฟอร์มเสถียรครั้งหนึ่งด้วย Terraform จากนั้นปล่อยให้ไอเท็มที่เปลี่ยนแปลงได้ไหลต่อเนื่องผ่าน Git และ fabric-cicd

นี่เป็นหนึ่งในวิธีการทําให้ Fabric เป็นอัตโนมัติ และมันเอื้อประโยชน์ต่อทีมที่มองโครงสร้างพื้นฐานเป็นโค้ดอยู่แล้ว และต้องการการตั้งค่าที่ควบคุมโดยสคริปต์และซอร์สโค้ด Fabric ยังมีระบบปรับใช้ผ่านพอร์ทัลและการผสานรวมกับ Git ซึ่งคุณสามารถควบคุมจาก UI ได้โดยไม่ต้องเขียน Terraform หรือ Python สําหรับการเปรียบเทียบตัวเลือกต่าง ๆ ดูที่ตัวเลือกเวิร์กโฟลว์ CI/CD ใน Fabric

สําหรับการติดตั้ง data-plane โดยเฉพาะ fabric-cicd เป็นตัวเลือกหนึ่ง คุณยังสามารถเรียกใช้ Fabric bulk (CRUD) REST API โดยตรง หากต้องการควบคุมการเรียกสร้าง อัปเดต และลบได้เต็มที่โดยไม่ต้องพึ่งพาไลบรารี บทเรียนนี้ใช้ fabric-cicd เพราะมันจัดการการ rebinding เฉพาะสภาพแวดล้อมให้คุณ

ทําไมต้องเลือก Terraform สําหรับเครื่องบินควบคุม

• แบบประกาศและแบบไม่พอต คุณอธิบายสถานะที่ต้องการของพื้นที่ทํางานของคุณเพียงครั้งเดียว; Terraform สร้างสิ่งที่ขาดหายไปและปล่อยส่วนที่เหลือไว้ตามเดิม
• ตรวจจับการลอยตัว terraform plan แสดงให้เห็นอย่างชัดเจนว่า live tenant แตกต่างจากแหล่งข้อมูลของคุณอย่างไร ดังนั้นการเปลี่ยนแปลงนอกย่านความถี่ในพอร์ทัลจึงสามารถมองเห็นและย้อนกลับได้
• ผู้ให้บริการรายเดียวสําหรับทรัพยากรหลากหลาย ผู้ให้บริการ Microsoft Fabric จัดการพื้นที่ทํางาน ความจุ การเชื่อมต่อ ลิงก์ Git และ RBAC ผ่าน Fabric REST APIs

ทําไมต้องใช้ fabric-cicd สําหรับระนาบข้อมูล

• ติดตั้งตามที่ Fabric คาดหวัง fabric-cicd อ่านการแสดงผล Git ของรายการของคุณและเผยแพร่ด้วยความหมายที่ถูกต้องสําหรับการสร้างหรืออัปเดต เพื่อไม่ให้คุณกด REST call ด้วยมือ
• การกําหนดพารามิเตอร์ parameter.ymlไฟล์จะผูกค่าเฉพาะของสภาพแวดล้อมใหม่ เช่น การชี้ไปยังบ้านพักทะเลสาบเริ่มต้นของสมุดบันทึก หรือการเชื่อมต่อของโมเดลเชิงความหมายไปยังเป้าหมายที่ถูกต้องในแต่ละสภาพแวดล้อม
• ล้าง มันสามารถยกเลิกการเผยแพร่รายการที่ถูกลบออกจาก Git ได้ ทําให้ทุกสภาพแวดล้อมเป็นภาพสะท้อนที่ซื่อสัตย์ของสาขาที่ติดตาม

กระบวนการแบบครบวงจร

สองระนาบนี้รวมกันเป็นระบบอัตโนมัติที่ต่อเนื่องกัน คุณจัดเตรียมแพลตฟอร์ม เพียงครั้งเดียว และหลังจากนั้นการเปลี่ยนแปลงเนื้อหาทุกครั้งจะวนลูปซ้ํา ๆ จากตัวแก้ไข ผ่าน Git เข้าสู่สภาพแวดล้อมทดสอบ โดยไม่มีขั้นตอนพอร์ทัลด้วยตนเองระหว่างทาง

service principal เดียวกันจะตรวจสอบความถูกต้องทุกขั้นตอน ดังนั้น flow ที่คุณรันด้วยมือในบทเรียนนี้คือสิ่งที่ pipeline CI/CD ดําเนินการแทนคุณ : stage provision (Terraform) จากนั้น stage deployment (fabric-cicd) ที่รันทุกครั้งที่ tracked branch เปลี่ยน แต่ละด่านจะจับคู่กับขั้นตอนดังต่อไปนี้:

Prerequisites

• ความจุของ Fabric ทั้งสองพื้นที่ทํางานในบทเรียนนี้ถูกกําหนดให้มีความจุเท่ากัน การทดลองใช้ได้ผล
• Service Principal (การลงทะเบียนแอป Microsoft Entra) ที่มี client secret ตัวตนเดียวนี้จัดเตรียมพื้นที่ทํางาน และ รันการปรับใช้
• Service principal ที่ตั้งค่า tenant สามารถใช้ Fabric API ที่เปิดใช้งานสําหรับกลุ่มความปลอดภัยที่มี service principal อยู่ สําหรับข้อมูลเพิ่มเติม ดูที่ เปิดใช้งานการตรวจสอบสิทธิ์หลักบริการสําหรับ Fabric APIs
• องค์กร Azure DevOps โปรเจกต์ และคลังข้อมูล Git ที่ service principal สามารถเข้าถึงได้ ที่เก็บข้อมูลต้องมีสาขา (เช่น main) และ โฟลเดอร์ที่คุณตั้งค่าไว้ ado_directory_name (เช่น /workspace) อยู่แล้ว การเชื่อมต่อ Git ใช้ PreferRemote, ซึ่งจะอ่านโฟลเดอร์นั้นบนสาขาเมื่อเชื่อมต่อ ดังนั้นทั้งสองต้องมีอยู่ก่อน ถ้าโฟลเดอร์หายไป terraform apply จะล้มเหลวกับ GitProviderResourceNotFound. ในการสร้าง ให้ commit ไฟล์ว่างเปล่า (เช่น .gitkeep) ไปยังเส้นทางนั้นบน branch ก่อนรัน Terraform
• เครื่องมือต่อไปนี้ติดตั้งในเครื่อง:
  • Terraform 1.8 หรือใหม่กว่า
  • Python 3.9 ขึ้นไป (สูงสุด 3.13)
  • Azure CLI

ตั้งค่าการรับรองความถูกต้อง

ทั้ง Terraform และ fabric-cicd จะตรวจสอบความถูกต้องในฐานะ service principal ส่งออกข้อมูลรับรองเป็นตัวแปรสภาพแวดล้อมเพื่อให้ทั้งสองเครื่องมือสามารถรับข้อมูลได้:

export FABRIC_TENANT_ID="<tenant-id>"
export FABRIC_CLIENT_ID="<app-client-id>"
export FABRIC_CLIENT_SECRET="<client-secret>"

# fabric-cicd (via DefaultAzureCredential) reads the AZURE_* names:
export AZURE_TENANT_ID="$FABRIC_TENANT_ID"
export AZURE_CLIENT_ID="$FABRIC_CLIENT_ID"
export AZURE_CLIENT_SECRET="$FABRIC_CLIENT_SECRET"

$env:FABRIC_TENANT_ID   = "<tenant-id>"
$env:FABRIC_CLIENT_ID   = "<app-client-id>"
$env:FABRIC_CLIENT_SECRET = "<client-secret>"

$env:AZURE_TENANT_ID    = $env:FABRIC_TENANT_ID
$env:AZURE_CLIENT_ID    = $env:FABRIC_CLIENT_ID
$env:AZURE_CLIENT_SECRET = $env:FABRIC_CLIENT_SECRET

ขั้นตอนที่ 1: จัดเตรียมพื้นที่ทํางานด้วย Terraform

ในขั้นตอนนี้ คุณจะกําหนดระนาบควบคุมเป็นโค้ดและนําไปใช้ สร้างโฟลเดอร์สําหรับการตั้งค่า Terraform ของคุณและเพิ่มไฟล์ต่อไปนี้

กําหนดค่าผู้ให้บริการ

สร้าง provider.tf การปักหมุดเวอร์ชันของผู้ให้บริการจะทําให้วิศวกรทุกคนมีพฤติกรรมเหมือนกัน

# We strongly recommend using the required_providers block to set the Fabric Provider source and version being used
terraform {
  required_version = ">= 1.8, < 2.0"
  required_providers {
    fabric = {
      source  = "microsoft/fabric"
      version = "1.12.0"
    }
  }
}

# Configure the Microsoft Fabric Terraform Provider.
# Auth is via the service principal exported as FABRIC_TENANT_ID /
# FABRIC_CLIENT_ID / FABRIC_CLIENT_SECRET. Never hard-code secrets here.
provider "fabric" {
  # Configuration options
}

ประกาศอินพุต

สร้าง variables.tf:

variable "capacity_name" {
  description = "Name of an existing Fabric capacity that backs both workspaces."
  type        = string
}

variable "workspace_prefix" {
  description = "Prefix for the workspace display names."
  type        = string
  default     = "releaseflow"
}

# Azure DevOps Git settings for the DEV workspace.
variable "ado_organization_name" {
  type = string
}
variable "ado_project_name" {
  type = string
}
variable "ado_repository_name" {
  type = string
}
variable "ado_branch_name" {
  type    = string
  default = "main"
}
variable "ado_repo_url" {
  type = string
}
variable "ado_directory_name" {
  type    = string
  default = "/workspace"
}

# Service principal used by the source-control connection.
variable "tenant_id" {
  type = string
}
variable "client_id" {
  type = string
}
variable "client_secret" {
  type      = string
  sensitive = true
}

# Object id of the developer or group to grant Contributor on DEV.
variable "contributor_principal_id" {
  type = string
}

กําหนดทรัพยากร

สร้าง main.tf การกําหนดค่านี้สร้างพื้นที่ทํางานสองแห่ง ได้แก่ การเชื่อมต่อซอร์ส-คอนโทรล, ลิงก์ Git สําหรับนักพัฒนา และการมอบหมายบทบาท

data "fabric_capacity" "capacity" {
  display_name = var.capacity_name
}

# DEV workspace — authored here, committed to Git.
resource "fabric_workspace" "dev" {
  display_name = "${var.workspace_prefix}-dev"
  description  = "Development workspace."
  capacity_id  = data.fabric_capacity.capacity.id
}

# TEST workspace — populated by fabric-cicd from the Git repo.
resource "fabric_workspace" "test" {
  display_name = "${var.workspace_prefix}-test"
  description  = "Test workspace."
  capacity_id  = data.fabric_capacity.capacity.id
}

# Source-control connection (service principal).
resource "fabric_connection" "ado" {
  display_name      = "${var.workspace_prefix}-ado-conn"
  connectivity_type = "ShareableCloud"
  privacy_level     = "Organizational"

  connection_details = {
    type            = "AzureDevOpsSourceControl"
    creation_method = "AzureDevOpsSourceControl.Contents"
    parameters = [{ name = "url", value = var.ado_repo_url }]
  }

  credential_details = {
    credential_type      = "ServicePrincipal"
    skip_test_connection = false
    service_principal_credentials = {
      client_id                = var.client_id
      client_secret_wo         = var.client_secret
      client_secret_wo_version = 1
      tenant_id                = var.tenant_id
    }
  }
}

# Connect the DEV workspace to Git.
resource "fabric_workspace_git" "dev" {
  workspace_id            = fabric_workspace.dev.id
  initialization_strategy = "PreferRemote"

  git_provider_details = {
    git_provider_type = "AzureDevOps"
    organization_name = var.ado_organization_name
    # The Fabric API returns project/repository names lowercased. Pass them
    # lowercased so Terraform's post-apply consistency check matches.
    project_name    = lower(var.ado_project_name)
    repository_name = lower(var.ado_repository_name)
    branch_name     = var.ado_branch_name
    directory_name  = var.ado_directory_name
  }

  git_credentials = {
    source        = "ConfiguredConnection"
    connection_id = fabric_connection.ado.id
  }
}

# RBAC: grant the dev team Contributor on DEV.
# If contributor_principal_id is a security group rather than a user, change
# type to "Group".
resource "fabric_workspace_role_assignment" "dev_contributor" {
  workspace_id = fabric_workspace.dev.id
  role         = "Contributor"
  principal = {
    id   = var.contributor_principal_id
    type = "User"
  }
}

ประกาศผลลัพธ์

สร้าง outputs.tf ชื่อพื้นที่ทดสอบจะป้อนข้อมูลขั้นตอนการปรับใช้

output "dev_workspace_id"   { value = fabric_workspace.dev.id }
output "test_workspace_id"  { value = fabric_workspace.test.id }
output "test_workspace_name" {
  description = "Pass this as --workspace_name to the fabric-cicd deploy step."
  value       = fabric_workspace.test.display_name
}

ใช้การตั้งค่า

ให้ค่าสําหรับตัวแปร (เช่น ใน terraform.tfvars ไฟล์ที่คุณเก็บไว้ไม่ให้ใช้ Git) จากนั้นรัน:

terraform init
terraform plan
terraform apply

Terraform รายงานทรัพยากรที่สร้างขึ้นและพิมพ์ผลลัพธ์

ความท้าทายด้านการจัดเตรียมที่ควรรู้

ผู้ให้บริการ Fabric นั้นทรงพลัง แต่พฤติกรรมบางอย่างอาจทําให้คนสะดุด โปรดจําไว้ก่อนจะใช้งานจริง:

• การเชื่อมต่อ Git ไม่สามารถนําเข้าได้ แหล่งข้อมูลไม่ fabric_workspace_git รองรับ terraform import. ถือว่าเป็นบูตสแตรปครั้งเดียวและเก็บไว้ในสถานะระยะไกลเพื่อไม่ให้รันต่อมาพยายามสร้างมันขึ้นมาใหม่ เก็บสถานะของคุณไว้ใน backend ที่ใช้ร่วมกัน เช่น Azure Storage แทนที่จะเก็บไว้ในแล็ปท็อปเครื่องเดียว
• ชื่อ Git ที่แยกตัวพิมพ์ใหญ่-เล็ก Fabric API จะคืนชื่อโปรเจกต์และคลังข้อมูล Azure DevOps ด้วยตัวพิมพ์เล็ก ถ้าคุณผ่านในกรณีผสม Terraform จะรายงาน ว่า "ผู้ให้บริการผลิตผลลัพธ์ไม่สม่ําเสมอหลังจากนําไปใช้" ห่อพวกมันด้วย lower()ตามที่แสดงด้านบน
• ขอบเขตของหลักการบริการ ตัวตนเดียวกันต้องสามารถสร้างพื้นที่ทํางานบนความจุ และ ถูกเพิ่มเป็นสมาชิกพื้นที่ทํางานได้ หากการจัดเตรียมล้มเหลวเนื่องจากข้อผิดพลาดการอนุญาต ให้ตรวจสอบการตั้งค่าผู้เช่าและการกําหนดบทบาทความจุจาก ข้อกําหนดเบื้องต้นอีกครั้ง
• ความลับควรหลีกเลี่ยงรัฐเมื่อเป็นไปได้ connection secret ใช้อาร์กิวเมนต์แบบเขียนอย่างเดียว client_secret_wo จึงไม่ถูกเก็บในสถานะข้อความธรรมดา อย่างไรก็ตาม ควรปกป้องไฟล์สถานะของคุณว่าเป็นไฟล์ที่ละเอียดอ่อน

ขั้นตอนที่ 2: ตรวจสอบการเชื่อมต่อ Git

Terraform ได้เชื่อมต่อพื้นที่ทํางานสําหรับนักพัฒนากับ Git ใน ขั้นตอนที่ 1 แล้ว ยืนยัน:

1. ในพอร์ทัล Fabric ให้เปิดreleaseflow-devพื้นที่ทํางาน
2. เลือก การตั้งค่า>การรวม Git
3. ยืนยันว่าพื้นที่ทํางานเชื่อมต่อกับองค์กร Azure DevOps ของคุณ โปรเจกต์ ที่เก็บข้อมูล สาขา และโฟลเดอร์ที่คุณตั้งค่าไว้ในado_directory_name

ขั้นตอนที่ 3: เขียนเนื้อหาในโปรแกรมพัฒนาและคอมมิตเนื้อหานั้น

ตอนนี้เพิ่มเนื้อหาลงในพื้นที่ทํางานของนักพัฒนาและส่งไปยัง Git ในบทเรียนนี้คุณจะสร้างสองสิ่ง: บ้านริมทะเลสาบและสมุดโน้ตที่อ่านจากมัน

1. ใน releaseflow-dev, สร้างบ้านริมทะเลสาบชื่อ demoLakehouse
2. สร้างสมุดบันทึกชื่อ demoNotebook แนบ demoLakehouse เป็น lakehouse เริ่มต้นและเพิ่มเซลล์ที่อ่านตารางหรือเขียนตัวอย่าง DataFrame ขนาดเล็ก
3. ลองรันสมุดบันทึกครั้งหนึ่งเพื่อยืนยันว่ามันใช้ได้กับ dev lakehouse
4. Open Source control ในพื้นที่ทํางาน เลือกทั้งสองรายการ และ Commit ไปยังสาขาของคุณ

หลังจากคอมมิต รีโพซิทอรีของคุณจะมีโฟลเดอร์และdemoLakehouse.LakehousedemoNotebook.Notebookโฟลเดอร์หนึ่งอยู่ใต้ไดเรกทอรีที่คุณกําหนดค่าไว้

ขั้นตอนที่ 4: ติดตั้งจากนักพัฒนาเพื่อทดสอบด้วย fabric-cicd

พื้นที่ทํางานทดสอบยังคงว่างเปล่า ใช้ fabric-cicd เพื่อเผยแพร่รายการจาก Git ลงใน test โดยผูกสมุดโน้ตเข้ากับ test lakehouse ระหว่างทาง

ติดตั้ง fabric-cicd

สร้าง requirements.txt:

fabric-cicd>=0.1.20
azure-identity>=1.17.0

ติดตั้ง:

pip install -r requirements.txt

เพิ่มไฟล์พารามิเตอร์

โน้ตบุ๊กที่เก็บไว้ใน Git points ที่ dev lakehouse และ dev workspace เมื่อคุณติดตั้งเพื่อทดสอบ การอ้างอิงเหล่านั้นต้องเปลี่ยนแปลงเพื่อให้สมุดบันทึกอ่านและเขียนข้อมูลทดสอบ Fabric-CICD ทําสิ่งนี้กับ parameter.yml ไฟล์

สร้าง parameter.yml ถัดจากสคริปต์การปรับใช้ของคุณ แทนที่ GUID สองตําแหน่งนั้นด้วย ID dev lakehouse และ dev workspace ID จริงที่ปรากฏในเนื้อหาสมุดบันทึกที่ commit ของคุณ:

find_replace:
  # DEV lakehouse id -> the deployed demoLakehouse id in the target workspace.
  - find_value: "<dev-lakehouse-guid>"
    replace_value:
      test: "$items.Lakehouse.demoLakehouse.$id"
    item_type: "Notebook"
    item_name: "demoNotebook"
    file_path: "/demoNotebook.Notebook/notebook-content.py"

  # DEV workspace id -> the target workspace id.
  - find_value: "<dev-workspace-guid>"
    replace_value:
      test: "$workspace.$id"
    item_type: "Notebook"
    item_name: "demoNotebook"
    file_path: "/demoNotebook.Notebook/notebook-content.py"

$items.Lakehouse.demoLakehouse.$idโทเค็น and $workspace.$id จะถูกแก้ไขโดย fabric-cicd เมื่อถึงเวลาปรับใช้ไปยัง GUID ในพื้นที่ทํางานเป้าหมาย

เขียนสคริปต์การปรับใช้

สร้าง deploy.py:

import argparse
from azure.identity import DefaultAzureCredential
from fabric_cicd import (
    FabricWorkspace,
    publish_all_items,
    unpublish_all_orphan_items,
)

ITEM_TYPES = ["Lakehouse", "Notebook"]


def main() -> None:
    p = argparse.ArgumentParser()
    p.add_argument("--workspace_name", required=True)
    p.add_argument("--environment", required=True)
    p.add_argument("--repository_directory", default="./workspace")
    p.add_argument("--parameter_file", default="./parameter.yml")
    args = p.parse_args()

    target = FabricWorkspace(
        workspace_name=args.workspace_name,
        environment=args.environment,
        repository_directory=args.repository_directory,
        item_type_in_scope=ITEM_TYPES,
        parameter_file_path=args.parameter_file,
        token_credential=DefaultAzureCredential(),
    )

    # Create or update every item, applying parameter.yml.
    publish_all_items(target)
    # Remove items deleted from the repo so test mirrors the branch.
    unpublish_all_orphan_items(target)

    print(f"Deployment to '{args.workspace_name}' complete.")


if __name__ == "__main__":
    main()

เรียกใช้การปรับใช้

ชี้สคริปต์ไปที่ชื่อพื้นที่ทดสอบที่ Terraform พิมพ์เป็น test_workspace_name. โคลน repo ของคุณ (หรือใช้สําเนาในเครื่องที่นักพัฒนาคอมมิตไว้) เพื่อให้โฟลเดอร์ไอเท็มพร้อมใช้งานในเครื่อง จากนั้นรัน:

python deploy.py \
  --workspace_name releaseflow-test \
  --environment test \
  --repository_directory ./workspace \
  --parameter_file ./parameter.yml

Fabric-CICD สร้าง Lakehouse และสมุดบันทึกในการทดสอบ ใช้ find_replace กฎ และรายงานแต่ละรายการที่เผยแพร่

ขั้นตอนที่ 5: ยืนยันโปรโมชั่น

ยืนยันว่าการทดสอบได้รับสําเนารีบาวด์ที่ถูกต้องของเนื้อหา:

1. ในพอร์ทัล Fabric ให้เปิดreleaseflow-testพื้นที่ทํางาน
2. ยืนยันว่า demoLakehouse และ demoNotebook มีอยู่แล้ว
3. เปิด demoNotebook แล้วยืนยันว่า lakehouse เริ่มต้นคือ การทดสอบdemoLakehouse ไม่ใช่ของ dev
4. เรียกใช้สมุดบันทึก มันควรจะอ่านและเขียน testlakehouse ได้

ตอนนี้คุณมีวงจรชีวิตที่ทําซ้ําได้: เปลี่ยนไอเท็มในการพัฒนา, commit ไป Git แล้วรัน deploy.py ใหม่เพื่อโปรโมทเพื่อทดสอบ

Automate in Azure DevOps

ทุกอย่างที่คุณรันในเครื่องจะใช้หลักการบริการเดียวกับที่ pipeline ใช้ ดังนั้นการเปลี่ยนไป CI/CD ส่วนใหญ่จะเป็นเรื่องของการวางคําสั่งเหล่านี้ในขั้นตอนของ pipeline: ขั้นตอนหนึ่งรัน terraform apply (control plane), ขั้นตอนหลังรัน deploy.py (data plane) สําหรับคําแนะนําเต็มรูปแบบของ Azure Pipelines ที่มีระบบ gated ในขั้นตอนการปรับใช้ fabric-cicd รวมถึงกลุ่มตัวแปรและการอนุมัติ โปรดดูที่ Tutorial: CI/CD using Azure DevOps and the fabric-cicd library

ขยายบทเรียนนี้

บทเรียนนี้ใช้สมุดโน้ตและบ้านริมทะเลสาบ รูปแบบเดียวกันนี้ขยายไปยังส่วนของระนาบข้อมูลมากขึ้น:

• เพิ่ม SemanticModel และ Report เพิ่มITEM_TYPESsemantic_model_bindingกฎ parameter.yml เพื่อชี้โมเดลไปยังการเชื่อมต่อของแต่ละสภาพแวดล้อม
• เพิ่ม a VariableLibrary และให้ fabric-cicd เปิดใช้งานชุดค่าที่ตรงกับ --environment you pass
• เพิ่มขั้นตอนหลังการปรับใช้ (เช่น รีเฟรชโมเดลเชิงความหมายหรือรันสมุดบันทึกทดสอบควัน) หลังจาก publish_all_items.

ล้างแหล่งข้อมูล

เพื่อหลีกเลี่ยงการใช้ความจุ ให้ลบพื้นที่ทํางานที่คุณสร้างขึ้น จากโฟลเดอร์ Terraform ของคุณ:

terraform destroy

อีกทางเลือกหนึ่ง คือ ลบ releaseflow-dev และ releaseflow-test workspaces ออกจากพอร์ทัล Fabric

เนื้อหาที่เกี่ยวข้อง

• CI/CD ใน Microsoft Fabric คืออะไร?
• ตัวเลือกเวิร์กโฟลว์ CI/CD ใน Fabric
• บทช่วยสอน: CI/CD โดยใช้ Azure DevOps และไลบรารี fabric-cicd
• บทเรียน: CI/CD โดยใช้ Fabric bulk API
• บทเรียน: การจัดการวงจรชีวิตแอปพลิเคชันใน Fabric
• ผู้ให้บริการ Microsoft Fabric Terraform
• เอกสารสําหรับห้องสมุด Fabric-CICD