如何在集成分支并不总是准备好上线的环境中处理使用 Git 的部署
所以我意识到这个标题很奇怪，所以让我澄清一下。我的环境有 15 名开发人员，在任何给定点，我们中最多 5 人可能正在处理同一组代码。这是一个 PHP Web 应用程序，有很多遗留/程序代码，因此我们经常编辑相同的文件，并且我们的一些更改可能影响深远。
因此，集成有些棘手，但更重要的是，有时会开发出经过多轮 QA 和测试的功能。市场部门进行审查，同时需要部署其他较小的功能。
目前，为了避免在 QA/集成中陷入困境，integration 分支是一种死胡同分支，当某些东西真正准备好时，它会直接从其功能分支合并到 master，并且 master 被推送部署到实时站点。
我正在尝试创建一个更流畅的工作流程，其中功能合并到 QA 中，然后 QA 合并到 master 作为部署，但我需要解决尚未准备好上线的功能问题与集成上的较小功能混合在一起。我愿意探索一些替代方法来处理运行时间较长的功能，而不是将它们合并到集成分支中，但我自己也遇到了困难。
So I realize that's a doozy of a title, so let me be clarify. I have an environment with 15 developers, and at any given point, up to 5 of us might be working on the same set of code. This is a PHP web app that's got a lot of legacy/procedural code, so we're often editing the same files, and some of our changes can be quite far-reaching.
As a result, integration is somewhat tricky, but even more to the point, sometimes a feature will be developed that goes through multiple rounds of QA & review by marketing, all while other, smaller features need to be deployed.
Currently, to avoid things getting stuck at QA/integration, the integration branch is a sort-of dead-end branch, and when something is truly ready, it's merged directly from its feature branch into master, and master is pushed to deploy to the live site.
I'm trying to create a smoother workflow, where features merge into QA, and then QA merges into master as a deployment, but I need to address the issue of features that aren't ready to go live being intermingled with smaller features on integration. I'm willing to explore some alternate way(s) to handle the longer-running features, rather than them merging into the integration branch, but I've hit the wall myself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要采用“发布候选者”的想法。
我在这里解释了这样做的过程： http://dymitruk .com/blog/2012/02/05/branch-per-feature/
如果您对此工作流程有任何疑问，请告诉我。
You need to adopt the idea of a "Release Candidate".
I've explained the process for doing so here: http://dymitruk.com/blog/2012/02/05/branch-per-feature/
Let me know if you have any questions about this work-flow.
事实是，有了 N 个特征，就有 N+(N 选择 2)+(N 选择 3)+(N 选择 4)+...+1 种不同的组合。
用英语来说，这就是“天哪，有很多组合”。
因此，您不必为每个可能的功能子集创建集成分支：您只需测试您关心的组合。如果某项功能本身还没有准备好迎接黄金时段，那么它就不可能与其他功能一起准备好迎接黄金时段。一旦进入特定版本的所有功能都成熟了，您就可以创建一个将所有这些功能放在一起的集成分支，对其进行质量检查，然后发布它。
您可以进行“高级集成”测试，只是为了看看 2、3、4 个左右的功能彼此配合得如何，但这些分支对于 QA 而言并不是“权威”：因为您没有最终的一组功能所有要运送到那里的东西，你不能将你所做的任何事情称为真正的质量保证。
因此，您没有一个“集成”分支 - 每个集成分支都用于一批完整准备进行质量检查的事物。如果有任何不好的东西进入那里，整个分支将无法通过质量检查，因此没有任何东西会从坏分支进入已部署状态 - 这意味着你永远不必说“这个有点好，那个有点”不好，拉那个，把这个留在质量保证过程之后：这将创建一个本质上未经测试的功能组合。
The fact of the matter is that, with N features, you have N+(N choose 2)+(N choose 3)+(N choose 4)+...+1 different combinations.
In English, that's "oh God there are a lot of combinations".
So, you don't create integration branches for every possible subset of your features: you only test the combinations that you care about. If something isn't ready for prime time by itself, there's no way it's ready for prime time in tandem with other features. Once all the features going into a particular release are mature, you create an integration branch with all of them together, QA that, and then ship it.
You may do "advance integration" testing just to see how well 2, 3, 4 or so features play with each other, but those branches aren't "authoritative" with respect to QA: because you don't have the final set of everything that's going to be shipped in there, you can't call anything you do true QA.
So you don't have an "integration" branch - each integration branch is for one complete batch of things which are ready for QA. If anything makes its way in there that's not good, the whole branch is going to fail QA, so nothing will creep its way from the bad branch into the deployed state - that means you never have to say "this bit is good, that bit is bad, pull that, leave this" after the QA process: that would be creating an essentially untested combination of features.