1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Continuous Integration Best Practice: Including a Version Number in Builds

windchill features best plm software
Written by SPK Blog Post
Published on September 9, 2014

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. An internal build number can also be correlated with an externally publicized release number. The number on the DVD says version 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:

Ronald Ross
Software Engineering Specialist
SPK and Associates

Latest White Papers

2023 Global DevSecOps Report

2023 Global DevSecOps Report

Productivity and efficiency are top priorities for many organizations, as seen from the 2023 Global DevSecOps Report. It is no coincidence these two priorities are also the driving forces of DevOps. Explore how businesses utilized DevOps practices to achieve success...

Related Resources

Exploring the Powerful Features of Creo AAX for Complex Assemblies

Exploring the Powerful Features of Creo AAX for Complex Assemblies

Manufacturing can be an intricate and time-consuming process. It is important to utilize the proper software for successful execution, especially when working with complex assemblies. Complex assemblies typically have a high part count of diverse components and...