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

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

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

我想听听SO社区的一些想法，这些想法在现实世界中是有效的。

我意识到哪种做法真正最好是有些主观的，但是我认为就什么工作进行良好的对话可能对许多人有帮助。

这是我的一些预告片问题，涉及该主题的关注 Realm 。这些并不是最终的 list ，而是人们了解我在寻找什么的起点。

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

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

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

您如何测试部署脚本与生产中的测试一样有效？

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

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

索引？

约束？

表定义？

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

一切吗？

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

序列？

Grants？

用户帐户？

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

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

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

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

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

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

可以合理地对此过程进行哪些异常(exception)(如果有)？

安全问题？

数据是否涉及身份识别问题？

无法完全自动化的脚本？

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

开发人员出错？

遇到意外的环境问题吗？

用于灾难恢复吗？

您如何使决策者相信DB-SCM的优势确实证明了成本合理？

传闻证据？

行业研究？

行业最佳实践建议？

呼吁公认的当局吗？

成本/效益分析？

在此模型中，谁应该“拥有”数据库对象？

开发人员？

DBA？

数据分析师？

不止一个？

最佳答案

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

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

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

两者的自动化。不要在环境

之间复制数据

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

使用模板，以便实际上您将为每种环境生成不同的脚本集(例如，对外部系统，链接数据库的引用)。

您如何测试部署脚本与生产中的测试一样有效？

您可以在生产前环境中对其进行测试:在生产环境(数据库和其他系统)的精确副本上测试部署

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

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

索引？

约束？

表定义？

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

一切吗？

一切，以及:

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

仅保留当前版本的数据库脚本(当然是版本控制的)，以及

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

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

序列？

Grants？

用户帐户？

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

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

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

请参阅2。

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

已从数据库中删除，已从源代码控制主干/提示中删除

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

开发/测试/发布时间表

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

尝试不要为每个开发人员创建一个单独的数据库。您使用源代码控制，对不对？在这种情况下，开发人员将更改数据库并 checkin 脚本。为了完全安全，请在每晚构建

期间从脚本重新创建数据库

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

艰难的一件事:不惜一切代价避免。