我一直在涉足网络开发技术是为了好玩（是的，我应该多出去走走），并且对缺乏对生产阶段（即开发、测试、性能和生产环境）的明确支持感到有点震惊。实际上，支持不是这个词。内容管理系统似乎在积极反对允许干净登台的努力。
目前我正在使用 Drupal。我很难找到社区如何解决这个问题。我看到的大多数帖子都建议在生产系统上重现开发中完成的步骤（阅读这篇文章实际上缩短了我的生命）。我还听说将生产数据推回给开发人员，以便他们添加增量功能。这不可能，如果客户不希望您将他们的数据拉回您的开发环境怎么办？
所以最后我的问题：
您如何管理 CMS 的实际生产暂存问题？
我的背景是推动生产就像把人送上月球一样，所以我可能需要放松一下。但是，我仍然对涉及源代码控制、允许生产回滚和测试的答案感兴趣。
我已经回答了一个关于数据库部署策略的问题。
还有一个关于代码部署的问题。
在我工作的地方，我们正在开展相当大的 Drupal 部署。我们大致有以下设置。
所有开发人员都有一个本地沙箱（Drupal + DB）。向所有其他开发人员（我们大约 15 人）共享的分支的提交代码。这包括由更新功能执行的配置更改。
当开发人员执行 svn up 时，他们还运行 update.php 以在本地执行任何配置更改。
我们有一个运行 simpletest 的冲刺测试系统，可用于用户测试。
在 sprint 结束时（我们使用 scrum），我们将分支合并到主干中，并在其上运行测试。
然后我们将其标记为发布并将其部署到 live（使用 Capistrano），最后在 live 上运行 update.php 以将配置更改应用到 live。
任何紧急修复都会从主干部署到 dot 版本 7.1 等。
如果您想了解更多详细信息，请发表评论。
在花费数周时间克服 Drupal 学习曲线后，如果您正在构建任何复杂的站点，“数据库中存储了太多配置”的问题会非常令人不安。
看看Development Seed为解决这个问题所做的工作。他们正在领导开发Context、Features和Spaces模块，这些模块协同工作以将配置数据存储在模块中（在数据库之外），以便可以使用代码对其进行版本控制。
目前我正在使用 Drupal。我很难找到社区如何解决这个问题。
这是 Drupal 的弱点之一；这件事真的处理不好。由于 Drupal 的很大一部分配置驻留在数据库中，因此特别难以理清。