tsql - SQL Server 数据库更改部署

Question

我正在努力跟上数据库的变化，以及如何干净地维护和部署从 Dev 到 PRD 从一个版本到另一个版本的数据库更改。

目前，我使用 SQL 脚本来弄清楚自上次发布以来发生了什么变化；

• Procs 和 Views 更容易推进，因为我可以简单地删除并重新创建(如果存在)。
• 表更改更加困难，因为不能简单地删除现有表。

但我认为我无法解决的主要问题是，在任何两个主要 PRD 版本之间，我们都有多个针对 Dev 和 UAT 的迷你版本。

Dev 和 UAT mini 版本是可以的，因为我从其他开发人员那里得到了一份更改列表，我将它与我的更改列表结合起来，然后发布一个版本，而且我是 Dev 和 UAT 数据库的系统管理员，所以我确切地知道是什么在那里，当我应用更改时会发生什么。

对于 PRD，我必须准备一个干净的脚本并将其交给 DBA，以便他可以在那里运行它，但除了 PRD 上的表名、列和数据之外，我无法查看任何其他内容。

PRD 的这个脚本应该捕获几乎所有已进入迷你版本的内容，但大多数时候这些迷你版本不是连续的，有时会相互抵消，因为一个添加功能 A，然后后续版本删除功能 A 但对于 PRD，我们可能必须添加功能 A，因此无需进行第二次迷你发布，这将有效删除功能 A。

简而言之，我正在寻找管理和跟踪版本之间数据库更改的方法，以及为数据库更改构建部署脚本的好方法。

注意:我在 TFS 中保留了一份手动维护的所有 SQL 对象的副本。

我尝试使用数据库项目，但我并没有很幸运地实现我想要的。

有什么想法吗？非常感谢任何帮助

Answer 1

我不熟悉 TFS，我使用的是 Git(以前是 CVS 和 SVN)，因此请正确看待这个答案。

管理和版本控制 SQL 位一直是我最糟糕的噩梦。 有一些工具可以简化变更管理，red-gate SQL Developer Bundle，它可以处理比较，也可以连接到版本控制系统。在较小的程度上满足您的要求，您拥有 idera SQL 比较工具集，idera 对一切的完美主义方法不应被过分看待。

无论如何，在我看来，管理变更不能也不应该作为一项技术性的事情来处理，它必须是 IT 治理和程序的一部分，它需要在任何相关职能部门之间进行记录和沟通。

当一些小型发布、热修复、微更改或类似的事情发生时，它们必须反射(reflect)在需要获取它的所有其他环境中。

当然，如果在生产中有一个迷你版本，而你是 UAT 的中间人，你可能不想在那个环境中插入迷你版本。 IMO，在 UAT 之后不久，您应该将迷你版本应用于环境并执行 E2E QA session 以确保环境良好。

如果你阅读我之前的段落你可能会发现一些问题假设 UAT 有一个 SP 版本 4 而迷你版本相同的 SP 是 2 ...你如何确保你不会导致回归?

这时候版本控制系统和合并工具就派上用场了。 Red Gate 工具还可以帮助您构建部署。

但是，我相信治理、沟通和遵守规则是持续成功的最重要因素。

今天的趋势是实现持续集成，按需构建测试环境，有内部的、托管的和云端的。通常它们的 build 和维护并不便宜，但它们会带来返回!

最后但并非最不重要的一点是，在开发 SQL 部署时您应该遵守的一些相同规则:

1. 每个更改脚本都应该是可重复的，例如
   • 创建过程前检查是否存在，创建前删除
   • 在任何插入之前检查该行不存在然后插入其他更新
2. 当部署到多个数据库时，每个更改脚本都必须确保您使用正确的数据库(在这里我发现同义词是自开 jar 器诞生以来最好的发明之一)
3. 更改脚本应该遵循一个顺序。对于每个对象:
   • DDL
   • 为上面的 DDL 应用 DCL
   • 为表应用 DML。
4. 我发现脚本的最佳顺序是
   • 创建/更改表
   • 创建/更改 View
   • 刷新所有 View
   • 创建/更改函数
   • 创建/更改函数
   • 执行每个 DML。
5. 在每个脚本中避免无法按 ABC 对脚本的子部分进行排序的诱惑，通常您有 FK 或 SP 之类的依赖项来执行其他 SP，这使 ABC 方法令人沮丧。