Heroku 部署

此页面记录了使用 dpl v1 进行部署，该版本目前是默认版本。下一个主要版本 dpl v2 将很快发布，我们建议您开始使用它。有关详细信息，请参阅我们的博客文章。您可以在此处找到 dpl v2 文档。

部署自定义应用程序名称
部署特定分支
运行命令
部署构建工件

Travis CI 可以在构建成功后自动部署您的 Heroku 应用程序。

要使用默认配置，请将您的加密 Heroku api 密钥添加到您的 .travis.yml 中

deploy:
  provider: heroku
  api_key:
    secure: "YOUR ENCRYPTED API KEY"

如果您同时安装了 Heroku 和 Travis CI 命令行客户端，则可以通过从项目目录运行以下命令来获取密钥、对其进行加密并将其添加到 .travis.yml 中

travis encrypt $(heroku auth:token) --add deploy.api_key

travis 命令默认为使用 travis-ci.org 作为 API 端点。如果您的构建在 travis-ci.com 上运行（即使您的存储库是公开的），请添加 --pro 标志来覆盖此设置

travis encrypt $(heroku auth:token) --add deploy.api_key --pro

您也可以使用 Travis CI 命令行设置工具 travis setup heroku。

部署自定义应用程序名称 #

默认情况下，我们将尝试部署到与存储库同名的应用程序。例如，如果您从 GitHub 存储库 travis-ci/travis-chat 部署应用程序，而没有显式指定应用程序的名称，Travis CI 将尝试部署到名为 travis-chat 的 Heroku 应用。

您可以通过 app 选项显式设置名称

deploy:
  provider: heroku
  api_key: ...
  app: my-app-123

还可以将不同的分支部署到不同的应用程序

deploy:
  provider: heroku
  api_key: ...
  app:
    master: my-app-staging
    production: my-app-production

如果这些应用属于不同的 Heroku 帐户，则需要对 API 密钥执行相同的操作

deploy:
  provider: heroku
  api_key:
    master: ...
    production: ...
  app:
    master: my-app-staging
    production: my-app-production

部署特定分支 #

如果您有特定于分支的选项，如上所示，Travis CI 将自动确定要从中部署的分支。否则，它只会从您的 master 分支部署。

您也可以使用 on 选项显式指定要从中部署的分支

deploy:
  provider: heroku
  api_key: ...
  on: production

或者，您也可以将其配置为从所有分支部署。

deploy:
  provider: heroku
  api_key: ...
  on:
    all_branches: true

从拉取请求触发的构建永远不会触发部署。

运行命令 #

在某些设置中，您可能希望在 Heroku 上成功部署后运行命令。您可以使用 run 选项执行此操作

deploy:
  provider: heroku
  api_key: ...
  run: "rake db:migrate"

它也接受命令列表

deploy:
  provider: heroku
  api_key: ...
  run:
    - "rake db:migrate"
    - "rake cleanup"

请注意，当我们运行您的命令时，Heroku 应用可能尚未完全部署并准备好提供请求。为了缓解这种情况，您可以在命令之前添加 sleep 语句以添加延迟。

自定义命令的错误日志 #

自定义 Heroku 命令不会影响 Travis CI 构建状态或触发 Travis CI 通知。

使用诸如 Papertrail 或 Logentries 之类的附加组件来获取 rake db:migrate 或其他命令的通知。

这些附加组件具有电子邮件通知系统，可以在 Heroku 日志中出现某些字符串匹配时触发。例如，如果日志包含“此迁移及所有后续迁移已取消”，则可以触发电子邮件通知。

重新启动应用程序 #

有时您希望在命令之间或之后重新启动 Heroku 应用程序。您可以通过添加“restart”命令轻松地做到这一点

deploy:
  provider: heroku
  api_key: ...
  run:
    - "rake db:migrate"
    - restart
    - "rake cleanup"

部署构建工件 #

在您的测试运行并在部署之前，Travis CI 将清理您所做的任何其他文件和更改。

这可能不是您想要的，因为您可能会生成一些也应该部署的工件（考虑资产编译）。现在有一个选项可以跳过清理

deploy:
  provider: heroku
  api_key: ...
  skip_cleanup: true

条件部署 #

可以使用 on 选项使部署成为条件。

deploy:
  provider: heroku
  api_key: ...
  on:
    branch: staging
    rvm: 2.0.0

上述配置将在 Ruby 2.0.0 上通过暂存分支时触发部署。

您还可以添加自定义条件

deploy:
  provider: heroku
  api_key: ...
  on:
    condition: "$CC = gcc"

可用条件为

all_branches - 当设置为 true 时，如果通过，则从任何分支触发部署。
branch - 要从中部署的分支或分支列表，如果通过，则默认为 master（如果未指定分支）。
tags - 当设置为 true 时，Travis CI 仅在标记的构建上部署。由于存在限制，此条件必须与设置为 true 的 `all_branches` 配合使用。否则，分支的默认条件将干扰标签条件。
condition - 自定义条件或自定义条件列表
jdk - 如果通过，则要从中部署的 JDK 版本。
node - 如果通过，则要从中部署的 NodeJS 版本。
perl - 如果通过，则要从中部署的 Perl 版本。
php - 如果通过，则要从中部署的 PHP 版本。
python - 如果通过，则要从中部署的 Python 版本。
ruby - 如果通过，则要从中部署的 Ruby 版本。
repo - 仅为给定存储库触发构建，以与 fork 良好配合。

部署策略 #

Travis CI 支持不同的机制来部署到 Heroku

api: 使用 Heroku 的构建 API。这是默认策略。
git: 通过 HTTPS 执行 git push。

它默认为 api，但您可以通过 strategy 选项更改它

deploy:
  provider: heroku
  api_key: ...
  strategy: git

在 `git` 策略上使用 `.gitignore` #

当您使用任何 git 策略时，请注意部署将遵循 .gitignore。

如果您的 .gitignore 文件匹配构建创建的内容，请使用 before_deploy 更改其内容。

在部署之前和之后运行命令 #

有时您希望在部署之前或之后运行命令。您可以为此使用 before_deploy 和 after_deploy 阶段。只有当 Travis CI 实际部署时，才会触发这些阶段。

before_deploy: "echo 'ready?'"
deploy:
  ..
after_deploy:
  - ./after_deploy_1.sh
  - ./after_deploy_2.sh