关于数据库对象是否应该受版本控制的SO社区wiki已经有一些讨论.但是,我没有看到很多关于为数据库对象创建构建自动化过程的最佳实践的讨论.
这对我的团队来说是一个有争议的讨论点 - 特别是在评估数据库部署自动化方法的优势和风险时,开发人员和DBA通常有不同的目标,方法和关注点.
我想听听SO社区关于哪些实践在现实世界中有效的一些想法.
我意识到这有点主观,哪些实践真的是最好的,但我认为一个关于哪些工作可能对许多人有帮助的良好对话.
以下是我在此主题中关注领域的一些预告片问题.这些并不是一个明确的清单 - 而是人们帮助理解我正在寻找的东西的起点.
- 测试和生产环境都应该从源代码控制构建吗？
- 是应该使用自动化构建 - 还是应该通过从稳定的,最终的测试环境中复制对象来构建生产？
- 您如何处理部署脚本中测试和生产环境之间的潜在差异？
- 您如何测试部署脚本是否可以像测试一样有效地对抗生产？
- 哪些类型的对象应该受版本控制？
- 只是代码(程序,包,触发器,java等)？
- 指标？
- 约束？
- 表定义？
- 表更改脚本？(例如,ALTER脚本)
- 一切？
- 哪些类型的对象不应该受版本控制？
- 如何在SCM存储库中组织数据库对象？
- 你如何处理转换脚本或ALTER脚本之类的一次性事务？
- 你如何处理退出数据库中的对象？
- 谁应该负责将对象从开发推广到测试级别？
- 如何协调来自多个开发人员的更改？
- 您如何处理多个系统使用的数据库对象的分支？
- 如果有的话,可以合理地对这个过程做出哪些例外？
- 安全问题？
- 具有去识别问题的数据？
- 脚本无法完全自动化？
- 如何使流程具有弹性和可执行性？
- 开发者错误？
- 出乎意料的环境问题？
- 用于灾难恢复？
- 您如何让决策者相信DB-SCM的好处真正证明了成本的合理性？
- 传闻？
- 行业研究？
- 行业最佳实践建议？
- 向公认的当局上诉？
- 成本效益分析？
- 谁应该在这个模型中"拥有"数据库对象？
- 开发商？
- 数据库管理员？
- 数据分析师？
- 超过一个？