Version management is a required aspect for any DevOps deployment pipeline. For our discussion purposes, we will state that any object that can flow through the delivery pipeline should be versioned. We can define an object as everything that is deployed through the deployment pipeline, examples would include software application code, software configuration files, middleware, middleware configuration files and hardware
configuration files. We also need to understand that any other work that is created in order to manage the deployment pipeline should be considered objects, examples include themes, epics, features, stories, requirements, specification by example, test cases and any required documentation.
So, what exactly is versioning? Versioning is a way to categorize the unique states of software as it is developed and released. We should also understand that there is no universal standard for how to assign versioning, some general logic is using a major release number, minor release number, maintenance release number and build number.
There are a number of common sense reasons why we should version, they include:
Prevent overwriting of changes by others
Allow for root cause analysis of bugs
Determine object version in various environments
Determine who made a change to an object and when it was done
Integration of objects
Lastly, we should identify what objects should be versioned.
Specification by Example/Test cases
Monitor Configuration files