Oops…! It's an era of Agile-Scrum-Sprint.
This is still okay but What about Monthly Releases and delivering various features using Jenkins as continuous integration (CI) tool?
Nowadays single team is working on different modules and various stories around them.
Working as a Technical Leader/Development Manager one may face difficulties in delivering various features in the same release.
This may be due to below considerable points:
- All features and issues are getting fixed on a single branch.
- Late identification of Technical Feasibility.
- Third Party dependency (UI/UX/Core Team).
- DEV/QA Team runtime bandwidth.
- Last moment urgent Production Bugs.
As a general practice and to avoid branch management, traditional teams have only one branch per release.
Changes done in that branch are targeting:
- New Feature/Story
- Bug Fixes
- Performance Fixes.
If any of the story/performance fixes can cause a delay that will lead to impacting timelines for other stories.
- This has to consider the overall effort to put in the last moment to roll back those changes.
- Again this leads to compromising the quality of the deliverable.
- Dev team gets less time to analyze the impact-areas.
- QA Team will get less time to verify the changes done.
- Marginally less/no time for regression.
- *Most importantly Handling pressure from upper management and criticism.
Below diagram gives pictorial representation of Teams' changes in Single Branch:
Let's try to analyze the scenario – Time for WH Questions!
· What Team is doing?
o Creating a Single branch from the Production/Stable branch for a release.
o Making changes for Bug fixes, Performance issue fixes, and Story Development in a Single Branch.
· Why Team is doing changes in the Single Branch?
o Avoid extra branch management.
o Availability of QA Environments.
o Avoid Migration/Regression efforts on every branch.
· How is it impacting?
o Anything gets delayed entire feature suit is getting delayed for a release.
o Timelines are getting missed.
o Last moment extra efforts without deeper analysis.
o Compromising Quality of deliverables due to lesser Testing Time.
It's time to change the way changes are getting pushed in Single Branch and come up with multiple branching strategies.
Let's summarize what needs to be achieved & HOW?
- Need to have Feature-Shelf so that based on decision any time any Merge-Ready Feature can be released in production with good quality.
- Want to have no pressure from management for technical items.
· No impact of any Story development/release plan decision on other Story.
o How? à Separate Branch for each Story and Performance Fixes.
· Every Story branch should have the latest issues fixed in this release.
o How? à Separate Branch for Bug Fixes name it : team_fixes.
§ Create Story Branch from team_fixes branch and keep merging on regular basis.
· Where to push a fix for Story Defects?
o Every fix for Story Defect must be pushed in the respective team_story_x branch only.
· Single Environment for QA to validate all these changes.
o How? à Create team_story branch where all story (team_fixes, team_story_1…. team_story_N) and performance(team_perf) branches are merged on daily basis if those are stable. J
o Migration and Regression will be done on single environment. (Same Target as using Single Branch Previously)
· Jenkins/CI:
o Run Compile & Test Execution job on individual branch.
o If Selenium tests written have single Job for team_story branch.
Please refer below diagram for suggested Branching Strategy.
Please feel free to comment to this article for any suggestion and queries.
No comments:
Post a Comment