Question

I run a rather complex project with several independent applications. These use however a couple of shared components. So I have a source tree looking something like the below.

• My Project
  • Application A
  • Shared1
  • Shared2
  • Application B
  • Application C

All applications have their own MSBuild script that builds the project and all the shared resources it needs. I also run these builds on a CruiseControl controlled continuous integration build server.

When the applications are deployed they are deployed on several servers to distribute load. This means that it’s extremely important to keep track of what build/revision is deployed on each of the different servers (we need to have the current version in the DLL version, for example “1.0.0.68”).

It’s equally important to be able to recreate a revision/build that been built to be able to roll back if something didn’t work out as intended (o yes, that happends …). Today we’re using SourceSafe for source control but that possible to change if we could present good reasons for that (SS it’s actually working ok for us so far).

Another principle that we try to follow is that it’s only code that been build and tested by the integration server that we deploy further.

‘CrusieControl Build Labels’ solution

We had several ideas on solving the above. The first was to have the continuous integration server build and locally deploy the project and test it (it does that now). As you probably know a successful build in CruiseControl generates a build label and I guess we somehow could use that to set the DLL version of our executables (so build label 35 would create a DLL like “1.0.0.35” )? The idea was also to use this build label to label the complete source tree. Then we probably could check out by that label and recreate the build later on.

The reason for labeling the complete tree is to include not only the actual application code (that’s in one place in the source tree) but also all the shared items (that’s in different places in the tree). So a successful build of “Application A” would label to whole tree with label “ApplicationA35” for example.

There might however be an issue when trying to recreate this build and setting the DLL version before deploying as we then don’t have access to the CruiseControl generated build label anymore. If all CrusieControl build labels were unique for all the projects we could use only the number for labeling but that’s not the case (both application A and B could at the same time be on build 35) so we have to include the application name in the label. Hence SourceSafe label “Application35”. How can I then recreate build 34 and set 1.0.0.34 to the DLL version numbers once we built build 35?

‘Revision number’ solution

Someone told me that Subversion for example creates a revision number for the entire source tree on every check in – is this the case? Has SourceSafe something similar? If this is correct the idea is then to grab that revision number when getting latest and build on the CruiseControl server. The revision number could then be used to set the DLL version number (to for example “1.0.0.5678”). I guess we could then get this specific revision for the Subversion if needed and that then would include that application and all the shared items to be able to recreate a specific version from the past. Would that work and could this also be achived using SourceSafe?

Summarize

So the two main requirements are:

1. Be able to track build/revision number of the build and deployed DLL.
2. Be able to rebuild a past revision/build, set the old build/revision number on the executables of that build (to comply with requirement 1).

So how would you solve this? What would be your preferred approach and how would you solve it (or do you have a totally different idea?)? **Pleased give detailed answers. **

Bonus question What are the difference between a revision number and a build number and when would one really need both?

Answer 1

Your scheme is sound and achievable in VSS (although I would suggest you consider an alternative, VSS is really an outdated product).

For your ‘CI’ Build – you would do the Versioning take a look at MSBuild Community Tasks Project which has a ‘Version’ tasks. Typically you will have a ‘Version.txt’ in your source tree and the MSBuild task will increment the ‘Release’ number while the developers control the Major.Minor.Release.Revision numbers (that’s how a client of mine wanted it). You can use revision if you prefer.

You then would have a ‘FileUpdate’ tasks to edit the AssemblyInfo.cs file with that version, and your EXE’s and ‘DLL’s’ will have the desired version.

Finally the VSSLabel task will label all your files appropriately.

For your ‘Rebuild’ Build – you would modify your ‘Get’ to get files from that Label, obviously not execute the ‘Version’ task (as you are SELECTING a version to build) and then the FileUpdate tasks would use that version number.

Bonus question:

These are all ‘how you want to use them’ – I would use build number for, well the build number, that is what I’d increment. If you are using CI you’ll have very many builds – the vast majority with no intention of ever deploying anywhere.

The major and minor are self evident – but revision I’ve always used for a ‘Hotfix’ indicator. I intend to have a ‘1.3’ release – which would in reality be a product with say 1.3.1234.0 version. While working on 1.4 – I find a bug – and need a hot fix as 1.3.2400.1. Then when 1.4 is ready – it would be say 1.4.3500.0