Implementation Notes

Using GIT to Upgrade any Web Based Software

In general, software requirements grow every day. A need exists to deploy new releases as well as sub-releases to cater the changing dynamics of daily software usage. Hence a smooth upgradation becomes an ultimate need for all the clients/users. A system is required by which they can easily upgrade their software in a matter of clicking just one button.

While upgrading a software, you might face a lot of hurdles some of which are listed below:

  1. Identifying where we can place our code which manages the stable code version and development/support version
  2. Checking whether new release is available or not on a particular server at a particular time
  3. Managing availability of new releases on test/debug instances
  4. Mechanism for deployment
  5. Quick Upgradation process
    .

Solution

After some R&D, vteams engineer Imran Yousaf developed a solution based on GIT. Reason being that GIT has a vital feature of branches. So, you can push your application’s code on GIT repository and make two branches; first one will be the default branch (Name: Master) and second one will be the development branch. Place your stable code version in Master branch always and later push the enhancements code in development branch. Once a sufficient or stable release is developed, merge the development branch with the master branch. Now you are a step closer to implement the final solution.

In order to develop a simple, robust and controllable upgradation system, a two step based interactive release management system is developed by vteams engineer. The first step has a check box for test instances. If the status of this check box is unchecked, it means the upgradation is only available for test instances. In the second step, you will have two inputs for upgradation manager’s new release number and its short description accordingly.

The request for every single instance calls a web service to the upgradation system with its particular IP address. The system will return the available release number in response to the web service call. The upgrade button will only display if the code’s post version is greater than the pre installed version.

Creating a simple interactive form can save a list of IP addresses in your release management system. Every single IP address saved in this list will be considered as a test/debug instance. The above mentioned web service validates whether the request comes from a valid test/debug instance or not.

If the request comes from a valid test/debug instance, it will call a web service to the upgradation system with its particular IP address. In response, the system will return the available release number. The upgrade button will then be displayed after the verification of code’s post version which should be greater than the pre installed version.

This will override the global upgradation settings and send the availability status or else, it will use the global settings.

For every new installation, make sure that you have GIT access keys. Additionally, custom batch scripts are developed which will trigger automatically when an upgradation thread is invoked. At first, it will use the GIT standard PULL commands to deploy the updated code on the server. Later, a standard SQL file will be executed which will ensure SQL level changes. If everything goes well, it will update the targeted installed version number as required. During this process, the application’s main configuration files will be maintained using GIT‘s “excludefeature.

Conclusion

The upgrade process becomes pretty quick, easy, manageable and controllable by simply managing the code on GIT and creating a proper release/upgradation management system. The developed web service easily identifies whether a new release is available or not and then acts accordingly. Hence in this way, only a single button will perform all the required upgradation on the client server.