使用 capistrano 和 git 进行稳健的部署策略
为允许以下场景的 RoR 应用程序设置稳健的部署策略的最佳方法是什么？
- 新功能已提交
- 新功能已部署到暂存环境
- 紧急功能/修复已提交
- 紧急修复 已部署到暂存（不包括以前的功能）
- 已在暂存上测试的紧急修复
- 已部署到生产的紧急修复
- 原始新功能已部署回暂存
据我所知，我需要使用 git 分支或标记或两者兼而有之。是否有任何工具可以减少或自动化维护这些分支或标签的开销？
What is the best way to set up a robust deploy strategy for a RoR app that allows for the following scenario?
- new feature committed
- new feature deployed to staging environment
- emergency feature/fix committed
- emergency fix deployed to staging (and previous feature excluded)
- emergency fix tested on staging
- emergency fix deployed to production
- original new feature deployed back to staging
As far as I can tell, I will need to use either git branches or tagging or both. Are there any tools that can reduce or automate the overhead of maintaining these branches or tags?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定是否有。对我来说，这更多的是一个过程问题，而不是一个技术性的、如何做的问题。
标记和分支，以及使用主题（或功能）分支通常是正确的方法。我倾向于保留两个长期存在的分支，master 和 staging，并且我使用主题分支进行所有开发。长期存在的分支是唯一用于部署到各自环境的分支，紧急修复由git revert处理，然后是cap部署，然后是主题分支中的修复然后将其合并到发生紧急情况的任何长期存在的分支中。
希望这有帮助。
I'm not sure there is. This is more of a process question to me than a technical, how-to question.
Tagging and branching, with the usage of topic (or feature) branches is usually the way to go. I tend to keep two long-lived branches, master and staging, and I use topic branches for all of the development. The long-lived branches are the only ones used for deploying to their respective environments and emergency fixes are handled by git revert followed by cap deploy followed by the fix in a topic branch which is then merged into whatever long-lived branch the emergency happened on.
Hope this helps.