我应该如何设置从开发到生产 Plone 的工作流程？

Question

几年前我曾使用 Plone 2，但它的工作流程和安全系统（更不用说新的主题引擎）似乎最适合当前项目。从可用性的角度来看，Plone 4 看起来要好得多，但是在它不强制用户进行特定设置的驱动下，如何最好地将它托管在我们面向公众的 Ubuntu 服务器上已经变成了一个迷宫。我已经使用统一安装程序（/home/plone/Plone/zinstance）安装了 Plone，并一直在前台运行它以进行开发，但我现在需要进行设置以使该网站上线。

我想在项目服务器上实现一个开发实例，我们可以将其用于我们自己的定制（在我们的桌面上添加其他本地实例以在签入开发实例之前进行测试），然后是一个我们的客户可以在其上进行测试的站点在它们上线之前，最后是上线网站。

特别是：

1. 我假设实时站点将基于 ZEO，而测试和开发将是独立的；这有意义吗？

2. 目前，所有内容都位于/home/plone/Plone，而我们所有其他（通常是PHP CMS）网站都托管在/srv/<domain>/www；然后一次性备份域的所有内容。布局不同的 Plone 实例以适应这种情况的最佳方式是什么？

3. 在从开发到测试再到实际站点的整个周期中，将我们的更改转移到构建和产品的最佳方式是什么？我们目前有一个将 Mercurial 用于其他系统的基本部署流程。

Answer 1

当前的最佳实践是使用buildout 来定义完全可重现的部署。

通常，您使用production.cfg 和development.cfg 配置通过包含共享配置，以根据任一环境的特定需求调整部署；您可以根据需要扩展此模型。例如，一个大项目可能有一个 staging.cfg 来首先将新功能部署到测试环境。

您是否在开发中使用 ZEO 完全取决于您的用例。大多数开发设置当然不需要它，但是在包含异步工作器的大型部署中，您可能会发现无论如何在开发时都需要 ZEO 服务器。同样，buildout 将使您更轻松地切换开发环境以满足不断变化的需求，尤其是与 supervisord 结合使用来管理设置中使用的各种守护程序时。

对于我管理的最大部署，我们使用 subversion 和 git 的组合，但仅出于历史原因。这一切都被转移到一个 git 存储库中。最后，存储库将包含其各种配置、development.cfg、staging.cfg 和每个生产机器的配置文件（生产集群中的每个服务器一个）的完整构建。例如，对于 3 机 ZEO 设置，这将是一个 zeo.cfg 和 instances-1.cfg 和 instances-2.cfg。核心开发鸡蛋存储在src/ 的同一存储库中。

开发仅在每个功能和每个问题的分支中进行。完成后，将一个分支合并到暂存分支中，并更新并重新启动暂存服务器。一旦客户在每个合并的分支上签字，并计划推出，我们将批准的分支合并到主分支并标记发布。然后生产集群机器切换到该新标签并重新启动。

我们还使用Jenkins 进行持续集成测试； main 和 staging 分支每天至少进行一次测试，让我们及早发现问题。

所有的守护进程都由一个专门的 supervisord 管理，它是通过一个 crontab 条目 (@reboot) 启动的，而不是本机操作系统的 init.d 结构。这样我们就可以完全通过 buildout 来管理正在运行的守护进程。构建甚至生成 logrotate 配置和 munin 监控插件；根据需要将这些符号链接到操作系统位置。

因为构建是完全独立的，所以在机器上设置生产构建在哪里 并不重要。一定要选择一致的东西，记录下来并坚持下去。确保你有足够的磁盘空间来满足你的守护进程的需要，否则不要太担心。

Answer 2

1. ZEO 与否 - 用于生产或开发 - 取决于个人需求和偏好。许多开发人员使用 ZEO 进行生产和开发，但很多人没有。扩展需要 ZEO（多个应用服务器）

2. 没有人关心...将 Plone 安装在您想要或需要的地方...在移动安装后重新运行构建可修复重定位问题。这是您的系统，而不是我们的系统...您决定。

3. 通常构建配置存在于存储库中，并且可以从存储库中提取到生产服务器上......否则您需要自己复制相关的构建文件。典型的安装工作如下：

   • 运行 virtualenv
   • 从 git/subversion 检查构建配置
   • 运行引导程序
   • 运行构建