分支版本,功能,子功能和环境
在发布之前,我已经通过了TFS游侠指南.
我在项目中有以下要求:
- 发布第1版
- 它部署在Dev环境中进行集成和健全性测试
- 如果没问题,那么代码将部署在QA环境中
- 如果没问题,QA发布的代码将在生产中部署.
目前,我们在CODE下的TFS中有一个代码库,开发人员代码在那里.以上分支到DEV镜像环境代码DEV分支分支到QA分支
如果需要热修复,则直接在QA分支上修复,然后反向合并到下面的分支.
在第一次开发之前这很好,但我觉得这需要重新构建,以便为将来的版本开发提供更好的可扩展性.
当前的问题:
- 需要计划支持未来的1.5版开发
- 目前有一些功能/修复可能会/可能不会在当前版本中.开发人员此刻只是搁置它,以便将来可以取消搁置.问题在于,随着时间的推移,货架因合并而变得巨大痛苦,因为它们没有历史
- 有时人们在货架上工作长达一周的大功能.合并成为一个巨大的油漆,直到那时,许多人也开展了数十个文件.
记住以上所有内容,我正在考虑重新设计我们的TS分支策略,如下所示:
按照这种方法:
开发将在dev分支上进行,例如DevRel1分支
如果开发人员需要处理大型功能,他将在一个分支上工作,例如从Dev分支分支的Feature 1分支.在
建成之后,他合并回Dev分支.- 对于可能的功能,可能会或可能不会在此版本中,开发需要工作可能从主分支功能分支.根据最终决定,它将更少合并到适当的开发分支.
- 代码将从Dev分支部署在Dev环境中
- 代码将部署到Main的QA分支
- 对于发布,main将分支到新的发布分支
- 质量保证的热修复发生在主分支上,而发布则发布在发布分支上.从发布的RI发生在main,在这种情况下发生FI到dev分支
这太复杂了吗？可以简化,这看起来很好,或者需要纠正吗？
我们目前正在使用TFS 2008.
我的建议是让事情尽可能简单。恕我直言，要避免的主要事情是：
- 复杂性使人们感到困惑。复杂性越高，处理所需的时间就越多，最终进行的合并就越多，犯的错误也就越多。如果您不需要进程，请将其删除。
- 如果您在分支中处理代码，那么您将来必然需要合并代码。分支在合并之前生存的时间越长，合并就会变得越困难和耗时。
- “搭载”彼此之间的分支层次结构需要通过多个级别进行合并才能将代码返回到开发分支，这使得将外围分支的更改推回到主代码库非常耗时。
因此，您绝对应该使用分支来支持您的开发需求，但尽量保持您的方案尽可能简单。
我们使用与您类似但更简单的方法。那是：
- 我们在开发分支工作。每日构建来自该分支以进行持续的质量检查。
- 当需要发布“代码冻结”时，就会创建发布分支。可以在任一分支中进行错误修复，但如果发布需要，它总是立即合并以保持开发和发布同步。如果可能的话，我们尽量不让版本偏离主分支。我们一次不会有多个发布分支处于活动状态。
- 当开发小的功能时，或者可以开发功能而不会在应用程序中“启用”或以其他方式影响代码的稳定性时，我们会继续在 Dev 分支内开发代码。例如，我们可以使用 #if 条件来禁用代码，直到可以在日常测试版本中安全地“激活”为止。这最大限度地减少了分支的需要。
- 当开发出一个可能会破坏 Dev 分支的大型功能时，我们会在一个单独的功能分支上工作。我们尝试规划该功能，以最大程度地减少允许功能/开发分支共存的时间，并且如果可能的话，在开发该功能时停止开发人员处理代码的相关区域，以最大程度地减少该功能完成时的合并问题。如果可能的话，在版本之间开发功能以最小化重叠（并发分支的数量）。
我们的其他关键策略是：
使用持续集成、单元测试、回归测试、门控签入和持续 QA 测试来保持开发分支尽可能稳定。我们的目标是任何日常构建“应该”足以直接交付给客户。实际上，偶尔会在短时间内（几天）失去稳定性，但大多数情况下，当这种情况发生时，我们仍然在几天内获得可发布的版本。
推迟创建分支直到绝对需要时。在 TFS 中，您可以从代码库历史记录中的任何点追溯创建分支。因此，当我们准备启动发布分支时，我们实际上并不创建分支，而只是将当前版本构建发送到 QA 部门进行测试。如果他们对该构建的质量感到满意，它将按原样提供给客户，而不会创建任何分支。只有当我们需要修复该版本的错误时，我们才真正创建分支（从构建原始候选版本的时间点开始，因此我们知道它从经过良好测试的代码快照开始）并招致（小）所需的成本。
作为旁注，我们还尝试了一个 Dev 分支，对 QA 分支进行门控签入，对 Release 分支进行门控签入，但这效果很差（主要是我们发现它给所有开发增加了相当大的开销。我们喜欢频繁签入，并且每次签入的两个额外的测试和合并步骤都很昂贵。在最坏的情况下，如果您删除、移动或重命名 TFS 中的文件，它会变得非常不稳定，甚至简单的合并也会失败 - 这些问题很难解决，而且很耗时。我们认为 TFS 中的合并仍然不够轻量级和强大，不足以支持这种方法，除非您准备投入大量时间来管理分支。另一方面，如果开发人员在签入时非常小心，那么情况会少得多所以我们换回了上面的轻量级方法，这增加了风险，但最大限度地减少了合并的需要——对于我们（拥有一个规模较小且纪律严明/有能力的团队）来说，这种方法效果更好。