Tags

, , ,

A basic way of putting version information may be using source code embedded defines.

versioning - basic version

These may be semantically correct if you follow something like, http://semver.org/, but manual setting will eventually lead to some misshapen. As a step forward in our DevOps journey, we want to enhance traceability in our deployments. Therefore, a better way will be passing automatic generated version information with compile time macros. Now the point will be what to pass. A good candidate may be one of Jenkins several environment variables.

versioning - jenkins environment variables

As an example BUILD_NUMBER is directly correlated with deployment, which makes it a perfect candidate in operations point of view. However, in DevOps developers are also expected to be at front line in incident handling. Unlike some other source control tools, Git does not have an auto incrementing number for commits. This is due to distributed architecture of Git. In distributed systems keeping consistency for a unique incrementing number will be heavy weight. But, if you are able to satisfy with uniqueness and forget the somewhat traditional auto incrementing property, git commit id’s will do the job.

versioning - git commit id

Hoping that a mix of jenkins build number with git commit id will please everyone in the team, here is an initial try sample from our windows build;

jenkins side

versioning - jenkins version

make batch

versioning - makebat

code side

versioning - modified version

and sample result. Embedding these to generated logs will do basic traceability.

versioning - result

Advertisements