5
votes

I try to implement a build pipeline using TFS.

We already have TFS building our projects after each commit. But the build take too long so we would like to split the build into two stages. Continuous integration literature suggest this technique.

So what I am looking for is something to do the following.

  • Developer checks in his source code.
  • TFS automatically triggers a build to compile the code and run some basic tests (we already have that). The developer gets quick feedback that his changes did not break something obvious.
  • Next if the build succeeded a new TFS task/build is triggered which takes the artifacts from the previous stage and runs some more time consuming tests.

Any ideas on how to implement this?

3

3 Answers

2
votes

1) Write a service that listens for the BuildCompleted event. IIS webservice sample code. Self-hosted WCF sample code. In your event handler, either call the TFS Build API to kick off a separate build type that defines additional tasks, or simply execute custom code directly from here.

2) Register your service with TFS, adding a server side filter on successful builds.

1
votes

At the moment we're doing this using the <AfterEndToEndIteration> target in MSBuild, and <Exec>ing TfsBuild.exe.

<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>
0
votes

You could have your intermediary, or minor builds check-in the resulting assemblies into source-control. That way you can have the other build use the already compiled DLL's to package and build the second part of the system.

You could have the "bigger" assembling build listen to check-ins from the library builds and assemble the builds dependant on that one.

Sure you get to check-in binary code, but unless your doing something strange you should have enough harddrive space.