Creating a TFS Custom "Builds" Check-In Policy

时间:2016-08-31 18:43:46

标签: c# .net tfs azure-devops tfs2015

The built-in TFS Builds Check-In Policy isn't configurable - it just looks to see if the last build failed, and if so, it shows the Policy warning in Visual Studio. Unfortunately, it considers the "last" build to be the one that last finished in time, not the last one to finish with the most recent changeset. As a result, it's possible for the Policy to be Clear even though things are broken. Consider this scenario:

Joe commits code in Changeset 1234 and it starts build "Awesome Build" John commits code in Changeset 1235 and it starts build "Awesome Build" as well, but change set 1235 contains a break

Since I have multiple build agents, both builds run at the same time.

Now let's say John's build finishes first and fails because of the break - the build policy is now in a Broken state - warning that you can't checkin (as expected).

Joe's build finishes second and succeeds - the build policy at this point will revert to a clear state, and no warning will appear. (not expected, the last changeset is still broken and needs to be fixed).

I know TFS allows me to create my own custom check-in policies by compiling a class implementing 'Microsoft.TeamFoundation.VersionControl.Client.PolicyBase'. There are some questions here though:

  1. The only OFFICIAL documentation I could find is here (https://msdn.microsoft.com/en-us/library/bb668980.aspx) and as the page suggests, this content is deprecated and no longer maintained. Does this imply there is a new/better/easier way to implement a custom check-in policy?

  2. Does anyone know where I can find documentation pertaining to writing these policies, specifically a "Builds" policy to solve the problem I outlined above. I'd like my check-in policy to be enforced base on latest changeset, not most recent build time.

Any help you can give would be great. This policy fix will fix up a lot of headaches in my very large development group.

1 个答案:

答案 0 :(得分:0)

你提供的文章是简单而且更好的方式它适用于更高版本,注册密钥路径是根据VS(8.0,12.0等...)的版本,对于64位机器,路径喜欢HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ VisualStudio {VisualStudioVersion} \ TeamFoundation \ SourceControl \ Checkin Policies。

在自定义签入策略中,您可以通过TFS API(评估方法)检查​​最新的构建结果。例如:

TeamFoundationServer tfs = new TeamFoundationServer("http://tfsserver:8080/tfs"); 
IBuildServer buildServer = (IBuildServer) tfs.GetService(typeof(IBuildServer)); 
IBuildDetailSpec buildDetailSpec = buildServer.CreateBuildDetailSpec("Team Project", "Build Definition Name"); 
buildDetailSpec.MaxBuildsPerDefinition = 1; 
buildDetailSpec.QueryOrder = BuildQueryOrder.FinishTimeDescending; 
IBuildQueryResult results = buildServer.QueryBuilds(buildDetailSpec);

如果您只是需要确保更改无法解决问题(构建可以成功),因为Daniel说使用门控签入(TFVC)或拉取请求与分支策略(git)。