版本、功能、子功能和环境的分支
在发布此内容之前，我已经浏览了 TFS 护林员指南。
我在我们的项目中有以下要求：
- 发布版本 1 的开发发生
- 它部署在开发环境上进行集成和健全性测试
- 如果可以，则将代码部署在 QA 环境上
- 如果可以，则 QA 发布的代码将部署在生产中。
目前，我们在 TFS 的 CODE 下有一个代码库，开发人员可以在其中进行编码。 上面分支到DEV来镜像dev环境代码 DEV分支分支到QA分支
如果需要热修复，则直接修复到QA分支，然后反向合并到下面的分支。
在第一次开发之前这一切都很好，但我觉得这需要重新构建，以便更好地扩展以适应未来的版本开发。
当前问题：
- 需要计划支持未来版本 1.5 的开发
- 目前有一些功能/修复可能会/可能不会加入 当前版本。开发人员暂时将其搁置，以便他们 将来可以被搁置。问题是随着时间的推移，货架变得 合并会带来巨大的痛苦，因为它们没有历史。
- 有时，人们会在货架上的大型功能上工作长达一周的时间。 合并成为一个巨大的油漆，因为到目前为止，这几十个文件已经 也被很多人做过。
牢记以上所有内容，我正在考虑重新设计我们的 TS 分支策略，如下所示：
按照这种方法：
开发将在开发分支（例如 DevRel1 分支）上进行
如果开发人员需要在大功能，他会致力于 分支例如Feature 1分支，从Dev分支分支出来。上
完成后他会合并回 dev 分支。- 对于可能包含或不包含在此版本中的功能， 开发可能需要处理从主分支分支出来的功能。 根据最终决定，它将更少地合并到适当的 开发分支。
- 代码将从 Dev 分支部署到 Dev 环境中
- 代码将从 Main 部署到 QA 分支
- 对于发布，main 将分支到新的发布分支
- QA 的热修复发生在 Main 分支上，发布时发生在 发布分支。发布中的 RI 发生在 main 上，FI 发生在 dev 上 在这种情况下会发生分支，
这是否变得太复杂了？是否可以简化，这看起来流程是否良好，或者是否需要修正？
我们目前使用的是 TFS 2008。
I have gone through the TFS rangers guides before posting this.
I have the below requirement in our project:
- Development of release 1 happens
- It is deployed on Dev environment for integration and sanity test
- If ok, then the code is deployed on QA environment
- If ok, QA released code gets deployed on production.
Currently we have a code base in TFS under CODE, where developers code.
The above is branched to DEV to mirror dev environment code
DEV branch is branched to QA branch
In case a hot fix is required, then it is fixed directly on QA branch, and then later reverse merged to below branches.
This was fine till first time development, but I feel this needs to be re-structured to be better scalable for future release development.
Current issues:
- need to plan to support future release 1.5 development
- At the moment there are some features/fixes which may/may not go in
current release. Developers just shelf it at the moment so that they
can be unshelved in future. Issue is that with time, shelves become
huge pain to merge as they do not have history - Sometime people work on big features on shelves for upto a week.
Merging becomes a huge paint as till then those dozens of files have
also been worked by a lot of people.
Keeping all the above in mind, i am thinking of redesigning our TS branching stategy as depicted below:
As per this approach:
Development would happen on a dev branch such as DevRel1 branch only
If a developer needs to work on a big feature, he would work on a
branch such as Feature 1 branch, branched from Dev branch. On
completion he would merge back to dev branch.- For probably features, which may or may not go in this release, the
develop needs to work on probably feature branched from main branch.
As per final decision, it would be base less merged into appropriate
dev branch. - Code would be deployed in Dev environment from Dev branch
- Code would be deployed to QA branch from Main
- For release, main would be branched to a new release branch
- Hot fixes on QA happen on Main branch, and on Release happen on
release branch. RI from release happens to main, and FI to dev
branches happen in this case
Is this getting too complex? can it be simplified, does this look fine process wise, or does it need correction?
We are using TFS 2008 at the moment.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的建议是让事情尽可能简单。恕我直言，要避免的主要事情是：
因此，您绝对应该使用分支来支持您的开发需求，但尽量保持您的方案尽可能简单。
我们使用与您类似但更简单的方法。那就是：
我们的其他关键策略是：
使用持续集成、单元测试、回归测试、门控签入和持续 QA 测试来保持开发分支尽可能稳定。我们的目标是任何日常构建“应该”足以直接交付给客户。实际上，偶尔会在短时间内（几天）失去稳定性，但大多数情况下，当这种情况发生时，我们仍然在几天内获得可发布的版本。
推迟创建分支，直到绝对需要为止。在 TFS 中，您可以从代码库历史记录中的任何点追溯创建分支。因此，当我们准备启动发布分支时，我们实际上并不创建分支，而只是将当前版本构建发送到 QA 部门进行测试。如果他们对该构建的质量感到满意，它将按原样提供给客户，而不会创建任何分支。只有我们需要修复该版本的错误时，我们才真正创建分支（从构建原始候选版本的时间点开始，所以我们知道它从经过充分测试的版本开始）代码快照）并产生（小）成本。
作为旁注，我们还尝试了一个 Dev 分支，对 QA 分支进行门控签入，对 Release 分支进行门控签入，但这效果很差（主要是我们发现它给所有开发增加了相当大的开销。我们喜欢频繁签入，并且每次签入的两个额外的测试和合并步骤都很昂贵，在最坏的情况下，如果您删除、移动或重命名 TFS 中的文件，它会变得非常不稳定，甚至简单的合并都会失败 - 这些都很难且耗时。决定TFS 中的合并仍然不够轻量和强大，不足以支持这种方法，除非您准备投入大量时间来管理分支。另一方面，如果开发人员在签入时非常小心，那么对分支的需求就会少得多。因此，我们换回了上面的轻量级方法，这增加了风险，但最大限度地减少了合并的需要 - 对于我们（拥有规模较小且纪律严明/有能力的团队）来说，这种方法效果更好。
My advice would be to keep things as simple as you can. IMHO the main things to avoid are:
So you should definitely use branching to support your dev needs, but try to keep your scheme as simple as possible.
We use a similar, but simpler, approach to yours. That is:
Our other key strategies are:
Use Continuous Integration, Unit Tests, Regression Tests, Gated Checkins and continuous QA testing to keep the Dev branch as stable as possible. Our aim is that any daily build "should" be good enough to ship straight to a customer. In reality there are occasional short periods (a few days) where that stability is lost, but most of the time when these happen we are still within a few days of having a releasable build.
Defer making branches until absolutely needed. In TFS you can retroactively create a branch from any point in the codebase history. So when we are ready to start a release branch, we don't actually create the branch but just send the current release build to the QA department for testing. If they are happy with the quality of that build, it goes to customers as is, with no branch having been created. It is only when we need to fix a bug for that release that we actually create the branch (from the point in time where the original release-candidate was built, so we know it starts from the well tested code snapshot) and incur the (small) costs that entails.
As a side note, we also tried a Dev branch, with gated checkins to QA branch with gated checkins to Release branch, but this worked poorly (Primarily we found that it added a considerable overhead to all development. We like to check in frequently and the two extra test-and merge steps for every checkin are expensive. In the worst cases, if you delete, move or rename files in TFS it becomes very flakey and even simple merges fail - these are difficult and time consuming to sort out. We decided that merging in TFS is still not lightweight and robust enough to support this sort of approach unless you are prepared to invest a lot of time into managing the branches. On the other hand, if devs are careful with their checkins, there is far less need for such a "rigorous" approach. So we swapped back to the above lightweight approach, which increases the risks but minimises the need to merge - for us (with a smallish and disciplined/competent team) this approach works better.
感谢您的所有回复。因此，我简化了我的设计，我们计划在对其进行测试运行之前对其进行一些调整。
新设计如下图（仍然欢迎评论！）
Thanks to all your responses. I have hence simplified my design and we plan to tweak it a bit before doing a test run on it.
The new design is as shown below(comments on it are still always welcome!)
我的 2 美分...
为了正确性，我建议将 PossibleFeature1 分支合并回其起源的同一分支，即 main.说到这一点，不要区分 Feature 和 PossibleFeature 分支。他们是一样的。功能总是会受到延迟、重新调整优先级的影响，无论出于何种原因它们最终不会出现在计划的版本中。原则上允许每个功能分支都具有这种灵活性。因此，对每个功能都一视同仁。
为了进一步简化您的模型（和您的生活），请考虑仅使用一个用于开发和质量检查的主分支。同时拥有两者所带来的额外开销和复杂性是不值得的。从主开发线将稳定的主版本部署到 QA。标记已发布的版本。
所以我的（个人）模型是有一个主要的开发分支。具有挑战性的大功能被放在自己的分支上。他们可能最终会进入发布版本，也可能会进入下一个版本，不用担心。定期从主分支合并到功能分支中，以保持它们同步。如果您需要暂时支持多个版本，那么最好有单独的发布分支。在稳定、alpha 和 beta 阶段之前启动发布分支。您可以考虑将部署到 QA 作为这些发布分支的一部分。
My 2 cents ...
For correctness, I would suggest to have the PossibleFeature1 branch merge back to the same branch it originates from, so the main. Talking about which, do not differentiate between a Feature and a PossibleFeature branch. They are the same. Features are alway subject to delay, reprioritization, whatever reason why they won't end up in the planned release. Allow this flexibility in principle for every Feature branch. So treat every Feature the same.
To further simplify your model (and your life) think about only having a main branch for development and QA. The additional overhead and complexity of having both is not worth the effort. Deploy stable main versions to QA from the main development line. Label the shipped versions.
So my (personal) model would be to have a main development branch. Big challenging features are put on their own branch. They might end up in the release, they might go to the next, no worries. Keep merging from the main into the feature branches on a regular basis to keep them in sync. It is good to have seperate Release branches if you have multiple versions out in the field that you need to support for a while. Start the Release branch before your stabilization, alpha and beta stages. You might consider deployment to QA as part of these Release branches.