Fabric CI/CD Deployment Checklist

1. GitReviewed, merged change
2. BuildVersioned artifacts
3. TestDeploy and verify
4. ProductionSame artifacts, prod config
5. RecordVersion and results

Before deployment

• Git is clean: everything to deploy is committed and merged; nothing exists only in a workspace.
• Branch reviewed: the change went through a pull request, and the reviewer knows what it touches.
• Environment configuration externalized: connections, paths and IDs come from variable libraries, parameters or deployment settings, not from notebook code.
• Dependencies checked: new Lakehouses, tables, shortcuts, connections or libraries exist in the target environment, or are part of this deployment.
• Workspace references checked: no hard-coded Dev workspace or Lakehouse IDs, default Lakehouse bindings or ABFS paths remain.
• Secrets and configuration validated: secrets live in a vault or connection, never in code; target values are set for every environment.
• Order known: items that depend on others (Warehouse schema before views, Lakehouse before notebooks) deploy in the right order.

Deploy

• Promote versioned artifacts: deploy the commit or build that passed Test, not a fresh export from Dev.
• Use the pipeline, not the portal: deployment pipelines, fabric-cicd, SQL database projects or your own tooling, the same way every time.
• Validate the deployment: the run reports success for every item, and failures stop the release instead of continuing partially.
• Review destructive changes: for Warehouses, read the schema diff before it runs.
• Avoid manual Production edits: any hotfix goes back through Git, or it will be overwritten by the next release.

After deployment

• Run smoke tests: a small, known run that proves the main path works.
• Verify notebooks and pipelines: they run in the target workspace and read and write the target Lakehouse, not Dev.
• Verify SQL and Warehouse dependencies: views, procedures and semantic models resolve against the new schema.
• Check logging: runs appear in your logs and monitoring with the expected environment name.
• Check failures: review failed activities and alerts for the first scheduled runs.
• Record the deployed version: commit or build ID, date, who approved it, and the result of the checks.