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