How to chain TFS builds?

It depends what you are trying to do.

1) Do you want the build + staging to run as one operation? So that you end up with one consolidated build report, one log file, one job in the server's build queue, every step executed sequentially by the same Build Agent that executed the previous step?

If so, then you are on basically the right path. I wouldn't <Exec> out to tfsbuild.exe though -- running an entire new build has a lot of overhead, and I'm not sure what the potential side effects are. Instead, I would use the <Call> task to execute msbuild tasks defined in your staging script(s).

2) Do you want the "build build" to actually queue a separate "staging build"? Separate reports, log files, & spots in the queue? Opportunity to be executed in parallel if you have multiple Build Agents?

If so, then:

create a new build definition(s) for staging
add some code to your original build definition that queues [one/several] of the new build definitions using the Team Build API. Sample code.
remove anything not related to the core build from the original build definition
make sure the new "staging" definitions don't have any automatic triggers (time intervals, checkin events, etc)

Preferably step 1, but <call> task cannot be used as you suggest. The staging build needs to be driver of the build in this case. It calls the core build and then does its custom staging. The problem with using a Minimal tfsbuild proj file is that, TFSBuild definition file created via the UI sets all path properties based on the solution picked to be built.(as we agree, staging build definition should not rebuild the solution) So is a pain to get the paths configured to call the right core TFSBuild.proj file without hardcoding them.

2009-07-27 03:50:34

I don't understand the problem. Why not store your staging scripts in the same directory as your build scripts? Actually, even that is not necessary -- just ensure the relative paths stay the same. ///// If that doesn't help, please give more detail on what you're trying to do. What are the exact things you expect to happen in the "first build" and "second build?" What tasks do they have in common, and what needs to be customized?

Richard Berg 2009-07-31 19:37:39

BTW, depending on what you're trying to do, Team Build might not be the right approach at all. For instance, my test environments are setup on a "pull" model instead of "push". Each machine subscribes to the TFS notification system. When a BuildCompletion event is raised, a service on the machine checks against various criteria configured for that box and redeploys a test environment as appropriate.

Richard Berg 2009-07-31 19:49:58

I can rather do it in CC instead of dealing with learning curve for TFSDeployer for a rather simple task like this.Why should it be that difficult to do something so straightforward in TFS that you need to rely on other tools? I'm surprised not many people are even talking about chained TFS builds

2009-07-28 16:58:23

Chained build would knock my version numbering out. I use a single build to build all of the "Artifacts" and then I need to deploy it to DEV then System Test then QA then Beta and finaly Live. This is done so there is absolutly no posability of a contaminated build (developer checkin). If there is a problem then we go back to DEV. This is done on every feature branch untill it is passed QA/UAT before being merged into main and the Branched for a release. :)

MrHinsh 2009-07-29 07:22:04

ansaurus

tags:

views:

answers:

How to chain TFS builds?

related questions