database - 你应该如何从源代码控制构建你的数据库？

Question

在 SO 社区 wiki 上有一些关于是否应该对数据库对象进行版本控制的讨论。然而，我还没有看到太多关于为数据库对象创建构建自动化过程的最佳实践的讨论。

对于我的团队来说，这一直是一个有争议的讨论点 - 特别是因为在评估数据库部署自动化方法的好处和风险时，开发人员和 DBA 通常有不同的目标、方法和关注点。

我想听听 SO 社区关于哪些实践在现实世界中有效的一些想法。

我意识到哪种做法​​真的最好是有点主观的，但我认为关于什么工作的良好对话可能对许多人有帮助。

以下是我关于本主题关注领域的一些预告问题。这些并不意味着是一个明确的列表——而是人们帮助理解我在寻找什么的起点。

测试和生产环境都应该从源代码控制构建吗？

两者都应该使用自动化构建 - 还是应该通过从稳定的最终测试环境中复制对象来构建生产？

您如何处理部署脚本中测试和生产环境之间的潜在差异？

您如何测试部署脚本是否能像在测试中一样有效地用于生产？

应该对哪些类型的对象进行版本控制？

只是代码(过程、包、触发器、java 等)？

索引？

限制？

表定义？

表更改脚本？ (例如 ALTER 脚本)

一切？

哪些类型的对象不应该进行版本控制？

序列？

拨款？

用户帐户？

应该如何在 SCM 存储库中组织数据库对象？

您如何处理诸如转换脚本或 ALTER 脚本之类的一次性事情？

你如何处理从数据库中退休的对象？

谁应该负责将对象从开发级别提升到测试级别？

您如何协调多个开发人员的更改？

您如何处理多个系统使用的数据库对象的分支？

这个过程有哪些异常(exception)，如果有的话，是合理的？

安全问题？

具有去标识化问题的数据？

不能完全自动化的脚本？

您如何使流程具有弹性和可执行性？

开发人员错误？

到意想不到的环境问题？

用于灾难恢复？

您如何让决策者相信 DB-SCM 的好处确实证明了成本的合理性？

轶事证据？

行业研究？

行业最佳实践建议？

向公认的当局上诉？

成本/ yield 分析？

谁应该“拥有”这个模型中的数据库对象？

开发商？

数据库管理员？

数据分析师？

不止一个？

Answer 1

以下是您问题的一些答案:

测试和生产环境都应该从源代码控制构建吗？ 是

两者都应该使用自动化构建 - 还是应该通过从稳定的最终测试环境中复制对象来构建生产？

两者都自动化。不要在环境之间复制数据

您如何处理部署脚本中测试和生产环境之间的潜在差异？

使用模板，这样实际上您可以为每个环境生成不同的脚本集(例如对外部系统、链接数据库等的引用)

您如何测试部署脚本是否能像在测试中一样有效地用于生产？

您在预生产环境中测试它们:在生产环境(数据库和可能的其他系统)的精确副本上测试部署

应该对哪些类型的对象进行版本控制？

只是代码(过程、包、触发器、java 等)？

索引？

限制？

表定义？

表更改脚本？ (例如 ALTER 脚本)

一切？

一切，以及:

不要忘记静态数据(查找列表等)，因此您不需要在环境之间复制任何数据

仅保留当前版本的数据库脚本(当然是受版本控制的)和

存储 ALTER 脚本:1 个 BIG 脚本(或名为 like 001_AlterXXX.sql 的脚本目录，以便以自然排序顺序运行它们将从版本 A 升级到 B)

哪些类型的对象不应该进行版本控制？

序列？

拨款？

用户帐户？

请参阅 2。如果您的用户/角色(或技术用户名)在不同环境中不同，您仍然可以使用模板编写脚本(请参阅 1。)

应该如何在 SCM 存储库中组织数据库对象？

您如何处理诸如转换脚本或 ALTER 脚本之类的一次性事情？

见 2。

您如何处理从数据库中退休的对象？

从数据库中删除，从源代码管理主干/提示中删除

谁应该负责将对象从开发级别提升到测试级别？

开发/测试/发布时间表

您如何协调多个开发人员的更改？

尽量不要为每个开发人员创建一个单独的数据库。你使用源代码控制，对吗？在这种情况下，开发人员更改数据库并 checkin 脚本。为了完全安全，请在每晚构建期间从脚本重新创建数据库

您如何处理多个系统使用的数据库对象的分支？

难点之一:不惜一切代价尽量避免。

这个过程有哪些异常(exception)，如果有的话，是合理的？

安全问题？

不要存储测试/生产的密码。你可以允许它用于开发，特别是如果你每天/每晚自动重建数据库

具有去标识化问题的数据？

不能完全自动化的脚本？

使用发布信息/ALTER 脚本记录和存储

您如何使流程具有弹性和可执行性？

开发人员错误？

从头开始使用每日构建进行测试，并将结果与​​增量升级(使用 ALTER 从版本 A 到 B)进行比较。比较结果架构和静态数据

到意想不到的环境问题？

使用版本控制和备份

将 PROD 数据库模式与您认为的进行比较，尤其是在部署之前。 SuperDuperCool DBA 可能修复了您的工单系统中从未出现过的错误 :)

用于灾难恢复？

您如何让决策者相信 DB-SCM 的好处确实证明了成本的合理性？

轶事证据？

行业研究？

行业最佳实践建议？

向公认的当局上诉？

成本/ yield 分析？

如果开发人员和 DBA 同意，你不需要说服任何人，我认为(除非你需要钱购买像 dbGhost for MSSQL 这样的软件)

谁应该“拥有”这个模型中的数据库对象？

开发商？

数据库管理员？

数据分析师？

不止一个？

通常 DBA 批准模型(在 checkin 之前或作为代码审查的一部分之后)。他们绝对拥有与性能相关的对象。但总的来说，团队拥有它[当然还有雇主:)]