Version control system is one of the major components of continuous delivery. It enhances speed, integrity & adds a lot of value to the whole development process. In our project, we are using GIT & GitHub developed originally by the famous Linus Torvalds for the Linux Kernel. Though it provides a lot of flexibility, we need to fine tune the process catering to our project mainly because of various releases for different customers. This becomes pretty evident considering the fact that ours is a SaaS based model.

Development Flow

At the start of every sprint, each developer will create a branch for the ticket assigned to him/her called as feature branch. At the end of the day, they are supposed to commit all the work done by them in their feature branch. We have implemented Continuous Integration using Jenkins which basically takes this feature branch & merges it with the common development branch. In addition to this, we have automated the unit test cases to ensure stability of this particular build. In order to ensure further code compliance & minimize/identify errors, we have integrated Sonar. Both, Sonar & automated unit test cases run along with the merge.

In case, this build process fails at any point of time, a mail is triggered to all the stakeholders & immediate action will be taken next morning to fix the issue. However, if everything works as expected, then the feature branch is merged along with the development branch.

There is one more Continuous Integration job which basically merges all the changes done in the development branch to the QA branch so that the testing team can start their testing on the completed items. This one is a straight merge wherein for any failure mails will be triggered to all the stakeholders.

From here on, some manual intervention is required as we advance towards planning production release/pre-release & it depends on the features planned for the release. The features (can be called as tickets of the sprint) planned for the release are merged from QA branch to the pre-release branch manually. The pre-release branch is tested on stage instances thoroughly to identify any bugs/defects. Finally, the feature planned for the production release is deployed to the production instance once again manually.

This whole process of deployment/branching is depicted in the diagram below.

Cloud-based Development Enables Ticket-based Code and Release Management Image 1

Fig 1. – Timeline of branching model.

Hot Fix Process

Sometimes, in order to fix a critical production bug or to deploy a feature, we might have work on a hot fix. This is a different scenario & the process is a bit different from the above. The bug is fixed directly in the pre-release branch & then it’s merged manually to production. The process doesn’t ends here; it is reversed & merged back to all other branches like QA, Development. Moreover, a feature branch is also created for this bug.Webinar