Can I use a single TFS 2010 build definition for multiple branches?

Question

I care about the builds of our products and asked me to come up with a way to customize the existing build definition to create different branches as needed.

The build process for this product already has several user steps and actions, and the product has a large number of project files that are built, so it is inefficient to configure a new build definition for each new branch that is created.

The build definition is configured to build from the main section. The goal is to introduce a specific branch (using the workflow argument that can be entered when building the assembly), which will then be created instead of the default main branch, without having to edit the assembly definition.

I have a separate test program that I use to test all of my custom actions and build procedures. In the workflow for this build definition, I added some assembly messages for logging so that I can view the values ​​of the variables used in the build process.

I also created a branch based on this test program, ready to test the assembly definition, which can be used to build more than one branch

First, I started the assembly for the source files of the test solution project from the source branch, and then I changed the definition of the assembly so that it was done using the new branch and another assembly started. When comparing build logs between two branches, there are only a few minor differences between them. (Logging Verbosity is set for diagnostics)

1st difference. I looked at the Workspace variable, and the Folders property of the assembly refers to their respective branches, in particular the ServerItem property of the Folders property

The second difference - Created project files (BuildSettings.ProjectsToBuild) come from the corresponding branches

I have not seen any other differences between the two build logs other than these

The main question is here :

Is there a standard way to replace branches built to define a single assembly?

If not, is it possible to simply change all the links to the default Main branch in a custom workflow template (in Workspace and BuildSettings.ProjectsToBuild) to the entered branch when the build is in order?

As always, well in advance for any help.

Answer 1

I managed to change the assembly workflow template so that I could build assemblies for several branches of the solution. To do this, I had to change some things in the workflow, as well as create additional workspaces for the service account that runs the builds.

• I added an argument to the workflow so that the required branch can be entered when the assembly is queued.

• I changed the drag and drop location for the assembly so that it was important for the branch entered (optional)

• A separate source directory has been created on the assembly machine for branch assembly

• Initialized the name WorkspaceName and SourcesDirectory to match the new workspace name and source directory folder

• I created a custom action to change the list of projects / solutions in BuildSettings.ProjectsToBuild so that they refer to them from the entered branch

• I noticed during the testing phase that although my new workspace for the introduced branch was initially configured to use the introduced branch as its ServerItem, it would still create a workspace with ServerItem that was introduced into the assembly definition. To get around this, I created another custom operation to reassign the branch workspace so that ServerItem points to the correct branch

There are several other things that I have involved in my workflow, but they are more of a trick that my developers requested, the above steps led to the creation of several branch constructs to define a single assembly.

Answer 2

I also needed even more branching flexibility in my build definitions, so I applied code activity to modify ProjectToBuild (e.g. Vermin step 5 above). Here's the code (project specific material removed):

[BuildActivity(HostEnvironmentOption.All)] public sealed class ConvertProjectsAccordingToBranch : CodeActivity { public static string s_MainBranch = "$/MyTeamProject/Main"; public InArgument<IBuildDetail> BuildDetail { get; set; } public InArgument<BuildSettings> BuildSettingsOriginal { get; set; } public OutArgument<BuildSettings> BuildSettingsConverted { get; set; } protected override void Execute(CodeActivityContext context) { Logger.Instance.Init(context); IBuildDetail buildDetail = BuildDetail.Get(context); BuildSettingsConverted.Set(context, ConvertProjects(BuildSettingsOriginal.Get(context), buildDetail.BuildDefinition)); } /// <summary>Returns a BuildSettings with ProjectsToBuild converted according to the build definition workspace</summary> public BuildSettings ConvertProjects(BuildSettings settingsOriginal, IBuildDefinition buildDefinition) { var mappings = buildDefinition.Workspace.Mappings; if (mappings.Count() != 1) { throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture, "Build definition must have exactly one workspace mapping. Build definition ID:{0} has {1} mappings", buildDefinition.Id, // IBuildDefinition doesn't have any Name property, seriously! mappings.Count())); } string definitionBranch = mappings.First().ServerItem; var settingsConverted = new BuildSettings() { PlatformConfigurations = settingsOriginal.PlatformConfigurations, }; foreach (string projectOriginal in settingsOriginal.ProjectsToBuild) { var projectConverted = projectOriginal.Replace(s_MainBranch, definitionBranch); if (!projectConverted.StartsWith(definitionBranch)) { throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture, "Project {0} is not under main branch {1}, Definition branch: {2}", projectOriginal, s_MainBranch, definitionBranch)); } settingsConverted.ProjectsToBuild.Add(projectConverted); Logger.Instance.Log("Converted ProjectToBuild: {0}, original: {1}", projectConverted, projectOriginal); } return settingsConverted; } } 

I also have a unit test for ConvertProjects() , but it depends on the local material, so I have not published it here. This is trivial and definitely worth writing!

Answer 3

I know this is very old, but just in case anyone finds this post.

We have one and the same requirement: the ability to create a function branch to create an assembly of a specific function used for testing before merging into Development.

Here's how we did it:

Created a set of Visual Studio extensions:

• Create a branch structure
• Run branch assembly
• Delete branch

Create an assembly branch will clone the assembly definition, which is used as a template. Change the name of the build definition and the branch-based workspace. The build definition will be visible in Team Explorer (VS2012).

Starting branch assembly will find the definition of the assembly and start the assembly.

Delete branch will find the assembly definition, delete all assemblies, delete the assembly definition and delete the branch (Clear). Rows and branches have a short lifespan, so it is important that they be cleaned.

Answer 4

In short: No and Yes :-)

For more information about these answers, the templates of standard TFS systems prefer to have one assembly definition for each branch that you want to build, or specify all branches that need to be built on onces, but in one assembly definition. There is no standard way to select from the available branches in the Queue new build dialog box.

The following answer: Yes, because you can customize your build template, and I understand that you have already started to do this. Depending on your branching structure, it’s quite easy to add a property to your template that appears in the dialog box for the new queue assembly and have (for example) a separator column with delimiters located on the half-column with all the branches that you want to create during the run , And for each item in this list, add a build solution during the workflow before the template starts iterating this list.

What should be done, however, I'm interested in how you ended up in this ability? You are not using VS files VS?