isotoma.plone.heroku 0.0.0

您将需要

• 已安装并运行本地的heroku工具

• 一个经过验证的heroku账户

• 愿意每月花费15美元以获得20GB的Postgres（Plone不适合5MB）。

开始一个项目

我们需要能够在虚拟环境中安装Plone，而不需要任何buildout的环境构建功能。除此之外，运行环境是临时的，因此我们无法在初始推送后手动构建它。

在您的requirements.txt中

isotoma.depends.zope2_13_8
isotoma.depends.plone4_1
isotoma.plone.heroku

前两个egg是虚拟包，会在您的虚拟环境中安装200多个包。这些是必需的，因为我们需要固定要使用的Plone版本。

第三个egg提供了bin/plone和bin/migrate。这些辅助工具将根据需要动态提供环境，并实例化站点/运行迁移。

我们将使用RelStorage来获取经济实惠的持久存储。我们必须使用1.4.2而不是1.5.x系列，以避免它引入的plpgsql要求。

在撰写本文时，似乎只有Django Python应用程序会自动获得数据库。您可以通过添加一个包含空settings.py的文件夹来获取一个。

django_bait/
    settings.py

您需要一个Procfile，以便Heroku知道如何运行zope实例

web: ./bin/plone -p $PORT

进行本地构建

构建您的虚拟环境

virtualenv .
./bin/pip install -r requirements.txt

您可以使用以下方式启动plone实例

./bin/plone

这将使您在8080端口上运行一个Plone实例。默认情况下，它不会使用任何数据存储。

添加您的产品

您可以使用ZopeSkel快速创建一个新的产品。

source bin/activate
mkdir src && cd src
pip install zopeskel
zopeskel plone my.app

然后按照提示操作。确保回答通用设置问题时选择“是”。

您可以将自己的自定义egg添加到requirements.txt中。

-e src/myapp.app

说明告诉您使用< span class="docutils literal">file:前缀。它们是假的。不要这样做。

您的ZCML应该由z3c.autoinclude找到。

然后您应该能够通过ZMI或使用下面描述的迁移脚本来安装您的产品。

部署到Heroku

确保将所有更改提交到您的Git存储库。然后

~/bin/heroku create --stack cedar
git push heroku master

等待。如果它不起作用，那可能是因为超时。部署200多个egg需要很长时间，Heroku可能认为您的部署出错并超时。

因此编辑您的需求

isotoma.depends.zope2_13_8
# isotoma.depends.plone4_1
isotoma.plone.heroku

提交并推送到Heroku。

这将构建不包含Plone的Zope，大约一半需要构建的egg。然后您可以取消注释Plone依赖项egg，再次推送以完成。

现在您应该有一个正常工作的Plone站点了！

重新根目录您的门户

默认情况下，您的实际站点不会在< span class="docutils literal">/，它会在< span class="docutils literal">/Plone。我们可以通过一些老式的Zope魔法来解决这个问题 - 注意，< span class="docutils literal">migrate命令可以自动为您设置。

• 在ZMI中，在< span class="docutils literal">/Plone创建一个SiteRoot对象。默认设置就很好。

• 在ZMI中，在< span class="docutils literal">/创建一个包含以下内容的DTMLMethod：

  <dtml-let stack="REQUEST['TraversalRequestNameStack']">
    <dtml-if "stack and stack[-1]=='zmi'">
      <dtml-call "stack.pop()">
      <dtml-call "REQUEST.setVirtualRoot('zmi')">
    <dtml-else>
      <dtml-call "stack.append('Plone')">
    </dtml-if>
  </dtml-let>

• 在ZMI中，在< span class="docutils literal">/创建一个指向我们刚刚创建的DTMLMethod的AccessRule。

现在任何对< span class="docutils literal">/foo的请求将由< span class="docutils literal">/Plone/foo处理，任何对< span class="docutils literal">/zmi/manage的请求将由< span class="docutils literal">/manage处理。成功。

迁移工具

迁移脚本使用< span class="docutils literal">isotoma.recipe.plonetools的Plone设置功能来自动化您站点的设置。它可以应用配置文件、安装产品、设置属性甚至调用随机突变。

在项目根目录中添加一个migrate.cfg

[main]
# The id of the Plone Site that is created. Default is Plone.
site-id = Plone

# The admin user that was created by mkzopeinstance - for us it will almost
# certainly be admin. Default is admin.
admin-user = admin

# Whether or not to apply the SiteRoot/AccessRule policy described in the previous
# section. Default is False.
rootify = True

# List of products to install on the initial migrate (when ``/Plone`` is created)
products-initial =
    Products.foo

# List of products to install (or reinstall) every time migrate is run
products =
    Products.LinguagePlone

# List of GenericSetup profiles to apply the first time migrate is run (when
# ``/Plone`` is created)
profiles-initial =
    myapp.policy:initial

# List of GenericSetup profiles to apply every time ``bin/migrate`` is run
profiles =
    myapp.policy:default

这个没有意义，但它显示了您能做什么。要本地运行

./bin/migrate -c migrate.cfg

要针对您的Heroku应用程序运行

~/bin/heroku run ./bin/migrate -c migrate.cfg

默认情况下，它会查找分支根目录中的migrate.cfg，您不需要告诉它 - 您可以直接< span class="docutils literal">./bin/migrate。

维护您的应用程序

您可以使用内置的Heroku日志工具查看您的日志。

./bin/heroku logs

您可以使用debug命令将解释器指向您的数据库。

./bin/heroku run ./bin/debug

您可以使用run命令在您的git存储库中运行脚本。

./bin/heroku run ./bin/run scripts/myscript.py