How can I implement assembly pipeline with TFS

Question

I am trying to implement an assembly pipeline using TFS.

We already have TFS building our projects after each commit. But the assembly takes too much time, so we would like to divide the assembly into two stages. Continuous integration literature suggests this method.

So what I'm looking for is what needs to be done.

• The developer checks its source code.
• TFS automatically starts the assembly to compile the code and runs some basic tests (we already have this). The developer receives quick feedback that his changes did not violate anything obvious.
• Then, if the build is completed, a new task / TFS build starts, which takes artifacts from the previous step and runs some more time-consuming tests.

Any ideas on how to implement this?

Answer 1

1) Write a service that listens for the BuildCompleted event. Sample IIS Web Service Code . Stand-alone example WCF code . In the event handler, call the TFS build API to run a separate build type that defines additional tasks, or simply execute your own code directly from here.

2) Register your service using TFS, adding a side filter server for successful builds .

Answer 2

We are currently doing this using the <AfterEndToEndIteration> target in MSBuild and <Exec> using the TfsBuild.exe file.

 <Target Name="AfterEndToEndIteration"> <PropertyGroup> <TfsBuildExecutable>C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\TfsBuild.exe</TfsBuildExecutable> <CommandToTriggerNextStage>&quot;$(TfsBuildExecutable)&quot; start /server:$(TeamFoundationServerUrl) /buildDefinition:&quot;Project\Next Stage&quot; /queue</CommandToTriggerNextStage> </PropertyGroup> <Exec Condition=" '$(Status)'!='Failed' " Command="$(CommandToTriggerNextStage)" /> </Target> 

Answer 3

Perhaps your reseller or minor builds will lead the resulting builds to the original control. Thus, you may have another assembly using the already compiled DLL to package and build the second part of the system.

You may have a “large” build that will listen to records from library collections and build builds that depend on this.

Of course, you get a binary registration code, but if you are not doing something strange, you should have enough space for your hard drive.