别再视数据库为特殊雪花：正确使用 Azure DevOps + SQL Projects

Emiliano Montesdeoca — Wed, 15 Jul 2026 00:00:00 +0000

很多团队声称自己在做 DevOps，然后却从某人的笔记本电脑上手动部署数据库变更。这种矛盾正是这个 Azure SQL 指南要解决的。SQL 项目加上 Azure DevOps 管道，使数据库交付变得确定性、可审计且足够安全以应对真实的生产工作流。

原文来源：https://devblogs.microsoft.com/azure-sql/fundamentals-of-azure-devops-with-sql-projects/

该方法中最强大的部分不是 YAML 语法，而是纪律序列：先构建，再发布，然后用最小权限和无密码身份保护部署路径。用 dotnet build 构建 .sqlproj 能在早期验证目标平台兼容性，并生成一个可以在环境间提升的 DACPAC 制品。

我的观点很直白：如果你的架构不在 CI 中构建，你的数据库质量过程基本就是在碰运气。在 SSMS 或 VS Code 中的本地成功不是发布保证。

部署设计也非常务实。使用与 Entra 身份关联的服务连接，授予用于架构和数据比较的限定范围数据库角色，以及为运行者 IP 自动临时开放防火墙并保证清理。这就是那种团队直到安全审查迫使他们重新审视一切时才肯做的运维卫生。

不要过早过度授权。 以 db_ddladmin、db_datareader 和 db_datawriter 开始是比给每个管道主体授予 db_owner“只是为了让它工作"更好的基线。只有在具体的部署需求证明必要时才提升权限。

另一个重要的收获是可移植性。因为 SQL 项目运行在 .NET SDK 工具链上，这个模式不限于 Azure DevOps。相同的基本原则可以迁移到 GitHub Actions 或其他编排器——这使得这个指南具有战略性，而非平台锁定。

核心观点

如果你的组织仍然将架构交付视为应用 CI/CD 之外的特殊流程，这就是你的迁移蓝图。你不需要英雄般的平台工程。你需要一致性、身份优先的安全，以及停止通过临时权限路径交付数据库变更的意愿。

这样做的团队将交付更快、回滚事件更少。推迟的团队将继续为手动数据平面部署的隐性成本买单。