Friday, May 01, 2009

Real Incremental Build - Part 3 – Out of the box with Team Build

See Part 1 – for motivation.
See Part 2 – Plan for getting only new/updated files.

Ok, so how do we actually perform our plan?

We will write an application which does the following

  1. Run Build with the original source:

    See Building a Specific Version with Team Build 2008.
    to put here the bottom line – add the following parameter to the command-line arguments:
    /p:GetVersion=version (where version can be C### – which means – Changeset number ###)

    for doing this programmatically, use IBuildServer.GetBuildDefinition(teamProject, name) and call CreateBuildRequest.

    The following line sets the command line to get the version you want:
    BuildRequest.CommandLineArguments = "/p:GetVersion=" + OriginalVersionSpec;

    Call QueueBuild(BuildRequest) to actually start the build. 
  2. Wait till the build ends:

    You can create a Timer and check the build status each time - QueuedBuild.Status
    You’ll need to refresh the build object – using - QueuedBuild.Refresh() before.
    Save the finish time for later use.
  3. Get changes only:

    This is the actual incremental build (all previous steps were preparations).
    You do this the same way like the build before (with the /p:GetVersion).
    But this time, you add another parameter: IncrementalBuild

    The full parameter string will look like this: (see the semicolon separator) 

    "/p:IncrementalBuild=true;GetVersion=" + CurrentVersionSpec
  4. Rebuild:

    Queue this build as well, and again wait for it to finish.
  5. Delete old files:

    Iterate through all files recursively in the drop location of the incremental build.
    Delete all files with LastWriteTime older than the finish time of the original build.

So now it seems we have what we wanted.

In the Drop location of the incremental build – only newer files will remain.
All files which weren't changed (or executables which weren’t regenerated due to no code change) – were deleted – leaving new/updated files only.

Or is it?

If you’ll look at the results – you’ll see lots of binaries (DLLs and EXEs) which shouldn’t be there.
No code change was done in their projects.
So why are they here?

Because at least one of their references assemblies has changed…

So we succeed partially:
All file types except assemblies – we have updated files only.
Assemblies – we have all files which had a change somewhere in their dependency tree.

Back to square one?

Solution in part 4...

No comments: