分支版本，功能，子功能和环境

Question

我在发布之前已经通过了TFS游侠指南。

我的项目中有以下要求：

1. 发布第1版
2. 它部署在Dev环境中进行集成和健全性测试
3. 如果没问题，那么代码将部署在QA环境中
4. 如果没问题，QA发布的代码将在生产中部署。

目前，我们在CODE下的TFS中有一个代码库，开发人员代码。 以上是分支到DEV镜像dev环境代码 DEV分支分支到QA分支

如果需要热修复，则直接在QA分支上修复，然后反向合并到下面的分支。

在第一次开发之前这很好，但我认为需要重新构建，以便为将来的版本开发提供更好的可扩展性。

当前问题：

1. 需要计划支持将来的版本1.5开发
2. 目前有一些功能/修复可能会/可能不会进入 当前版本。开发人员现在就把它搁置起来 将来可以取消搁置。问题是，随着时间的推移，货架成为了 由于没有历史而合并的巨大痛苦
3. 有时候，人们会在货架上处理大型功能长达一周的时间。 合并成为一个巨大的油漆，直到那时数十个文件 也受到很多人的欢迎。

记住以上所有内容，我正在考虑重新设计我们的TS分支策略，如下所示：



按照这种方法：

• 开发将在Dev分支上进行，例如仅DevRel1分支

• 如果开发人员需要处理大型功能，那么他就可以使用 分支，如特征1分支，从Dev分支分支。在
  完成后他会合并回dev分支。

• 对于可能的功能，可能会或可能不会在此版本中， 开发需要工作可能从主分支分支。 根据最终决定，它将基础较少合并为适当的 dev branch。
• 代码将从Dev branch
部署在Dev环境中
• 代码将从Main
部署到QA分支
• 要发布，main将分支到新的发布分支
• QA上的热修复发生在主分支上，并且在发布时发生 发布分支。发布的RI发生在main，而FI发送到dev 在这种情况下发生分支

这变得太复杂了吗？可以简化，这看起来很好，还是需要纠正？

我们目前正在使用TFS 2008.

Answer 1

我的建议是尽可能保持简单。恕我直言，要避免的主要事项是：

• 复杂性让人困惑。复杂性越高，处理所需的时间越多，最终完成的合并就越多，所犯的错误就越多。如果您不需要某个流程，请将其删除。
• 如果您处理分支中的代码，那么您将来需要合并代码。在合并之前存在的分支越长，合并变得越困难和耗时。
• “Piggybacking”彼此分支的层次结构引入了通过多个级别合并以将代码返回到dev分支的需要，这使得将更改从外围分支推回到主代码库中变得非常耗时。 / LI>

因此，您绝对应该使用分支来支持您的开发需求，但请尽量使您的方案尽可能简单。

我们对您使用类似但更简单的方法。那就是：

• 我们在Dev分支上工作。每日构建都来自这个分支，以实现持续的QA。
• 当需要发布“代码冻结”时，会发布一个Release分支。可以在任一分支中进行错误修复，但如果发布需要，则始终立即合并以保持dev＆amp; amp;同步发布。如果可能的话，我们尽量不让发布与主分支分开。我们从来没有一个活跃的发布分支。
• 当开发小功能，或者可以开发功能而不会在应用程序中“启用”或以其他方式影响代码的稳定性时，我们将继续在Dev分支中开发代码。 E.g我们可能会使用#if条件来禁用代码，直到在日常测试版本中“激活”安全为止。这最大限度地减少了分支的需要。
• 当开发出可能破坏Dev分支的大型功能时，我们会在单独的功能分支上工作。我们尝试规划该功能以最小化允许功能/ dev分支共存的时间，并且如果可能的话，停止开发人员在开发功能时处理代码的相关区域，以最小化功能完成时的合并问题。如果在版本之间开发可能的功能以最小化重叠（并发分支的数量）。

我们的其他关键策略是：

• 使用持续集成，单元​​测试，回归测试，门控检查和连续QA测试，以使Dev分支尽可能稳定。我们的目标是，任何每日构建“应该”足够好，可以直接运送给客户。实际上偶尔有一段短暂的时间（几天）会失去稳定性，但是大部分时间发生这种情况时，我们仍然可以在几天内进行可释放的构建。

• 推迟分支，直到绝对需要。在TFS中，您可以从代码库历史记录中的任何位置追溯创建分支。因此，当我们准备启动发布分支时，我们实际上并不创建分支，而只是将当前发布版本发送给QA部门进行测试。如果他们对该构建的质量感到满意，那么它将按原样发送给客户，而不会创建任何分支。只有当 我们需要为该版本修复我们实际创建分支的错误时（从构建原始版本候选者的时间点开始，所以我们知道它从经过良好测试开始代码快照）并产生需要的（小）成本。

作为旁注，我们还尝试了一个Dev分支，带有门禁签到QA分支，门禁签到Release分支，但是效果不佳（主要是我们发现它为所有开发增加了相当大的开销。我们想检查经常和每个签入的两个额外的测试和合并步骤是昂贵的。在最坏的情况下，如果您删除，移动或重命名TFS中的文件它变得非常有趣，甚至简单的合并失败 - 这些是困难和耗时的排序我们认为合并TFS仍然不够轻巧，不够强大，无法支持这种方法，除非你准备投入大量时间来管理分支机构。另一方面，如果开发人员小心他们的签到，那么这种“严谨”的方法远不那么需要。所以我们换回了上面的轻量级方法，这增加了风险，但最大限度地减少了合并的需要 - 对于我们（对于一个规模小，训练有素/能干的团队），这种方法效果更好。

Answer 2

感谢您的所有回复。因此我简化了我的设计，我们计划在对它进行测试之前稍微调整一下。

新设计如下所示（对它的评论仍然欢迎！）

Answer 3

我的2美分......

为了正确，我建议让 PossibleFeature1 分支合并回它所源自的同一分支，所以主要。谈论哪些，不区分功能和 PossibleFeature 分支。他们是一样的。功能总是受到延迟，重新优先级排序，无论他们为什么不会在计划发布中结束的原因。原则上允许每个功能分支具有这种灵活性。因此，对待每个功能都是一样的。

为了进一步简化您的模型（以及您的生活），请考虑只有一个主分支用于开发和QA。两者的额外开销和复杂性是不值得的。从主开发线向QA部署稳定的主要版本。标记出货版本。

所以我的（个人）模型将是一个主要的开发分支。极具挑战性的功能被放在他们自己的分支上。他们可能会在发布时结束，他们可能会进入下一个，不用担心。保持定期从主要功能分支到功能分支以保持同步。如果你需要支持一段时间的字段中有多个版本，那么拥有单独的Release分支是很好的。在稳定，alpha和beta阶段之前启动Release分支。您可以考虑将部署到QA作为这些Release分支的一部分。