多个构建定义以及关联的提交和工作项 [英] Multiple build definitions and associated commits and work items

查看:87
本文介绍了多个构建定义以及关联的提交和工作项的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有TFS 2015 Update 3,并希望为同一个Git仓库创建两个构建定义:



  • ProductA手册(候选版本)
  • ProductA CI(持续集成)

手动构建定义允许用户对候选发布版本进行排队(包括构建安装程序和一堆包装产品所需的其他构建步骤。)


CI构建定义只是构建产品以确保它编译,运行单元测试,并收集代码指标。 / p>

我发现当我将代码更改到我的仓库时,CI构建运行很好,代码更改和相应的工作项与该构建相关联。  这很好,除了当我决定将手动构建排队以创建
a发布候选版本时(通常在发生许多CI构建之后的日期),我希望代码更改和相应的工作项因为上一个手动发布候选版本与此新版本候选版本相关联。  相反,
我发现TFS没有将任何提交或工作项与发布候选版本相关联,因为它们被CI版本吞没了。  最终,我要做的是能够动态创建更改日志/发布说明,其中
准确显示最新候选版本中包含的更改。  我们的质量保证团队测试发布候选版本而不是CI版本,因此有这些信息会很棒。


我想知道是否有办法让这个工作正常。  我可以配置CI构建以跳过/禁止源代码和工作项关联检查,如果可能的话,以便下一个候选版本构建具有正确的
更改列表。


解决方案

你好mcobum,


你可以 首先使用TFS API获取最新的候选版本和前一版本。


请参阅此链接以获取构建: http://stackoverflow.com/questions/5263005/tfs-api-how-to-query-builds-independent-of-which-build-definition -they-belongs


其次,获取这两个版本的源版本ID。然后按源版本ID获取两个版本文件。


从源代码管理下载文件,请参阅此链接:https://paulselles.wordpress.com/2014/01/08/team-foundation-server-api-programmatically -downloading-files-from-source-control /


然后以编程方式在所有文件的两个版本之间获得差异:
http://stackoverflow.com/questions/11263251 / programatically-a-diff-between-an-file-of-a-file-in-tfs

 


最好的问候


I have TFS 2015 Update 3 and would like to create two build definitions for the same Git repo:

  • ProductA Manual (Release Candidate)
  • ProductA CI (Continuous Integration)

The manual build definition allows a user to queue a release candidate build (which includes building the installers and a bunch of other build steps that are needed to package up the product).

The CI build definition simply builds the product to ensure it compiles, runs the unit tests, and will gather code metrics.

I am finding that when I check in a code change into my repo, the CI build runs which is great and the code change and corresponding work item is associated with that build.  That is fine, except that when I decide to queue the manual build to create a release candidate build (usually at a later date after many CI builds have occurred), I'd like the code changes and corresponding work items since the last manual release candidate build to be associated with this new release candidate build.  Instead, I am finding that TFS doesn't associate any commits or work items with the release candidate build because they get swallowed up by the CI builds.  Ultimately, what I am trying to do is be able to dynamically create a change log / release notes which accurately shows what changes have been included in the latest release candidate build.  Our QA team tests the release candidate builds not the CI builds so having this information would be great.

I'd like to know if there is a way to get this to work.  I'd be ok with configuring the CI builds to skip/suppress source code and work item association checking, if that were possible so that the next release candidate build would have the correct list of changes.

解决方案

Hi mcobum,

You could first use TFS API to get the latest release candidate build and the previous one.

Refer to this link to get builds:http://stackoverflow.com/questions/5263005/tfs-api-how-to-query-builds-independent-of-which-build-definition-they-belong

Second, get the source version id of these two builds. Then get two versions files by source version id.

Downloading Files from source control, refer to this link:https://paulselles.wordpress.com/2014/01/08/team-foundation-server-api-programmatically-downloading-files-from-source-control/

Then programatically get a diff between two versions of all the files: http://stackoverflow.com/questions/11263251/programatically-get-a-diff-between-two-versions-of-a-file-in-tfs  

Best Regards


这篇关于多个构建定义以及关联的提交和工作项的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆