Building software source code is an integral part of continuous integration and is the backbone of developing useful software. By “build”, I mean that the source code needs to be received as input to a compiler and a binary of some sort emitted for the software to become useful. So what are we getting to? Binaries. This is how we get them, but how are they best handled? How can we identify and distinguish one string of ones and zeros from the next one?
One continuous integration best practice in dealing with binaries is to include something human readable in all the machine readable digits. This can be a version number, a date stamp, or both. And more than just including a build number, the build number should change for each build, preferably by increasing in some predictable way.
Here are some reasons why this is desirable as part of your software lifecycle:
- Including a version number marks the binary as something serious, namely that it is destined for testing, and perhaps for eventual customer use. The reason we are building the software is because something has changed, and also presumably for the reasons mentioned — we have a purpose such as testing or releasing the binary for use.
- Marking a binary allows us to determine what we are looking at, since binaries are, by their very nature, machine readable, but human unreadable. Having an identifier in the binary allows us to distinguish one binary from another. While the content of binaries are of course different from each other, something more is needed to enable a human looking at a binary to distinguish one version from another of the same code base.
- Having a way to distinguish which binary version you are working with allows you to record defects or other issues that are particular to each specific version of the code. And having that version number allows you to refer back to the source code which comprises the binary, see the next point.
- Using a version number vs. a date stamp is perhaps a better way to synchronize a built binary with the source code from which it came. In the source control system, either a change set number or a label can be correlated to the build number, thus tying the two together. And knowing which source files have been used to create the binary is invaluable to investigating any issues encountered with the binary.
- An internal build number can also be correlated with an externally publicized release number. The number on the DVD says version 1.4.0.54. The internal number in the binary should match this, else there is a problem with the release process!
Perhaps this isn’t a complete list, but I think this is a fair summary of why adding build numbers in a binary is a continuous integration best practice. For my next blog post, I will provide an example of how to use Jenkins and a related plugin to create and pass a build number to the continuous integration build process. Stay tuned!
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
Ronald Ross
Software Engineering Specialist
SPK and Associates
