Heroku 工程团队记录了他们利用 Heroku 运行时（Heroku Runtime）从手动部署到自动化持续部署的过程，Heroku运行时是他们的应用程序托管环境。他们使用 Heroku 原语和自定义部署工具实现了这一目标。

Heroku 运行时团队可以构建和运维单一（私有空间，Private Space/PS）及多租户（公共运行时，Common Runtime/CR）环境。这包括容器编排、路由和日志记录。在此之前，该团队需要遵循的部署流程是由多个手动步骤组成的，包括主要值班工程师的签字、预留足够的缓冲区以监控部署后的情况以及对多个仪表板的监控。如果还需要部署其他区域和服务，则必须等到该次部署全部稳定之后，这也会带来相应的开销。由于当时团队规模较小，并且服务和区域仅限于美国和欧盟 2 种生产环境，所以这种方法是可行的。随着团队成员数量的增加以及将 CR 重新构建成一个面向多服务的长期项目，团队必须进行自动化实践并构建一个可以自动化部署工具。

InfoQ 联系了 Heroku 的主要技术人员 Bernerd Schaefer，以进一步了解他们所面临的挑战以及相应解决方案的细节。

之前的流程依赖于团队的规模和对预期效果的详细手动计划。Direwolf 是一个测试平台，它可以上报跨区域的状态。当团队成员增加到 30 多人时，这个过程会变得很繁琐。再加上 CR管理架构改造（将 CR 的单体 Ruby 应用程序分割成多服务）的挑战。团队决定推行完全自动化。该应用程序在两个生产环境中运行，手动步骤会导致更高的协调成本。

团队的解决方案是使用现有的 Heroku 原语和一个名为 cedar-service-deployer 的自定义工具。每个服务都会成为管道（Pipeline）的一部分，并且共享服务作为长期项目的一部分部署在跨多个预生产（staging）和生产（prod）环境中。cedar-service-deployer tools 工具是使用 Go 编写的，它可以扫描管道以发现不同阶段之间的差异。如果扫描到任何差异，它将运行检查程序以查看是否可以将代码提交到下一个阶段。这些检查包括发布时间、足够的集成测试时间、正在运行的事件（incident）、正在触发的告警、只能从主干分支进行升级等。Schaefer 说到，添加新检查需要变更代码，因为该列表是固定的。同时，他还解释到，团队可以配置自己的告警：

团队可以配置单个服务所需要检查的服务项，特别是要监控哪些告警以确定服务的健康状况。例如，某个服务可能有一个告警是用来检查服务是否启动的，一个是用来检查其 HTTP 成功率是否超过99%，向部署程序中添加这些服务的团队可以在 JSON 文件中配置告警，以便对部署程序服务在发布期间进行监控。

监控和告警是部署的重要组成部分，因为它们可以指出可能存在的问题。Heroku 使用 Librato 收集度量指标和告警。Schaefer 说，还有一些其他的系统也可以进行监控，但是到目前为止，部署程序所控制的所有服务都是使用的 Librato。

Schaefer 进一步阐述了他们的监控理念：

我们一直在推动的一件事情是将监控引入到我们的标准服务工具包中，以便每个服务在默认情况下都具有有用的工具。当然，随着服务投入生产并进入成熟阶段，它们可能需要一些定制的工具。但是我们的目标是，服务开发人员可以专注于他们服务所提供的功能，并成为对应功能的专家，而无需成为度量指标收集、跟踪或其他我们想知道的系统运行情况的专家。

尽管在大多数情况下，部署程序可以自动决定是否推送，但是我们仍提供了手动覆盖的规则。Schaefer 解释道：

系统总是允许运维人员使用现有的手动工具来进行发布。我们可能会在事件期间执行此操作，以便将关键的热修复程序补丁发布到受影响的环境中。在一个事件中，很少还会推送其他的变更，因为如果有某项事件正在进行中的话，我们会尽力减少其他对生产环境的变更，而且人们很少会急于将产品发布上去，但是如果需要的话，这种能力也是存在的。

部署程序的无状态特性意味着它的工作方式可以尝试在管道中任意两个阶段之间进行升级，而不是绑定到单个“发布”版本上。这使得多个提交点可以同时出现在部署管道的不同阶段。

原文链接：

Heroku’s Journey to Automated Continuous Deployment

创作场景

Heroku 的自动化持续部署之旅