Develop Multi-Value Applications With Modern Source Code Managers

Legacy Version Control Tools for Multi-Value Application Development

The legacy version control tools are specific to the multi-value programming controls BP libraries and DICT files on the PICK operating system environment. Checking out code from a BP library is usually known as the locking process because files get locked by the developer for the time of their code change request. This leads to the sequencing of processing code change requests because the files that the developer intends to modify are locked and copied to the development stage.

Let’s use an example to well explain this concept. Let’s consider five staging levels, such as development, QA, UAT, pre-production, and production environments. The developer is required to move their code changes through these staging environments. The developer checks out the elements from the production BP library to the development BP library and begins to work on modifying the elements.

If the developer works in their own development BP library, then they continue to add elements to the library and compile, catalog, and test their changes. Once satisfied with the code changes and ready to move their code to the next stage level, they need to run an audit check to see if anyone else has changed anything related to their elements of BP library, such as BP programs and other dependencies like INCLUDE and COMMON elements and DICT ITEMS that has been included. If other changes have already been promoted, they must then get those changes into their elements, recompile, catalog, and test before moving forward to the next stages.

If the developer works in the development BP library, then all other changes in that development level are automatically added to their code changes. When the developer is ready to move forward with their code changes, they must check to make sure any changes they may have picked up are also ready to move forward. If not, then they must manually remove the other code changes, recompile, catalog, and then retest to promote to the next stage levels. 

As you can see from the above case, there are many manual tasks and reviews that must be performed. A lot of times, rework is required because of late decisions about what functionalities will move forward and what will not. Since a lot of manual work is involved, there’s a great chance of missing elements to move to the next stage levels.

Modern Source Code Managers for Multi-Value Application Development

Modern source code managers allow parallel development on the same elements of BP Library without locking. There are many software configuration management solutions available in distributed software development category. Git is one of the standard modern source code managers. Git implements the functionality to clone, branch, and commit, as well as push and merge changes to the original source code repository. The image below shows the various steps a developer performs to edit code and share it with their team.

1. The application origin repository is the source of truth. The developer clones the app origin repo to their local machine with its history and all the branches.
2. The developer creates a branch on their local repo and works on the required code changes for feature1. The branch will track the code changes of elements of the BP library. 
3. Commit the code changes of feature1 to the local repository.
4. Push the code changes of the feature1 branch from their local repo and merge them with the origin master branch. 

Developers in the team can work on these individual features in isolation using feature branches for current and future releases. To avoid regression, the current release changes should be merged with the future release branch, this way parallel development can be achieved without locking the elements of the BP library using branching.

Conclusion

For multi-value application development, migrating to modern source code managers like Git allows you to create branches, which will help development teams to work on several releases in parallel without locking the elements of BP library and DICT items. It provides great flexibility between releases of hotfixes and it avoids manual work. The CI/CD goal can be achieved easily with modern source code managers. It avoids the high licensing costs of legacy version control tools per user.