What are your build and release steps? When to increment build numbers?

Question

I am having trouble defining and automating my build process despite simple requirements:

1. Every build should have a unique build number.
2. Every tagged release should be reproducible

What I have:

• A C++, Red Hat Enterprise Linux 5.x, Subversion development environment.
• A build machine ( actually a virtual machine )
• A version.h file with #defines for major, minor, and buildnumber.
• A script for incrementing the version.h buildnumber.
• A rpmbuild spec file that exports the tagged Subversion source, builds, and makes the rpm installer packages.

Questions:

• Assuming multiple developers per project, when should the build number be incremented and version.h file be checked-in? The build machine? Some sort of Subversion hook? Pre-build or post-build?

Thanks in advance for those willing to take the time to share their experience with build processes.

-Ed Linux newbie. Former Windows C++/.NET developer.

Answer 1

Why not modify your build process so that it grabs the latest revision number from the repository and uses that as the build number?

Assuming svn incorporates all of the elements that go into a build of your product, that should give you a unique number per potential differing build, and make it easy to match up what the state of the codebase was at the time of building. If there are other elements that can vary with time, you could add another item concatenated to the revision number - perhaps a date/time value.

You'll never have to worry about manually incrementing it, because each time a developer commits they'll increment the revision number automatically.

Answer 2

Don't store the build number directly in your file, use the subversion revision number (or some other monotonically-increasing value, like the date/time) as your build identifier. In the past, I've used the value of date -u +"%Y%m%d%H%M%S", as we were using CVS not SVN.

Answer 3

We have teams of upto 40+ developers adding code to our product. Each developer submits their change to a central location for the product. This forms an ordered list of code submissions. Scripts then take each submission and integrates it into a test build based on the last released configuration and any previous submitted changes in the current round. Unit tests are run after each code submission is compiled, also any acceptance tests added in the current round are also run. At the end of each day unit tests and regression tests are run against the evolving build.

Twice a week the list of submitted code changes is wrapped up and that becomes the a new released configuration of the product and the codebase is updated.