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

Question

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

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

我正在使用厨师的 deploy_revision资源，我很高兴它的工作原理。我渴望从“推”到“拉”。但除非我们的测试通过，否则我不想部署代码。我坚持在实现这种效果的替代方法之间进行选择:

将 Chef 指向一个标签(例如 2.0 )并在我们的部署配方中定期更新该标签。 (我不喜欢这样，因为它不是真正的持续部署。我们现在每次想要发布代码时都回到手上。)

在一个分支点厨师，让 Jenkins 合并 master -> release测试套件通过后。 (我不喜欢这样，因为现在我的 Jenkins 服务器可以读/写我的存储库。)

不要将 Chef 配置为定期运行，而是让 Jenkins 运行 chef-client通过 SSH。 (我不喜欢这样，因为我期待有一天我们的 Jenkins 机器不再可以通过 SSH 访问我们的服务器。)

部署代码，但如果之后测试失败，则恢复提交。 (在我看来，太容易出错了。)

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

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

Answer 1

您可以设置一个小脚本来监听来自 Jenkins 的 prod 并为您运行厨师 - 换句话说，为 Jenkins 制作一种不需要完全 SSH 访问的有限形式的触发访问。

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