使用管道部署仓库

适用于:✅ Microsoft Fabric 中的“仓库”模块

Microsoft Fabric流水线为跨工作区(如开发→测试→生产)之间更改仓库模式提供了一种简化的方式。 管道内置依赖处理、模式验证和声明式部署智能。

Important

此功能目前为预览版

本文将解释使用管道的仓库部署流程。

Fabric Data Warehouse的管道部署生命周期示意图。

部署管道提供了安全跨工作区移动仓库变更所需的生命周期结构。 它们作为模式推广的中央编排层,使团队能够标准化变更如何通过分析平台流动,而不必依赖临时部署。 一旦创建,流水线就成为比较仓库、审查变更和执行部署的主要接口。

创建管道

要创建新的管道,请参见“ 开始使用部署管道 创建和管理部署管道”。

比较

部署前务必核实并比较T-SQL的变更。 部署流水线在 Fabric 门户中提供了一个简单的比较界面,用于审查受影响的仓库对象。

审查这些变更可以让团队在推动下游环境更新前验证准备度。 这一过程在多个团队共同参与仓库开发的企业场景中尤为重要。

Fabric 使用 DacFx(数据层应用框架)进行此比较。 DacFx 构建了两种环境的声明式模式模型,并识别新表、修改后的列、约束或依赖变化等差异。 由于这种比较是基于模型的,它准确反映了部署过程中发生的情况。

Important

为了实现模式比较,仓库必须同时存在于源工作区和目标工作区中。 如果目标工作区还没有仓库,先创建或部署初始基线版本。

Note

如果某列 COLLATE 的从句明确指定了与仓库默认排序相同的排序,比较时不会显示为差异,因为这等同于根本没有指定排序。 只有那些与仓库默认排序不同的列,在合并发生变化时才会出现在比较中。 如需更多信息和示例,请参见“排查 Git 集成以Fabric Data Warehouse开发”。

在部署任何变更之前,利用部署流水线的比较功能来审查源仓库与目标仓库工作空间之间的差异。

在Fabric门户中截图,使用流水线比较两个不同工作区的仓库。

选择 比较 并查看更改,例如在仓库中创建新视图:

一个州仓库和另一个州仓库的对比截图。

Deploy

比较结束并验证更改后,你可以直接从流水线界面选择要推广的仓库项目来部署。

从Fabric门户截图,部署到该阶段的流程界面。

部署过程中,部署管道利用 DacFx 根据模式差异生成智能部署计划。 Fabric只应用必要的更改,使目标工作区与源文件同步。

来自 Fabric 门户的成功部署截图。

部署配置

Fabric部署流水线采用DacFx部署技术,配置专门针对Fabric Data Warehouse。 这些配置确保部署能够可靠成功,同时与 Fabric 平台的能力和运营实践保持一致。

  • 可能的数据丢失阻断(BlockOnPossibleDataLoss = true - Fabric Data Warehouse 防止可能截断、丢弃或丢失用户数据的部署。 这种设置防止高风险模式变更通过CI/CD过滤,使数据丢失风险成为有意为之,而非默许默认。

  • 跳过数据库级选项脚本(ScriptDatabaseOptions = false——Fabric 在平台层面管理许多数据库级设置。 部署期间的脚本语句 ALTER DATABASE ... SET 可能导致失败或意外配置漂移。 因此,部署流水线避免传播这些设置,确保模式部署仅聚焦于支持的仓库对象。

  • 允许对复制对象进行引擎强制执行(DoNotAlterReplicatedObjects = false ——仓库通常使用内部复制机制,例如在链接或同步场景中。 部署流水线不再提前阻止模式变更,而是允许 Fabric 引擎判断是否允许更改。 这种方法防止了不必要的部署失败,同时保持了平台的安全性。

  • 禁用事务式DDL脚本(IncludeTransactionalScripts = false ——仓库目前不支持在交易中封装DDL脚本。 因此,部署流水线生成非事务脚本,以确保部署成功完成。

  • 使用智能默认值进行模式演进(GenerateSmartDefaults = true ——当模式变更引入更严格的约束时,例如将可空列转换为不可空列或添加带有默认约束的新列,部署管道可以自动填充基线值。 这种方法帮助部署成功,无需手动准备数据,并减少了模式演进过程中的操作摩擦。

  • 从部署中排除安全主体(ExcludeObjectTypes = Logins, Users, Permissions ——安全对象被有意排除在仓库部署之外。 跨环境推广登录、用户或权限可能会带来安全风险或环境特定的冲突。 相反,应通过环境治理或身份管理流程单独管理访问控制。

  • 不丢弃源代码中不存在的对象(DropObjectsNotInSource = false - 目标中存在但不在源代码中的对象不会自动丢弃。 那些能让生产与源码控制完美同步的仓库可能会觉得这很受限。

Limitations

  • 默认情况下,系统会阻止表丢失。 部署过程不会自动丢弃目标中存在但源端不存在的对象。 这种设计减少了意外的数据丢失,并防止了生产环境中的意外删除。
  • 成功的部署并不总是意味着所有请求的更改都被应用了。 即使部署跳过了请求的丢弃表动作,也能报告成功,因为默认情况下,表丢弃是被阻挡的。 在这种情况下,部署操作完成了,但目标仍可能偏离源码控制,直到你明确解决缺失的变更。
  • 目前,部署过程优先考虑安全而非严格的源码奇偶校验,不丢弃仅存在于目标中的对象。
  • Fabric 部署管道不支持 SQL 分析端点项。
  • SQL 分析终结点与仓库之间的跨项依赖关系、项排序和同步差距会影响 Fabric 部署管道工作流。
  • 不支持在部署流程中选择相关项目用于Fabric Data Warehouse。

Git 集成故障排查

关于 Git 集成的具体限制,请参见 Git 集成文章中的 “Git 集成的限制 ”。

关于Fabric Data Warehouse开发中常见Git集成问题的排查、变通方法和修复方法,请参见“Fabric Data Warehouse开发中的Git集成故障排除”。