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

Question

关于数据库对象是否应该受版本控制的SO社区wiki已经有一些讨论.但是,我没有看到很多关于为数据库对象创建构建自动化过程的最佳实践的讨论.

这对我的团队来说是一个有争议的讨论点 - 特别是在评估数据库部署自动化方法的优势和风险时,开发人员和DBA通常有不同的目标,方法和关注点.

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

我意识到这有点主观,哪些实践真的是最好的,但我认为一个关于哪些工作可能对许多人有帮助的良好对话.

以下是我在此主题中关注领域的一些预告片问题.这些并不是一个明确的清单 - 而是人们帮助理解我正在寻找的东西的起点.

1. 测试和生产环境都应该从源代码控制构建吗？
   
   • 是应该使用自动化构建 - 还是应该通过从稳定的,最终的测试环境中复制对象来构建生产？
   • 您如何处理部署脚本中测试和生产环境之间的潜在差异？
   • 您如何测试部署脚本是否可以像测试一样有效地对抗生产？
2. 哪些类型的对象应该受版本控制？
   • 只是代码(程序,包,触发器,java等)？
   • 指标？
   • 约束？
   • 表定义？
   • 表更改脚本？(例如,ALTER脚本)
   • 一切？
3. 哪些类型的对象不应该受版本控制？
   • 序列？
   • 资助？
   • 用户帐户？
4. 如何在SCM存储库中组织数据库对象？
   • 你如何处理转换脚本或ALTER脚本之类的一次性事务？
   • 你如何处理退出数据库中的对象？
   • 谁应该负责将对象从开发推广到测试级别？
   • 如何协调来自多个开发人员的更改？
   • 您如何处理多个系统使用的数据库对象的分支？
5. 如果有的话,可以合理地对这个过程做出哪些例外？
   • 安全问题？
   • 具有去识别问题的数据？
   • 脚本无法完全自动化？
6. 如何使流程具有弹性和可执行性？
   • 开发者错误？
   • 出乎意料的环境问题？
   • 用于灾难恢复？
7. 您如何让决策者相信DB-SCM的好处真正证明了成本的合理性？
   • 传闻？
   • 行业研究？
   • 行业最佳实践建议？
   • 向公认的当局上诉？
   • 成本效益分析？
8. 谁应该在这个模型中"拥有"数据库对象？
   • 开发商？
   • 数据库管理员？
   • 数据分析师？
   • 超过一个？

Answer 1

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

1. 测试和生产环境都应该从源代码控制构建吗？是
   • 是应该使用自动化构建 - 还是应该通过从稳定的,最终的测试环境中复制对象来构建生产？
   • 两者的自动化.不要在环境之间复制数据
   • 您如何处理部署脚本中测试和生产环境之间的潜在差异？
   • 使用模板,这样实际上您可以为每个环境生成不同的脚本集(例如,对外部系统,链接数据库等的引用)
   • 您如何测试部署脚本是否可以像测试一样有效地对抗生产？
   • 您在预生产环境中测试它们:在生产环境的精确副本上测试部署(数据库和可能的其他系统)
2. 哪些类型的对象应该受版本控制？
   • 只是代码(程序,包,触发器,java等)？
   • 指标？
   • 约束？
   • 表定义？
   • 表更改脚本？(例如,ALTER脚本)
   • 一切？
   • 一切,和:
     • 不要忘记静态数据(查找列表等),因此您不需要在环境之间复制任何数据
     • 仅保留当前版本的数据库脚本(当然是受版本控制),以及
     • 存储ALTER脚本:1个BIG脚本(或名为like 001_AlterXXX.sql的脚本目录,因此以自然排序顺序运行它们将从A版升级到B)
3. 哪些类型的对象不应该受版本控制？
   • 序列？
   • 资助？
   • 用户帐户？
   • 请参阅2.如果您的用户/角色(或技术用户名)在不同环境之间有所不同,您仍然可以使用模板编写脚本(请参阅1.)
4. 如何在SCM存储库中组织数据库对象？
   • 你如何处理转换脚本或ALTER脚本之类的一次性事务？
   • 见2.
   • 你如何处理退出数据库中的对象？
   • 从DB中删除,从源控制主干/提示中删除
   • 谁应该负责将对象从开发推广到测试级别？
   • 开发/测试/发布时间表
   • 如何协调来自多个开发人员的更改？
   • 尽量不为每个开发人员创建单独的数据库.你使用源代码控制,对吗？在这种情况下,开发人员更改数据库并签入脚本.为了完全安全,在夜间构建期间从脚本重新创建数据库
   • 您如何处理多个系统使用的数据库对象的分支？
   • 艰难的一个:尽量避免不惜一切代价.
5. 如果有的话,可以合理地对这个过程做出哪些例外？
   • 安全问题？
   • 不存储test/prod的密码.你可以允许它开发,特别是如果你有自动每日/每晚数据库重建
   • 具有去识别问题的数据？
   • 脚本无法完全自动化？
   • 使用发布信息/ ALTER脚本记录和存储
6. 如何使流程具有弹性和可执行性？
   • 开发者错误？
   • 从头开始测试每日构建,并将结果与​​增量升级进行比较(使用ALTER从版本A到B).比较结果模式和静态数据
   • 出乎意料的环境问题？
   • 使用版本控制和备份
   • 比较PROD数据库模式与您的想法,尤其是在部署之前.SuperDuperCool DBA可能修复了票证系统中从未出现的错误:)
   • 用于灾难恢复？
7. 您如何让决策者相信DB-SCM的好处真正证明了成本的合理性？
   • 传闻？
   • 行业研究？
   • 行业最佳实践建议？
   • 向公认的当局上诉？
   • 成本效益分析？
   • 如果开发人员和DBA同意,你不需要说服任何人,我想(除非你需要钱购买像dbSQL的MSGhost这样的软件)
8. 谁应该在这个模型中"拥有"数据库对象？
   • 开发商？
   • 数据库管理员？
   • 数据分析师？
   • 超过一个？
   • 通常,DBA会批准该模型(在签入之前或作为代码审查的一部分之后).他们肯定拥有与性能相关的对象 但总的来说,团队拥有它[和雇主,当然:)]

Answer 2

我尽可能将SQL视为源代码

如果我可以在标准的兼容SQL中编写它,那么它通常会在我的源代码控制中的文件中.该文件将尽可能多地定义,例如SP,表CREATE语句.

我还包括用于源代码控制测试的虚拟数据:

1. 凸出/ SQL/setup_db.sql
2. 凸出/ SQL/dummy_data.sql
3. 凸出/ SQL/mssql_specific.sql
4. 凸出/ SQL/mysql_specific.sql

然后我抽象出所有的SQL查询,以便我可以为MySQL,Oracle,MSSQL或其他任何东西构建整个项目.

构建和测试自动化使用这些构建脚本,因为它们与应用程序源一样重要,并测试从完整性到触发器,过程和日志记录的所有内容.