8

I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).

I wonder what the easiest way is to test the build templates I'm creating? Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?

I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).

Robaticus
  • 22,857
  • 5
  • 54
  • 63
Patrick Huizinga
  • 1,342
  • 11
  • 25
  • 1
    Over two years have gone by and a new version of TFS and VS and still no solution to this problem. Does anyone know of any Microsoft Connect feedback item for this that we can up vote? – user392139 Aug 06 '13 at 22:20

3 Answers3

4

Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.

James Reed
  • 13,873
  • 51
  • 60
0

I want to test my builds against the teams latest code-base without having to branch it over to a trial project.

Instead, I do the following:

  1. Create a separate build definition called 'Infrastructure'
    • clone a production definition
  2. Set the trigger on the Infrastructure build definition to manual.
  3. Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
    • keeps the notification of broken builds away from the bulk of the team).
  4. Create a separate build process template, called 'Infrastructure.xaml'.
  5. Point the Infrastructure build definition at the Infrastructure process template.

Now when I want to iterate on a new build feature for the team:

  1. Check out the build process template I want to update, and lock it.
  2. Copy the build process template I want to update overtop of the Infrastructure.xaml.
  3. Add my build feature to the Infrastructure.xaml file, and check that in.
  4. Use the Infrastructure build definition to test my changes.
  5. Iterate over 3-4 until I get it right.
  6. Complete the feature and have my changes verified by another Infrastructure team member.
  7. Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.

This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.

d3r3kk
  • 3,465
  • 3
  • 18
  • 22
0

@d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.

Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.

Nekoashi
  • 83
  • 4