Design and Architecture 101: Branching Strategy for Your Microservices
Rapid Development and deployment of microservices have become essential for organizations by leveraging agile practices and principles. In the microservices world, each team focused on their deliverables instead of waiting for other teams to complete their features before moving to production. This makes teams more independent and agile. To foster this culture efficiently, you need to have a branching strategy where teams focus on developing the features and release them to production without much friction. A well-defined branching strategy simplifies the process of releasing new features or updates to microservices independently, reducing downtime and increasing agility. In this article, I would like to outline the popular branching strategy that helps teams achieve rapid development and deployment.
There are multiple popular strategies available. Git flow and trunk-based development strategies are widely used across organizations. In this Article, we would like to focus on Trunk-based development, which has become the default branching strategy for highly performant teams.
What is a Branching Strategy?
A branching strategy enables you to define how your team uses the code branches to achieve concurrent feature development, improvements, bug fixes, and rapid releases to PROD.
What is trunk-based development?
Every git repository contains a trunk branch implicitly. The trunk branch is also known as the main, master, or mainline branch.
In trunk-based development, developers integrate their changes directly into the trunk (main/master/mainline) branch. The frequency of the integration is very high (multiple times a day).
The primary purpose of trunk-based development is to avoid long-lived branches by merging partial or complete features. This can be achieved by committing the code changes straight to the main branch or by using short-lived branches with an efficient code review process.
The fundamental difference between feature-branches based development and Trunk-based development is that feature-branches based development typically involves multiple developers and takes days or even weeks of work. whereas in trunk-based development, branches typically last no more than a few hours, with many developers merging their individual changes into trunk frequently. In trunk-based development, feature enablement is managed through feature flags.
Key characteristics of Trunk-Based Development:
- Frequent Integration: Developers are encouraged to integrate their code changes into the main or trunk branch as soon as possible. This promotes continuous integration and helps identify and resolve conflicts early.
- Feature Flags: Feature flags enable the developers to merge code into the main branch while keeping certain features hidden until they are ready for release.
- Sort-lived Branches: Developers create a feature branch, work on a specific feature or bug fix, and then merge it back into the main branch quickly.
- Continuous Automated Testing and Integration: Trunk-based development relies heavily on automated testing and continuous integration (CI) practices to ensure that the main branch remains stable and deployable at all times.
Benefits of Trunk-based Development:
- Improved Code Stability: Trunk-based development encourages frequent commits, which leads to smaller and more manageable changes.
- Reduced Merge Complexity: Frequent integration reduces the likelihood of encountering complex and time-consuming merge conflicts because code changes are continuously integrated into the main branch. Large and infrequent merges can introduce bugs that are hard to identify and resolve due to the sheer size of the changes.
- Reduced Technical Debt: Long-lived branches often lead to ‘merge hell’, where the differences between one branch and another are so big that merging becomes a nightmare.
- Streamlined Review Process: Code reviews become more straightforward and frequent. Smaller, more frequent merges are easier to review than large, complex feature branches. This constant feedback loop fosters collaboration and ensures higher code quality.
- Faster Feedback Loop: Developers receive rapid feedback on the impact of their changes on the overall system, allowing for quicker bug identification and resolution.
- Simplified Release Process: Since the main branch is always stable, the process of releasing new versions becomes more straightforward and less error-prone.
Steps to move towards of trunk-based Development
- Develop and Commit code in small batches: Working in small batches reduces the time it takes to get feedback on changes, making it easier to triage and remediate problems. It also increases efficiency and motivation.
- Feature Flags: Feature flags are non-negotiable requirements for trunk-based development. Feature flags allow developers to safely merge incomplete code to the trunk or main branch on a regular basis, thus avoiding merge conflicts and increasing deployment speed. i.e. Feature flags allow developers to deploy incomplete features to production without releasing them to end-users.
- Synchronous code reviews: Teams should move away from asynchronous code reviews to synchronous code reviews. There are instances where asynchronous code reviews take hours or days. By adopting synchronous code reviews, feedback can be shared in minutes or hours.
- Implement comprehensive automated testing: Automated testing is the core of Trunk-based development.
- Have a fast build: The build and test process must complete within minutes.
Ways to measure trunk-based development
Release process in trunk-based development
Below are the typical steps involved in the release process in trunk-based development when releasing a bug-fix.
- Step 1: The developer creates a branch from the main or trunk branch.
- Step 2: The developer completes the fix in the newly created branch.
- Step 3: Automated test cases get executed to ensure the stability of the code.
- Step 4: The developer raises a PR to merge it into the main branch and include a git-tag that identifies the changes. A developer reviews their code and verifies the fix, so they approve the pull request.
- Step 5: Upon approval, the code gets merged into the trunk branch and deployed into the integration environment with the provided tag.
- Step 6: Upon verification in integration environments, code gets moved into the User acceptance environment, where it gets verified by the beta-testing users.
- Step 7: Upon verification in the user acceptance environment, the code gets promoted into the production environment with the given tag.
That’s all for today!
Thank you for taking the time to read this article. I hope you have enjoyed it. If you enjoyed it and would like to stay updated on various technology topics, please consider subscribing for more insightful content.
References:
