0

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

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

尤其：

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

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

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

4

2 回答 2

6

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

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

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

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

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

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

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

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

于 2012-11-02T10:55:55.113 回答
1

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

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

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

    • 运行虚拟环境
    • 从 git/subversion 签出构建配置
    • 运行引导程序
    • 运行构建
于 2012-11-02T05:37:26.767 回答