4

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

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

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

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

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

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

4

2 回答 2

2

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

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

于 2012-12-30T18:17:04.700 回答
0

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

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

ssh deploy_system deploy_build=true chef-client

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

于 2012-12-31T22:59:31.860 回答