人们如何处理内容管理系统的生产阶段？

Question

为了好玩，我一直在尝试web开发技术(ya，我应该更多地出去)，对于缺乏对生产阶段(即开发、测试、性能和生产环境)的明确支持，我感到有点震惊。实际上，支持并不是一个词；内容管理系统()似乎在积极地反对允许清洁分期的努力。

目前我正在使用Drupal。我很难找到社区如何解决这个问题。我看到的大多数帖子都推荐复制在生产系统上开发的步骤(阅读这篇文章实际上缩短了我的寿命)。我还听说过将生产数据推回给开发人员，这样他们就可以添加增量特性。如果客户端不希望您将他们的数据撤回到您的开发环境中，这是不可能的。

所以最后我的问题是：

如何管理CMS的实际生产阶段问题？

我来自一个背景，推动生产感觉就像把人送上月球，所以我可能需要放松一点。但是，我仍然感兴趣的答案涉及源代码管理、允许生产回滚和测试。

Answer 1

我已经回答了关于DB部署策略的问题。

还有一个关于代码部署的问题。

在我工作的地方，我们正在进行相当大的Drupal部署。我们大致有以下设置。

所有开发人员都有一个本地沙箱(Drupal + DB)。提交到一个分支的代码在所有其他开发人员之间共享(我们大约有15个开发人员)。这包括由update函数执行的配置更改。

当开发人员启动svn时，他们还运行update.php在本地执行任何配置更改。

我们有一个短跑测试系统，运行最简单，可以用于用户测试。

在sprint的末尾(我们使用scrum)，我们将分支合并到主干中，并对此运行测试。

然后，我们将其标记为发行版，并将其部署到live (使用Capistrano)，最后在live上运行update.php以将配置更改应用于活动。

任何紧急修复都会从中继线部署到一个点版本7.1等。

如果你想要更多的细节，请留下评论。

Answer 2

在花了几周时间超越Drupal学习曲线之后，如果您正在构建一个具有任何复杂性的站点，“过多的配置存储在DB中”的问题非常令人不安。

看看发育种子为解决这个问题所做的工作。他们领导着上下文、特性和空间模块的开发，这些模块共同工作，将配置数据存储在模块中(DB之外)，以便可以用代码对其进行版本化。

Answer 3

目前我正在使用Drupal。我很难找到社区如何解决这个问题。

这是Drupal的弱点之一；它确实没有正确地处理这个问题。由于Drupal的很大一部分配置位于数据库中，所以很难进行排序。