| name | fabric-alm-cicd |
| description | Plan, implement, review, and troubleshoot Microsoft Fabric ALM and CI/CD workflows using Git integration, deployment pipelines, Variable Libraries, Fabric REST APIs, fabric-cicd, GitHub Actions, or Azure DevOps. Use when the user asks about source control, deploy, promote, release, dev/test/prod, environment variables, deployment pipeline automation, Git sync, fabric-cicd, or Fabric item definition validation.
|
Fabric ALM and CI/CD
Use this skill for lifecycle management across Fabric workspaces and item types. For endpoint-specific definition details, delegate to the relevant authoring skill after the release shape is clear.
Required References
Workflow
- Identify the workspace, environments, capacity boundaries, and deployment target.
- Inventory Fabric items and classify each item as source-controlled, deployment-pipeline supported, REST-definition deployable, or manual/unsupported.
- Choose the release mechanism:
- Git integration plus deployment pipelines for productized team workflows.
fabric-cicd for code-first definition deployments.- Direct REST
updateDefinition for targeted automation or item types with known definition envelopes.
- Define environment configuration through Variable Libraries, deployment rules, or external config files.
- Add validation gates before deployment and smoke checks after deployment.
- Document permissions, token audiences, tenant settings, and rollback steps.
Delegation
Route endpoint details to specialized skills:
| Need | Delegate |
|---|
| Notebook, Lakehouse, Spark Job Definition, Environment | spark-authoring-cli |
| Warehouse DDL/source control details | sqldw-authoring-cli |
| Dataflows Gen2 definition CI/CD | dataflows-authoring-cli |
| Power BI semantic model/TMDL refresh and deployment | powerbi-authoring-cli |
| Eventhouse/KQL schema scripts | eventhouse-authoring-cli |
| Eventstream topology deployment | eventstream-authoring-cli |
| Workspace security/capacity/governance | FabricAdmin |
Must
- Handle pagination, LRO, throttling, and
Retry-After on all REST automation.
- Use the correct token audience per API family.
- Treat item pairing and workspace assignment as deployment prerequisites.
- Keep secrets out of item definitions, notebooks, prompts, and repository files.
- Validate environment-specific item IDs and connection IDs before deployment.
- Include post-deploy verification, not just deployment success.
Prefer
- Variable Library value sets for dev/test/prod configuration.
- Git-connected development workspace and deployment pipelines for team ALM.
- Small, reversible releases with explicit smoke tests.
- Source-controlled plain definition parts rather than opaque base64 blobs.
- Release notes that include operation IDs and run IDs.
Avoid
- Assuming every Fabric item supports Git integration or deployment pipelines.
- Deploying by display name only when stable IDs or pairing are required.
- Using deployment pipelines for Warehouse data movement; they promote schema and content definitions, not data.
- Updating existing items by recreating them; resolve item ID and call
updateDefinition where appropriate.
- Reusing a Fabric REST token for SQL, OneLake, KQL, or Power BI endpoints.
Output Format
For planning requests, return a release plan with:
- Workspace/environment map
- Item support matrix
- Configuration and secret strategy
- Deployment mechanism per item
- Validation gates
- Required permissions
- Rollback and recovery notes
