𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽
您的部署成功完成。您的 Azure DevOps 流水线通过了。生产环境工作区看起来完美无缺。
然而，周一早晨降临了。
语义模型刷新失败。Lakehouse 分区损坏。每个用户的报表都超时。
这正是大多数教程所忽略的 Microsoft Fabric CI/CD 的另一面。
大多数英文资源展示的是“Hello World”级别的设置。它们教你如何同步项目（items）。但它们没有教你如何运行真实的生产环境。
我研究了来自日本开发者社区 Qiita 的文档。他们已经摸索出了生产级 Fabric 部署中存在的真实问题。
Fabric 将一切都视为项目（items）。这些项目包括语义模型（semantic models）、Lakehouse、流水线（pipelines）、报表（reports）和笔记本（notebooks）。其目标是将这些项目视为代码。
标准的工作流如下：
- 源码控制：将项目作为 JSON 定义导出到您的仓库中。
- 构建阶段：验证配置和依赖关系。
- 发布阶段：使用环境参数部署到目标工作区。
但这种简单的流程在规模扩大时会失效。原因如下：
依赖错误 教程说您可以按任何顺序部署项目。这是错误的。语义模型依赖于 Lakehouse。如果您在 Lakehouse 更新之前部署了模型，刷新就会失败。
API 限制 教程建议使用一个流水线处理所有事务。大型工作区在并发部署期间会触及 Fabric API 的速率限制。您需要逻辑来减缓处理速度。
容量差异 模型在测试环境中可能运行正常，但在生产环境中可能会失败。生产工作区通常具有不同的容量层级和功能限制。
如果您想从教程过渡到真实的生产环境设置，请遵循以下规则：
- 使用顺序部署。根据依赖关系定义项目的部署顺序。
- 实现工作区锁定。防止两个流水线同时运行。这可以防止工作区损坏。
- 保留一个备份工作区。如果部署失败，将其作为回滚目标。
- 使用感知容量的参数。根据您实际的生产容量来测试您的设置。
工具是现成的，模式也是行之有效的。您只需要为那些教程中略过的失败做好准备。
您的团队是否遇到过教程中未提及的部署失败？生产环境检查清单中还应该包含哪些内容？
Microsoft Fabric CI/CD：没人谈论的部署鸿沟
Microsoft Fabric 正在迅速改变数据工程、数据科学和分析的游戏规则。它提供了一个统一的、SaaS 化的平台，将数据湖、数据仓库和数据集成功能整合在一起。
然而，对于那些习惯于成熟 DevOps 实践的企业级用户来说，Fabric 的 CI/CD（持续集成/持续部署）现状却显得有些令人困惑。虽然 Microsoft 提供了工具，但这些工具之间存在一个明显的“鸿沟”，如果不解决这个问题，自动化部署将变得异常困难。
Fabric DevOps 的两大支柱
目前，Microsoft Fabric 主要依靠两种方式来实现 DevOps 流程：
1. Git 集成 (Git Integration)
Fabric 允许用户将工作区 (Workspace) 与 Azure DevOps 或 GitHub 仓库进行同步。这使得开发者可以将 Fabric 项目（如 Notebooks、Lakehouse 的定义、语义模型等）作为代码进行版本控制。
优点：
- 版本控制。
- 代码审查 (Code Review)。
- 协作开发。
2. 部署流水线 (Deployment Pipelines)
这是 Fabric 提供的一种内置功能，用于在不同的工作区（例如：开发、测试、生产）之间移动内容。它允许你通过图形界面或 API 快速将已完成的项目从一个环境推送到另一个环境。
优点：
- 环境隔离。
- 简单的 UI 操作。
- 支持规则配置（例如，在不同环境中更改连接字符串）。
鸿沟：两者之间的脱节
这就是问题所在：Git 集成和部署流水线是两个相互独立的“孤岛”。
在理想的 CI/CD 工作流中，流程应该是这样的：
编写代码 -> Git Commit -> Pull Request -> 合并到主分支 -> 自动触发部署到测试环境 -> 自动触发部署到生产环境。
但在目前的 Microsoft Fabric 中，这个流程是断裂的：
- Git 集成是“工作区 <-> 仓库”的同步：当你将代码推送到 Git 时，它只是更新了仓库。它并不会自动触发将这些更改“部署”到另一个工作区。
- 部署流水线是“工作区 <-> 工作区”的移动：部署流水线主要基于 Fabric 内部的项目定义进行移动，它并不直接感知 Git 仓库的状态。
这意味着什么？
如果你使用 Git 来管理开发，当你合并代码到 main 分支后，你仍然需要手动进入 Fabric 界面，或者编写复杂的自定义脚本，来触发部署流水线将这些更改从“开发工作区”推送到“测试工作区”。
这种脱节导致了所谓的“部署鸿沟”：你拥有了版本控制，但你还没有实现真正的自动化部署。
为什么这很重要？
对于小型项目，手动点击“部署”可能没问题。但对于大型企业，这种脱节会带来以下风险：
- 环境不一致：手动部署容易出错，可能导致测试环境和生产环境的代码版本不匹配。
- 缺乏审计追踪：如果部署不是由 Git 触发的，那么很难追踪“究竟是哪次代码提交导致了生产环境的变化”。
- 无法实现真正的 DevOps：无法实现完全自动化的流水线，意味着开发速度会受到人为干预的限制。
如何弥补这一鸿沟？
虽然目前没有“一键式”的完美解决方案，但你可以通过以下几种方式来缓解这个问题：
1. 使用 Fabric REST API 和 Azure DevOps Pipelines
这是目前最专业的做法。你可以利用 Azure DevOps Pipelines 来编排整个流程。当 Git 仓库发生变化时，触发一个 Pipeline，该 Pipeline 调用 Fabric 的 REST API 来触发部署流水线。
2. 编写自定义脚本
使用 Python 或 PowerShell 编写脚本，通过 API 自动化执行从 Git 同步到部署流水线触发的操作。
3. 关注 Fabric 的演进
Microsoft 正在不断改进 Fabric。随着 API 的完善和对更多项目类型的支持，这种集成可能会变得更加自然。
总结
Microsoft Fabric 拥有强大的潜力，但其 CI/CD 流程目前仍处于“半自动化”阶段。理解 Git 集成与部署流水线之间的脱节，对于构建可靠、可扩展的数据平台至关重要。不要仅仅满足于拥有版本控制，要致力于构建一个能够连接代码与环境的完整自动化链路。