TFS Build and Local Build

Question

I have been tasked with updating the companies outdated build process. It is all done in batch and perl scripts. The current build process is:

1. Schedule a build through a web interface.
2. Build server takes the build process off the queue.
3. Build server checks out all of the files from the TFS source control.
4. Build server runs a couple of code injection scripts that modify the source before the build.
5. Build server updates versions and signs the code.
6. Build server uses visual studio to compile the projects.
7. After that is finished the build server zips up the output and drops it in a network share location.

The real difficult part is the code injection scripts. They are 3 perl scripts that modify a lot of code. They are also very machine dependent in the way they were designed. (So I can't just drop them in the build process without a lot of modification)

My end goal is to be able to run the build process on local dev machines and also have CI running on the TFS server.

In my searching it seems that there is no way to emulate a TFS Build on a local machine. So is my only option to use pre-/post-build command line scripts in my cs.proj files? Or is there a better way to do complex builds on the local machine and run the same builds on the TFS?

I have seen Using TFS build definitions on a local machine, but that seems a bit hacky to me. I guess it wouldn't be a horrible solution if there isn't a better one.

Answer 1

I have tried to do something similar in the past myself. Unfortunately, there isn't a good way to go about it because of everything that the TFS Build Workflow requires. What I found was that there are basically 2 ways to go about it.

1. Create a MSBuild script that will run on both Server and Local
2. Create a MSBuild script for local and Custom Activity for Server.

If you are intent or have a requirement that you be able to reproduce the build exactly on both the developer machine and the build server, then I would opt for #1. Otherwise I would go with #2. The second option is nice because then you can play within the TFS workflow for doing the main builds which provides you with many objects that you would need as well as giving you a nice place to configure settings without having to check out/in files to change how the build occurs.

For either method you would most likely have to modify your Perl scripts to take in parameters to account for any customization you have to do between systems. Then you can have the user either pass these in or default them in the MSBuild script for local builds and set them up as parameters in the TFS Build Workflow. Thus they can be easily modified if needed. Regardless of the method though, the only good way to do it is to standardize on how things need to be setup on the developer machines and the build server so that you don't have to provide the customization as much.

If you do opt for the first option then you can use the Legacy build configuration for TFS build which supports using a MSBuild script for everything and then you can share the script between both developers and the build server but if someone accidentally changes this script then it does run the risk of breaking the build.