mPharma Engineering Code Release Culture
As we continue to grow as an engineering team it has become necessary to document our code release process. We continuously seek to improve our release culture and to make sure we limit the number of bugs or low-quality code that ends up in production.
I will begin by taking you through the process of building a feature into a backend service.
We currently maintain a single master branch for our backend services and a two-branch approach for our frontend applications namely test and production to represent the different environments we run workloads on.
Find an image of our current git branching strategy below:
How to add a feature to a service (Backend application)
A backend engineer would branch off the master branch and then create a feature branch that would hold all the code for that feature. After completing the feature and testing on their local machine, they proceed to create a merge request and tag another backend engineer (in a situation where the engineer tagged is not the service owner, you would be required to tag the service owner) to review. In a situation where the reviewer requests for changes, they notify the owner of the specific merge request to make changes to the code.
After all comments on a review have been resolved, the engineer proceeds to merge that particular merge request into the master branch. Any code merged into the master branch automatically triggers our CI/CD process which runs a couple of quality gate processes(Sonarqube for static code analysis, Unit Test for making sure no breaking change has been introduced for old and new code, Code Coverage to measure the degree to which tests written cover the source code) and deploys the new feature into our test environment once all the process pass.
We then move to the next stage of our release process which is tagging the Quality Assurance(QA) Engineer to review your feature. The role of the QA Engineer is to make sure the feature meets all the product requirements defined by the product manager. If the QA Engineer is satisfied with the feature as against the requirements stated by the PM, he/she considers that task as Done.
Once a task is marked as Done the engineer that built the specific feature has the sole responsibility of manually deploying the feature into production.
