在SO社区wiki上有一些关于数据库对象是否应该进行版本控制的讨论.但是，I haven't seen much discussion about the best-practices for creating a build-automation process for database objects.
对于我的团队来说，这一直是一个有争议的讨论点-特别是在判断数据库部署自动化方法的好处和风险时，开发人员和DBA通常有不同的目标、方法和顾虑.
I would like to hear some ideas from the SO community about what practices have been effective in the real world.个
我知道哪种做法是最好的，这有点主观，但我认为一个很好的对话，关于哪些工作可以对很多人有帮助.
Here are some of my teaser questions about areas of concern in this topic. These are not meant to be a definitive list - rather a starting point for people to help understand what I'm looking for.个
- Should both test and production environments be built from source control?
- 两者都应该使用自动化构建-还是应该通过从稳定的、已完成的测试环境复制对象来构建生产？
- 如何在部署脚本中处理测试环境和生产环境之间的潜在差异？
- 如何测试部署脚本在生产环境中的工作效率，以及它们在测试中的工作效率？
- 什么类型的对象应该进行版本控制？
- 哪些类型的对象不应进行版本控制？
- 在SCM存储库中应该如何组织数据库对象？
- 如何处理转换脚本或更改脚本等一次性内容？
- 如何处理数据库中注销的对象？
- 从开发到测试级的promoting个对象应该由谁负责？
- 如何协调来自多个开发人员的更改？
- 如何处理多个系统使用的数据库对象的分支？
- 这个过程有哪些例外(如果有的话)是合理的？
- 安全问题？
- 具有取消标识问题的数据？
- 无法完全自动化的脚本？
- 您如何才能使流程具有弹性和可执行性？
- 到开发人员错误？
- 应对意外的环境问题？
- 用于灾难恢复？
- 您如何让决策者相信DB-SCM的好处确实证明了成本是合理的？
- 轶事证据？
- 行业研究？
- 行业最佳实践建议？
- 向公认当局提出上诉？
- 成本/效益分析？
- 在此模型中，谁应该"拥有"数据库对象？
- 开发人员？
- DBA？
- 数据分析师？
- 多个？