过去一周,我一直在忙着做厨师,并准备(情绪和操作上)停止使用Capistrano. (我们正在托管一个Rails应用程序.)

我们遵循GitHub流程,这意味着我们只有主人和一大堆功能分支.现在我们使用Jenkins进行持续集成和持续部署,我们使用Capistrano将master部署到我们的服务器 – 但只有在我们的单元,集成和验收测试通过后才能使用.

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

> Point Chef标记(例如2.0)并在我们的部署配方中定期更新该标记. (我不喜欢这个,因为它不是真正的持续部署.每次我们想要发布它时,我们现在回到手持我们的代码.)
>点厨师在分公司,让Jenkins合并主人 – >测试套件通过后发布. (我不喜欢这个,因为现在我的Jenkins服务器对我的存储库具有读/写访问权限.)
>不要将Chef配置为定期运行,而是让Jenkins通过SSH运行chef-client. (我不喜欢这个,因为我期待有一天我们的Jenkins机器不再具有SSH访问我们的服务器.)
>部署代码,但如果之后测试失败,则还原提交. (在我看来,太容易出错了.)

我觉得我已经完成了足够多的功课.我一直关注Steve Jang’s thorough write-up,并在Chef docs上花了几个小时的时间.但是在与Chef持续部署的所有优秀的社区教程中,我没有看到任何提及这个特定的用例.

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

最佳答案 您可以设置一个小脚本来监听Jenkins的prod并为您运行chef – 换句话说,为Jenkins创建一个有限形式的触发访问,不需要完全SSH访问.

另一种选择是使用Jenkins合并master的存储库的单独克隆 – >发布到,这不是您的开发存储库.然后让Chef从那里拉出来(或者让Chef在那里查找修订版本,并从原始存储库中提取该修订版本,这会让您更有信心,没有人人为地搞砸了它们之间的提交).