如何阻止 Chef 部署测试失败的代码？

Question

上周我一直在加强 Chef，并准备（在情感上和操作上）停止使用 Capistrano。 （我们正在托管一个 Rails 应用程序。）

我们遵循 GitHub 流程，这意味着我们只有 master 和一系列功能分支。现在我们使用 Jenkins 进行持续集成和持续部署，并且我们使用 Capistrano 将master 部署到我们的服务器 - 但只有在我们的单元、集成和验收测试通过之后。

我正在使用 Chef 的 deploy_revision 资源，我对它的运行效果感到非常兴奋。我渴望从“推”到“拉”。但除非我们的测试通过，否则我不想部署代码。我被困在实现这种效果的替代方法之间的选择：

1. 将 Chef 指向一个标签（例如 2.0），并在我们的部署配方中定期更新该标签。 （我不喜欢这样，因为它不是真正的持续部署。我们现在又回到了每次想要发布代码时都手持代码的方式。）
2. Point Chef 在一个分支，在测试套件通过后让 Jenkins 合并 master -> release。 （我不喜欢这样，因为现在我的 Jenkins 服务器对我的存储库具有读/写访问权限。）
3. 不要将 Chef 配置为定期运行，而是让 Jenkins 通过 SSH 运行 chef-client。 （我不喜欢这样，因为我期待有一天我们的 Jenkins 机器不再拥有对我们服务器的 SSH 访问权限。）
4. 部署代码，但如果之后测试失败，则恢复提交。 （在我看来太容易出错了。）

我确实认为我已经完成了足够多的功课。我一直在关注Steve Jang's thorough write-up 等，并在Chef docs 上花费了数小时的时间。但是在所有关于使用 Chef 进行持续部署的优秀社区教程中，我没有看到任何提及这个特定用例的内容。

我可以接受上述大多数选项，但如果我知道这是一种行之有效的方法，我会感觉更好。我相信其他组织已经解决了这个问题。你是怎么做到的？

Answer 1

我使用的一个解决方案是保护环境变量（特别是ENV['deploy_build']）后面的厨师食谱中的实际代码部署。与实际部署代码无关的所有内容都留在了配方中的这些守卫之外，并且厨师客户端每半小时愉快地运行一次，以确保基本系统已准备就绪。

当构建和测试运行成功时，构建系统会触发以下形式的 ssh：

ssh deploy_system deploy_build=true chef-client

这允许配方部署最新的构建。这特别有帮助，因为我们的构建系统需要以特定顺序将更新部署到服务器，因此可以从构建系统 (jenkins) 进行编排

Answer 2

您可以设置一个小脚本来侦听来自 Jenkins 的 prod 并为您运行 chef - 换句话说，为 Jenkins 创建一个不需要完全 SSH 访问权限的有限形式的触发访问。

另一种选择是拥有 Jenkins 合并 master -> release 的存储库的单独克隆，这不是您的开发存储库。然后让 Chef 从那里拉取（或者让 Chef 在那里查找修订版，并从原始存储库中提取该修订版，这会让您更加确信没有人在两者之间人为地搞乱提交）。