Stop! Show me your build number!
Having a lot of these installation kits around can get us in trouble when we have teams of testers and coders working in parallel because when the test team finds a problem they will fill a bug report and send it back to the development team. But in complicated problems it is important to be able to reproduce the bug in the context it happened and exactly with the code that caused the bug. This means we need something, a number or label, to uniquely identify the build that produced the installation kit that was used when the bug manifested itself.
The answer is “the build number”. We need to maintain a build number and this build number has to allow us to identify and ideally to rebuild the deliverable, identical to the one used when the bug happened.
During the years I’ve seen a lot of solutions to this issue. But the question is what are the requirements and what is the best solution.
What I want is to be able to identify with a single label the status of my code repository at the moment the build was done. This will ensure that I can redo the build and get the same exact result from the build, the same deliverable. This is important because the result of a build process can be rather big (installation kits for lots of platforms for example) and I don’t want to have somebody work full time on managing and backing up these build results since they are most likely to be thrown away when the testing is done and also because during some specific periods - like around deadlines - in the life cycle of a product they tend to be created more than once a day.
As solutions for the build numbers I have seen:
- a number that increments with every build and it is stored somewhere in the code repository
- a tag maintained by the code repository itself when a file is checked in
- a time stamp that is not actually stored anywhere but just recorded at build time
While all of them somehow solve the issue I have something to dislike about each of them.
The solutions that maintain a build number in the code repository require the build process to modify and check in a file. This leads to a very long artificial history for that file. Also philosophically speaking I don’t like the build process to touch the code repository. It also requires special handling of the local builds developers like to make on their machines since we don’t want these local builds to modify the build number.
The solution based on the time stamp suffers from the fact that various machines in the network might not have exactly the same time and from the fact that the time stamp is generated on the build machine not on the code repository machine.
Of course this is not a fundamental or very interesting problem but I would still like to find out what people use out there. What do you think the best solution is and why?
So… Show me your build number! …Please 
Subversion gives each revision a unique ID. The advantage is that because it’s already a property of the code, there’s no need to check in again to update the number, your build system can just insert it into the build process.
The advantage here is that with no extra information, you can plug the build number directly into svn checkout to get the precise version of your code that was built.
@Charles Miller
Yes you are right
but unfortunately most of the projects are already using some sort of code repository that is not SVN. Subversion solves this in a very elegant way but what about the projects who cannot, for various reasons, afford to make the jump?
Ouch.. Have you ever heard about Maven? It answers all your questions and dozzens more..
However it does touch your repository. ..Philosophy and Pragmatism never play well together…
@Robert Sayfullin
Yes I did hear about Maven but I cannot say I am a fan. I am sometimes reluctant to use tools that answer questions I didn’t ask. On this front I prefer ANT. But in the end I think it is a matter of taste.
AccuRev has a stream concept (like branches but easier to manipulate and manage) and each stream has history. We use the history of a particular stream (say ‘release4.x’) and get the most recent change. Using the timestamp of this change (or the transaction number) allows you to reproduce the build each time as well as compare two releases and see exactly what code changed.
Granted this falls into the same comments, I am relying on the source control as my stamp. This seems like the most reliable… relying on the tool that did the build (like maven or cruisecontrol) means you can end up with two builds that have exactly the same code, but no reliable way to make that determination.
@JSherwood
Thank you for the link. I don’t know much about AccuRev but the streams look like a smart concept. On this other hand this detail alone is not enough to make a switch from CVS. As Charles Miller said above SVN also has a good way of solving this. Also SVN is the natural upgrade path from CVS. But I will definitely look a bit into AccuRev to learn something about its concepts. Knowledge might come handy at some point in the future.
I cannot speak to SVN alternatives, but if you are using SVN, you can tie the SVN update command into your build using the Maven 2 VCS plugin. That sets a variable which you can insert into a properties file so that it can be rendered at some place in the UI. As another approach, Hudson is a continue integration server that keeps track of build numbers for each build it executes. It knows exactly which version of the VCS tree it took so that you should be able to trace back bugs. Of course, depending on the capabilities of the VCS system, your milage may vary.