情景：
持续集成 + 部署节点网络应用在每次提交时都要掌握，例如通过Travis到Heroku。
（两个选项：Travis's deploy hook或Heroku's GitHub Sync。重要的是，如果CI成功/测试通过，两种方式都只会部署。）
我想要将这个应用程序的一些部分维护为单独的，可重复使用的模块，例如在他们自己的git回购中。
为简单起见，我们假设一切都公开。
-
我想同样不断地整合+＆＃34;部署＆＃34; （即，提供给应用程序）这些模块，每次提交他们的主人（或w / e分支）：
每次更新我的网络应用时，我都想使用这些模块的最新稳定（即测试）版本。
重要的是，如果我不小心将错误提交给某个模块，并且 CI失败，则对该网络应用的更新不会选择此更改。< / p>
我不想在每次提交时手动碰撞版本，或发布标签等。
-
我已经调查了很多选项，但无法找到实现所有这三个目标的简单方法！
npm git dependency ：我可以直接在每个模块的GitHub回购中指出我的网络应用package.json（例如{{1} }）获得连续的部署＆＃34; （可用性）该模块的回购。但是，如果我不小心提交了一个错误，即使模块的CI失败，应用程序也会在下一次部署时被破坏。
Travis npm publish ：Travis可以在成功的CI后自动将模块发布到npm，但是npm注册表每次都需要一个唯一的版本，并且没有自动碰撞版本AFAICT的方法。
Travis GitHub release：我希望Travis可以自动更新代码，但它只能在标签上执行（它是标签对于发布构建资产意味着更多，所以仍然是手动的。
-
有什么办法吗？谢谢！
答案 0 :(得分：1)
想到的一个选项，虽然需要手动实现，但可以更新Travis {{1}上的分支（例如stable或tested或w / e） （有点像手动部署挂钩）。
然后，您可以自由地提交master，但是这个其他分支只包含通过CI的提交。这允许你在这个分支点指向npm，例如after_success。如果您通过非强制foo.git#stable更新，则可以保证此分支仅包含ffwd提交。
您需要为脚本提供GitHub用户信誉，例如通过安全env vars，但它们可以与Travis本身使用的相同。我不确定是否会有任何其他问题。例如。我假设git可用于Travis脚本。