This is a corollary of the Codeline Organization post.
Where do I place the build script are in the Version Control? My opinion is to store them under the trunk or branch, i.e. inside the codeline. Please note that your actual branching structure is ininfluent.
I know, the MSBuild Project File Creation Wizard places them in the TeamBuildTypes folder just under the root, but I think this is more an hindrance than an help.
The advantages of this approach are:
- when you branch to freeze a release, you keep the build script together with the code — in case you need to recompile those bits, you will be sure the build scripts haven’t inadvertently changed;
- you may have scripts branch aware — they show a different behavior, if they are run in a developer or in a release branch;
- you may work on a isolated branch to change the build script.
Disadvantages? Sure, there are:
- first and foremost, your build scripts have to be branch independent (or branch aware) — they cannot have full paths but only relative paths;
- you need to manage merges as needed.
I touched a point that needs to delve into.
Branch aware build scripts
I think that some actions inside a build script needs to be aware if you are in a developer or in a release branch.
For example, you may want some comment into an executable to distinguish how it has been built, using AssemblyConfiguration or AssemblyInformationalVersion values. Another thing you want to change is the version number: in a developer build you don’t need to touch the numbers — or even zero them all; while in a release build you want unique and possibly contiguous version numbers.
This can be achieved in TFS in two ways:
- the build script changes behavior by the name of the build definition
- the script computes the version control path in which it resides.
I prefer the second approach, as I may have more definitions than branches, or more precisely then branch containers.
Hope this may spawn some comments.