有策略地进行分支
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
源代码是开发工作中的重要资产。 但是在多个开发人员同时处理文件更新时,有效地管理和改进源文件可能是一大难题。 可以使用版本控制系统将源代码存储在共享存储库中,以隔离并行开发工作、集成代码更改以及恢复以前的文件版本。 版本控制中的一个关键要素是分支,这可实现同时开发。 如果有策略地进行分支,则可以保持多个版本的软件的顺序和一致性。
Team Foundation 提供了一个灵活而可靠的版本控制系统。 你可以使用 Team Foundation 版本控制来管理开放源代码、文档、工作项和由团队处理的其他关键信息的过程中的多个版本。
通过多个项目版本同时引入多个更改时,团队如何管理代码?
使用版本控制系统时,必须考虑如何设置分支结构。 可以通过镜像源代码文件来创建分支。 随后可以更改分支,而不会影响源。 例如,如下图中的分支结构所示,MAIN 分支包含已通过集成测试的已完成功能,而 DEVELOPMENT 分支包含正在构造的代码。 当 DEVELOPMENT 分支中的新功能完成并且可以通过集成测试时,可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支。 此过程称为反向集成。 相反,如果将来自 MAIN 分支的代码合并到 DEVELOPMENT 分支,则该过程称为正向集成。
有关如何创建和合并代码分支的详细信息,请参阅 CodePlex 网站上的以下页面:Team Foundation Server 分支指南 2.0。
分支和合并需要遵循以下原则:
每个分支必须具有有关如何将代码集成到此分支中的已定义策略。 例如,在上图的分支结构中,可以分配团队成员以拥有和管理 MAIN 分支。 此成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。 当 MAIN 分支还集成来自其他分支的更改时,正向集成非常重要。
MAIN 分支必须包含已通过集成测试的代码,以便它始终准备好进行发布。
DEVELOPMENT(或工作)分支在不断演化,因为团队成员会定期签入更改。
标签是分支中的文件在特定时间的快照。
有关详细信息,请参阅使用标签获取文件快照。
Team Foundation Build 为你的分支提供多种生成类型:手动、持续、封闭、滚动和计划。 建议为 MAIN 分支选择封闭签入生成类型。 这意味着 DEVELOPMENT 分支必须通过 MAIN 分支的所有需求,然后您才能提交反向集成。 DEVELOPMENT 分支应运行连续生成类型,因为团队必须尽早知道新签入何时会影响 DEVELOPMENT 分支。
团队采用何种频率进行反向集成和正向集成?
如下图所示,应至少在完成某个用户情景时执行反向集成和正向集成。 尽管每个团队可能以不同方式定义完成,不过用户情景的完成通常意味着完成了功能以及对应的单元测试。 仅当单元测试验证了 DEVELOPMENT 分支的稳定性之后,才能向 MAIN 分支进行反向集成。
如果有多个工作 (DEVELOPMENT) 分支,则只要有任何分支集成到 MAIN 分支,便应向所有工作分支进行正向集成。 因为 MAIN 分支保持稳定,所以正向集成是安全的。 因为无法保证工作分支是稳定的,所以工作分支上可能会出现冲突或失败。
应尽快解决所有冲突,这十分重要。 通过将封闭签入用于 MAIN 分支,可帮助使反向集成更容易,因为质量把关可帮助避免 MAIN 分支中出现冲突或错误。 有关详细信息,请参阅签入到由封闭签入生成过程控制的文件夹。
团队如何对实现不同用户情景的源进行管理?
如下图所示,可以定期将更改签入工作分支以完成用户情景。 可以同时在同一个分支中实现多个用户情景。 但是,仅当完成了所有正在进行的工作时,才能向 MAIN 分支进行反向集成。 建议按相似大小对用户情景分组,因为你不希望大型用户情景阻止集成许多小的用户情景。 可以将两组用户情景拆分为两个分支。
团队应在何时添加分支?
应在以下情况下创建分支:
必须在与现有分支不同的计划/周期上发布代码时。
代码需要不同分支策略时。 如果创建的新分支具有新策略,则可以向项目添加战略值。
向客户发布功能,并且团队计划进行不会影响计划的发布周期的功能时。
不应为每个用户情景都创建分支,因为会形成较高的集成成本。 虽然 TFVC 使分支变得简单,不过在具有许多分支时,管理分支的开销可能会很高。
团队如何从版本控制的角度管理发布?
团队应能够在任何冲刺 (sprint) 结束时发布代码。 通过使用 Team Foundation Server,可以标记一个分支,以便在特定时间点拍摄代码的快照。 如下图所示,可以标记一个版本的 MAIN 分支。 这使您可以将分支返回到它在这点的状态。
因为必须在发布时实现更新,所以为发布创建分支可帮助团队在下一个冲刺 (sprint) 中独立工作,而不会与将来的发布形成冲突。 下图显示一个分支,其中包含更新代码,会在第二个冲刺 (sprint) 结束时进行发布之后反向集成到 MAIN 支中。
为发布创建分支时,应从 MAIN 分支(它最稳定)创建该分支。 如果从工作分支为发布创建分支,则可能会导致集成难题,因为无法保证工作分支的稳定性。