Sharing IT Best Practices with youSharing IT Best Practices with you
Version management is an essential aspect of the DevOps deployment pipeline. Many DevOps teams realize too late that every object needs to have a (correct) version. This article gives a list of objects to be versioned and explains why to version these objects.
In this article, an object is defined as everything that is deployed through the deployment pipeline, for example software products, software configuration files, middleware, middleware configuration files, hardware configuration files, et cetera. In addition, all the objects that are created in order to manage the deployment pipeline are considered objects, for examples themes, epics, features, stories, requirements, test cases, CI’s, S-CI’s, documents et cetera.
Software versioning is a way to categorize the unique states of software as it is developed and released.
There is no universal version number logic. However, the most common used one is:
Version (W.X.Y.Z.)
[Wiki]: A Version Control System is a computer program or a collection of programs that allow you to manage the changes in documents, programs, or other information stored in computer files. A VCS is most used in software development so that multiple people can make changes to the same files. Changes are usually indicated by a code, the “revision number” or “revision level”. Each change will be linked to a timestamp and to the person who made the change. Changes can be compared, restored and sometimes merged. A version management system is usually a separate program, but it is also built into some software such as word processors (such as Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (such as OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in different CMS systems. It is also a feature of wiki software, so changes can always be reversed, for example in vandalism.
Version management is the process that manages the changes to objects.
An important start using version management is to determine the version strategy. This strategy is about making important choices. These choices can be made by answering the following questions:
Based on this strategy the correct tooling can be selected.
Within the deployment pipeline of DevOps each object must have an Identification (ID) and a version. The business case of version management is based on the following risks:
To eliminate these risks versioning management supports the DevOps teams with
Table 1 gives an overview of objects that are related to a DevOps phase.
| Phase | Versioned Objects | Tooling |
| Plan | Theme, Epic, Feature | Requirement management tool |
| Code | S-CI, Baseline, datamodel | Software management tool Data modelling tool |
| Build | BuildID | Build server tool |
| Test | Test data, test case, test set, test run | Test management test automation tool |
| Released | Release Notes, deployment script, configuration file | Deployment tool |
| Operate | Data file, protocol | Data file management tool |
| Monitor | Monitor Configuration file | Monitor systems |
Table 1, Objects per DevOps phase that needs to be versioned
| Versioned Objects | Benefits of versioning |
| Theme, Epic, Feature | The themes, epics and features are the place holders for the requirements. This means that changing one of these objects also might include that all other objects in the deployment pipeline should be changed (see article #09). |
| S-CI
| Continuous Integration demands a high frequency of checking-out and checking-in. Each time a version should be generated by the VCS in order to keep track on the changes. This also means that in case of a loss of a source code of a serious error that not can be solved, the prior version is still there. |
| Data model | The information in an application or report has to be defined well. The information that is received, transformed and send /exported by the application changes over time. So, does the data model. The versioning of the data model is one of the most important aspects of data quality management. |
| Baseline | A baseline consists of S-CI’s of a certain version. Test cases are used by the DevOps team to check whether or not all those S-CI are working fine together. However, if after testing the wrong version of the S-CI is used then further in the deployment pipeline errors will occur. So, the VCS should keep track of the changes to the baseline in terms of S-CI’s and their version. |
| BuildID | the compiled objects are normally not versioned, but they are created by using a unique version of the software. So, the buildID should refer to the version of the baseline that is used. |
| Test case | Test cases are used to check the adherence to the requirement. To perform a test, the object to be tested has to be known as well. As soon as the requirement or the object get a new version, the test cases may become invalid. So, the test cases should be adjusted where needed. Thus, test cases must have a version as well. Certainly, in case of regression testing. If test cases always are used in the same test set, then the versioning can be administered on the test set level. |
| Test data | Test cases make use of test data. Normally test cases do create and delete their own test data. However, a standard set of data is most of the time also needed. This test data set has to be versioned in order to check that all test cases using this set are still working properly. |
| Test run | A test run makes use of a test set of a certain version. All defects should refer to the test set version that is used. |
| Configuration file | Not only software but also all other objects like database management systems, operating systems, firewalls et cetera need configuration settings. These settings are about paths, database names, message queues etc. Each environment may require different settings. So the objects and the configuration files are kept separate. After the object is deployed then the correct version of the correct configuration files is used to configure the object.So versioning of configuration files is very important to keep the deployment pipeline running correctly. |
| Deployment script | There are many deployment scripts needed to deploy a complete environment. The versioning of these scripts is needed in order to match them with the versions of the configuration files. |
| Release Notes | Release notes are updated for each release. It is important to keep this in sync with the version of the application the is released. |
| Data file | Many applications do generate output files that are used by other applications to process transactions. It is very important to version the format of these files. Also, the version of the application that created the file of the file is important information to solve incident |
| Protocol | The communication between applications is performed based on protocols. These protocols need to be versioned. Many applications also do check for the protocol version that is used by other application in order to agree on the communication session or not. |
| Monitor Configuration file | The monitor provisioning must be configured correctly in order to detect events. By using a versioning of the monitor configuration this can be safeguarded. |
Table 2, A list of objects that needs to be versioned plus the reason for versioning.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Acceptatiecriteria, ISBN: 9789071501784
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.