Software Release Management 2.0
Before starting, let me give you a small piece of information about the company and the structure. Al Tayer Group is a holding company established in 1979. It operates in 6 countries in the Middle East, with over 200 stores in multiple markets. Well-known fashion brands like Gucci are part of Al Tayer’s retail business. In addition, the group has started launching e-commerce sites since 2016 with Ounass and followed by Nisnass in 2018.
Ounass, the definitive home of luxury, is the Middle East’s first premier luxury website offering the world’s most exclusive brands in an editorial environment that is globally relevant but locally-led.
Nisnass is the latest e-commerce launch from Al Tayer Group, one that’s targeted at digitally savvy shoppers of the “now” generation.
Company Websites and Service Structure
Full-Stack Developers are responsible for the Ounass and Nisnass websites including FE, BE and orchestration layer and microservices. Magento developers are responsible for the E-commerce platform.
Task Management Process
The task management process consists of 5 steps — Product, Develop, Test Release, Test and Production Release.
Branching Strategy
The branching strategy is one of the most important aspect of release management. In 2016, when we started developing the websites, we had a similar structure to Trunk-based development as,
- work on master (everybody has access to push master)
- merge it to beta (everybody has access to push beta)
- merge it to prod after successful testing.
Problems of this strategy were:
- The test environment was stuck because of bugs, we were not able to push any features to production before fixing those bugs. So, if we have 2 different features on beta, these will wait for one other to be fixed or we would need to do cherry-pick.
- All developers would use the “master” as a development branch. When a defaulted code was pushed to the master branch, it might affect other developers and block them until we find out how to fix the problem.
- Everybody was able to push codes to beta, therefore beta was never stable.
As a result, we decided to have a new branching strategy and create some policies or rules that would cover all the problematic steps. We had two different websites that used the same orchestration layer. Also, we had to find a way not to break one of the websites when we do deployment for the other website while we deploy something to the orchestration layer.
Branching/Release Strategy 2.0:
So, after long meetings, we decided to go with a more feature-based branch structure. We agreed to have a feature branch for each development we start. All feature branches would be created from the master branch. If more than one developer works on the same feature, we will create one main branch named JIRA-ID and sub-branches which will be merged to the main branch after development is completed.
After development is completed for the main future branch, it will be merged to the “next” branch which is same as the production.
Next step after we merge all feature branches to the “next”, we can merge that to “beta”. If the release manager pushes anything to beta, deployment to the test environment will start automatically. Release managers should update related JIRA tasks after beta release with a test tag.
Beta is tested and all tasks are ready for production, in this step release manager will push all the beta changes to the “prod” branch. Create a git tag and add it to tickets. Then if everything is okay on the website, merge prod changes to master. When we create a new next branch, we need to reset it to the latest master.
Steps until here were for the Frontend/Backend repositories, but we have one more problem to fix. We have an orchestration layer that is used by both website repositories. Using the same next, beta and prod branch is tricky for us. Websites should not break each other when they deploy something to production about their features.
So, we decided to use different next, beta and prod branch by brands with brand prefixes. After the test of the production code for one of the brands and merging it to master, the brand release manager informs other brand’s release manager to pull the latest changes from master and test it on the second brand’s beta.
Release Strategy Steps and Rules
- Create a feature branch from “master”. (Jira Status: In Development)
- Push changes to feature branch and create Merge Request. (Jira Status: In Code Review)
- Merge it into the “next” branch after Code Review. (Jira Status: Ready for Beta)
- Merge next branch changes to the “beta” when QA Team is ready to test. (Jira Status: Ready to Test)
- Merge beta branch changes to the “prod” when the test is completed. (Jira Status: Deployed to Production)
- Create a release tag (git tag) and share it with QA. (eg. r20200320T123000)
- If we don’t have any problem with production, merge prod changes to “master”. (Jira Status: Closed)
- Update the ticket when one the following is done:
A ticket is merged to beta: Add environment tag (eg. nis-beta)
A ticket is removed from the beta: Remove environment tag
A ticket is merged to prod: Add release tag (eg. r20200320T123000) - No new merges after 4 PM every day, with the exception of defects & regressions.
- If there’s a problem in the beta environment and QA is unable to identify the reason, they will inform the release manager to find the root cause of the problem. Never create a branch from beta or next. It should be from a feature branch or master.
Key Benefits
- Managing more than one feature branch at the same time.
- Deploying easily to more than one environment.
- Releasing development branches quickly and with fewer conflicts.
- Not blocking the QA Team when we take deployments.
- Capability to test different branches without merging to master.
- Deploying separated repositories by using the same structure.
- Giving visibility when we deploy something to environments.
Release Manager Role
The release manager has an important role as that is the main person who can unblock the developers and the QA team. With collaboration between the project and the QA teams, the release manager merges the ready tickets to test and production environments.
Release managers who are part of the tech team, are specific and unique to every chapter. Each brand and chapter have separated release managers like one for the Full-Stack team and one for the Magento team.
To sum up, the responsibilities of the Release Manager are:
- Release planning with Project Team.
- Configuring releases with related future and fix branches.
- Deployment of ready tickets related to the release plan.
- Code quality and size check on each release step.
- Help QA Team for blockers.
Supporting The Release Management Process with a Script
If you are interested to learn about the Automation of Release Management Process, you can read my post on the following link:
References
https://www.aha.io/roadmapping/guide/release-management
http://www.bu.edu/tech/files/2012/06/RM-Quick-Refv3.pdf
https://cloud.google.com/solutions/devops/devops-tech-trunk-based-development
