Best build process solution to manage build versions

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

I need more space than responding as comments directly allows...

Thanks! Good answer! What would be the difference, what would be better solving this using SubVersion for example?Richard Hallgren (15 hours ago)

The problems with VSS have nothing to do with this example (although the "Labeling" feature I believe is implemented inefficiently...)

Here are a few of the issues with VSS

1) Branching is basically impossible 2) Shared checkout is generally not used (I know of a few people who have had success with it) 3) performance is very poor - it is exteremly "chatty" 4) unless you have a very small repository - it is completely unreliable, to the point for most shops it's a ticking timebomb.

For 4 - the problem is that VSS is implemented by the entire repository being represented as "flat files" in the file system. When the repository gets over a certain size (I believe 4GB but I'm not confident in that figure) you get a chance for "corruption". As the size increases the chances of corruption grow until it becomes an almost certainty.

So take a look at your repository size - and if you are getting into the Gigabytes - I'd strongly recommend you begin planning on replacing VSS.

Regardless - a google of "VSS Sucks" gives 30K hits... I think if you did start using an alterantive - you will realize it's well worth the effort.