在使用分支时,如何确定特定TFS构建中固定的工作项?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (25)

我们已经开始在TFS 2010中使用以下分支结构:

到目前为止,所有更改都已在开发分支中执行,并且所有签入已与任务工作项关联。任务都是Bug或产品待办事项项目工作项目的子项目。每个CI构建都会针对特定的变更集进行触发,并且变更集与任务相关联,因此我们可以手动计算出刚刚构建的Bug或PBI。

代码生成一段时间后,部署到集成环境并由开发人员进行测试,它将合并到Main分支。显然,多个变更集可能会同时合并到Main中。如果我们在此之前没有手动触发夜间,夜间构建将构建此代码。QA稍后会将这些“主”构建中的一个部署部署到QA环境中。

自上次部署质量保证以来,主分支可能有多个版本。这些构建与“合并”变更集相关联,而不与与任务相关的原始变更集关联。

我如何确定由给定的“主”构建所处理的任务集,这是与任务工作项关联的构建的不同分支的构建?

一旦我们开始准备发布,我们可能需要在发布分支进行更改,这会使事情进一步复杂化,因为我们将从发布版本恢复到主发布版本,并且发布更改集将与任务关联。那些将被合并到发展,使生活更有趣!

提问于
用户回答回答于

看看雅虎Ehn的博客文章TFS 2010中的自动合并工作项目。他写了一个插件,可以从codeplex下载。它将自动关联与合并的变更集关联的工作项目。因此,当你合并到Main或Release时,工作项目将与这些分支中的变更集相关联,并且工作项目将包含在构建报告中以供构建这些分支。该插件非常易于部署。

用户回答回答于

你可以构建一个自定义工作流活动,您可以在构建过程中运行该活动,以便遍历通常关联的每个变更集的合并历史记录。它基本上是从一组已知的相关变更集开始行走。我更喜欢这种方法,因为您可以让开发人员担心只需将工作项目与原始变更集关联起来,而不必使用合并变更集也可以完成。

扫码关注云+社区