IT industry is going through a disruptive evolution where being AGILE and adopting DevOps is the key catalytic agent for accelerating the floor for success. As explained in my earlier DevOps Models blog, they complement each other rather than competing against one another. If Leaders will at the crossroad where in case they need to pick one what should be their pick. There is no right or wrong approaching, it depends on the scenario and dynamics for the program or project. I would personally pick #DevOps over Agile as its supremacy lies in ACCELERATING delivery with RELIABILITY and CONSISTENCY. This path will enable and empower development teams to be more productive and prone to less rework. Does this mean adopting DevOps with any standard will help reap benefits? In this blog, I will focus on importance of one of the standard and best practice around Code branching and merging strategy to get the desired outcome by adopting DevOps. To drive Delivery in much more efficient and eloquent way, everyone should adopt best practices to sustain in the current competitive ecosystem, by keeping cost to minimal. What I am going to cover in this blog are few best Code Branching and Merging (CB&M) trends however they should be fine-tuned depends on the project dynamics.
DevOps spread is across all phases and not limited to Build, Test or Deployment phases alone. Before build phase, DevOps architect should lay down the protocol and clear guidelines how team members during build phase will approach for CB&M. Code Branching enable team to work in parallel whereas Code Merging help teams avoid stepping on each other shoes and enable avoid rework by arresting code override. CB&M strategy should be agnostic to the tool and technology be it TFS, GitHub, CVS or Team forge.
Typical challenges because of lack of proper CB&M strategy:
- Code Merge miseries and mysteries of who override the code.
- Fear of Rewrite because of override.
- Delayed release because of Branch and Merge overheads.
- Quality issues because of improper merging.
- Rework because of deadlock merging.
- Last minute production delays because of wrong code merge and semantic conflict.
- Production branch need to have latest and greatest code, matches production version.
I recall few mitigations we use to define. These mitigations with be a history only with well-defined CB&M strategy.
- We used to have a dedicated code manager to create branches and sync up in the folder and upload on the master branch.
- Merging frequently and smaller rather than rarely and large.
- Rebuild code multiple times in a day to ensure no override.
- Multiple roots to address multiple versions of code.
Moreover, during the journey for each release, we found that our deployment scripts were unverifiable and unreliable to get latest code at any point in time for redeployment. Post code branching and merging mess up it become an endless loop, means as one issue gets uncovered it typically unveil another hidden issue. All this led to delays and infuriating situations when discussion become tense and unmanageable.
Not merging changes into the production line until feature line is feature ready, is called cherry-picking; where teams decide which features to merge in before release.
Here are few best practices to manage Code Branching and Merging strategies:
- Define source control FOLDER correctly:
- Trunk-Based Development (TBD), where all developers commit to one shared branch. Release manager, picks up the committed code from individual developer and finally based on assessment go for final commit on Trunk. Not a good practice for enterprise wide single big release.
- Branch levels, here are various patterns defined to handle Branching and Merging issues.
- Feature wise Branch segregation.
- Centralized Master Branch (Production equivalent).
- Selection sort
- Sort Algorithm.
- Define appropriate Tagging. Tagging help fetch source code based on logically segregation.
- Daily Tagging
- Logical Feature Completion based tagging.
- Product level Tagging.
- Production level Tagging.
- Define Merging strategy. “Merging” is the act of integration into your current working branch from another branch.
- Fast forward Merge. Keep moving and as logical commit happen on one branch, merge into working base branch.
- Rebase with every commit and merge. Every commit by developer merges back to the base and it will be categorized as rebase.
- Avoid last minute merge, without approval from product owner, Scrum master and lead.
- Reverse integration, this approach allows team to merge from the development branch to the main branch. This is more apt for scenarios where logical completion of feature milestone is done.
- Forward integration, this approach allows team to merge from the main branch to a development branch. This is recommended when a child branch is ready to accept the latest code back into its branch from parent branch. Frequent forward integrations into development branches are a best practice.
- Promiscuous Integration, here constant merging between 2 feature lines in play but merge with mainline after completion or big bang merge.
- Upfront capture dependencies.
- Understand what code will get added, modified and removed to define appropriate CB&M strategy.
- Working on two independent modules, team can follow trunk model.
- Working on critical features, define staircase model i.e., branch out for each feature.
- Working on release/sprints with no critical user story, follow hybrid model.
- Frequency and discipline of merging code
- All developers to merge at least daily
- Every developer is given a slot to merge hence higher the frequency of merge better it is to manage.
- Daily merge call or call out:
- Call it a scrum merge.
- Developers call out before merge to mainline stream and in case of no conflict of interest, auto merge.
- Real time merge using CI. Build Virtual environment for each developer with CI delivery pipeline for individual. Go for Gated check-in to avoid last minute rush. It should cover Code Review, Unit testing and Code build checks.
- Big Bang Merge, merge source code between 2 feature lines constantly but merge with production line after full release is ready to deploy.
After defined bundle of best practices, there is a high probability of making successful Code Merge and Branching strategy. Best Practice help get better probability but does not guaranteed error free and challenge free development journey. Here are few branching and Merging models.
Branch by Features – Works well when we have well defined independent scope for each feature or Release. More so for Kanban it is great.
Branching for single sprints team:
Branching for Multiple sprints teams
Branching for Multiple sprints teams with Hotfix branch
It is important for projects to define and laydown Code Branch and Merge strategy so control delivery risks and issues and execute project in controlled manner. With the rise of Distributed Version Control Systems (DVCS) such as git and Mercurial, it is easy to layout CI approach. To ensure things will work properly, they can run builds and tests on individual branch and later commit to the main branch. Feature toggle and Branch Abstraction help make sure features are switched “On” or “Off” despite being half cooked without impacting production line. Pick appropriate Version Control System or tool which aligns with you CB&M strategy, personally I prefer GIT for various reason. GIT is the source code management system that help manage different version of code in parallel without conflict. It emphasis on Data consistency and Integrity, Distributed environment. It helps keep version of code. Occasionally while working on a project one would like to go back to previous version to validate or modify or confirm changes. Git is a very popular open source, code versioning tool that will help one mange Versions of Configurable Items and Artifacts, based on merge strategy. Merge strategy is key for DevOps projects as that will form the base and first step for DevOps.
I hope this blog was helpful and provided much needed CB&M strategies to be successful. It is an important change for people to stay connected while doing development and yet work independently without overriding each other’s code.
Happy Coding using appropriate Code Branching and Merging (CB&M)
Outstanding Outlier: “AG”
Learn Git in a Month of Lunches