几年前我和Plone 2合作过，但它的工作流程和安全系统（更不用说新主题引擎）似乎最适合当前的项目。从可用性的角度来看，Plone 4看起来要好得多，但是在不强迫用户特定设置的驱动下，如何最好地将它托管在面向公众的Ubuntu服务器上已经变得有点迷宫了。我已经使用统一安装程序（在/home/plone/Plone/zinstance中）安装了Plone，并且已经在前台运行它以进行开发，但我现在需要设置一些东西来移动这个网站
我想在项目服务器上实现一个开发实例，我们可以将它用于我们自己的自定义（在我们的桌面上有额外的本地实例，以便在检查开发实例之前进行测试），然后我们的客户端可以在在他们上线之前，最后是现场网站。
特别是：
我假设现场网站将基于ZEO，而测试和开发将是独立的;这有意义吗？
目前，所有内容都在/home/plone/Plone，而我们所有其他（通常是PHP CMS）网站都来自/srv/<domain>/www;然后，一次性备份域的所有内容。布置不同Plone实例以适应这种情况的最佳方法是什么？
通过从开发到测试再到实时网站的循环，将更改转移到构建和产品的最佳方法是什么？我们目前使用Mercurial进行其他系统的基本部署过程。
答案 0 :(得分：6)
目前的最佳做法是使用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进行持续集成测试;主要和分期分支每天至少进行一次测试，让我们尽早发现问题。
所有守护进程都由专用的supervisord管理，该监督通过crontab条目（@reboot）启动，而不是本机OS init.d结构。这样我们就可以完全使用buildout来管理正在运行的守护进程。扩建甚至生成logrotate配置和munin监控插件;根据需要将它们符号链接到OS位置。
因为buildout完全是自包含的，所以在哪里在机器上设置生产构建并不重要。选择一致的东西，记录并坚持下去。确保您有足够的磁盘空间来满足您的守护程序需求，否则不必过于担心它。
答案 1 :(得分：1)
ZEO与否 - 用于生产或开发 - 取决于个人需求和偏好。许多开发人员使用ZEO进行生产和开发，而许多开发人员则没有。扩展需要ZEO（多个应用服务器）
没有人在意......安装Plone你想要它或者需要它...在移动安装后重新运行buildout修复了重定位问题。这是你的系统，而不是我们的...... 你决定。
通常，buildout配置存在于存储库中，可以从存储库中提取到生产服务器上....否则，您需要自己复制相关的buildout文件。典型安装的工作方式如下：