Published January 22, 2023
by Doug Klugh
The Need for Speed
Should your software development team use feature branches to isolate changes from each developer or leverage Trunk-Based Development (TBD) to integrate small batches of code frequently as part of everyone’s daily work? In other words, should you optimize for individual productivity or team productivity? If you want to deliver software faster and with higher quality, the answer should be obvious. TBD enables continuous integration, simplifies code merges, and shortens the feedback cycle through frequent automated testing. Feature branching promotes Continuous Isolation while TBD promotes Continuous Integration. Although TBD is a new approach for many teams, it is a key component to achieving frequent and continuous delivery.
Feature branching is an effective method for optimizing individual productivity by isolating each developer's work from the rest of the team. Each developer works independently without other team members stepping on their toes (or on their code). However, when it comes time to merge that branch with everyone else's code, it can be difficult — even unmanageable at times. When that happens, developers tend to do it less often — further compounding the problem. Infrequent code merges also lengthen the feedback cycle and impede collaboration within the team. This fosters nothing more than a group of individuals focusing on their own isolated piece.
Trunk-Based Development optimizes team productivity by integrating everyone's changes frequently, shifting the feedback loop earlier in the development lifecycle. With continuous integration, code merges are much smaller and, hence, much easier. Frequent integration enables us to Shift Left (i.e., fail fast) by catching merge conflicts and test failures for the entire codebase much earlier than with feature branches.
« Without automated testing, continuous integration is the fastest way to get a big pile of junk that never compiles or runs correctly. »
- Gary Gruver, Director of Engineering, HP LaserJet Firmware Division
Following are some fundamental practices that facilitate Trunk-Based Development:
Feature toggles are a necessity for Trunk-Based Development. They enable developers to integrate incomplete code with production code by encapsulating features and infrastructure changes inside switchable software modules. These switches can be used to easily turn features on or off within any environment. This will ensure that incomplete features will not break existing functionality and will not be accessible to users until they are ready for primetime.
Unit tests are also a must-have for Trunk-Based Development. It is critical that all code changes are verified prior to integrating them with production code. Not only should the code be verified locally before merging to the trunk, but unit tests should also compose most of the Commit Tests, serving as the entry gate to the deployment pipeline.
Automated acceptance tests will help to validate the entire system to ensure that new functionality isn't breaking the production build. And because developers are integrating small batches of code, most failures will be quick to locate and easy to fix. These tests will maintain confidence that the software is fulfilling its purpose, while guarding against wide-spread changes to the system.
Related Posts
assistant Development Tip
Trunk-Based Development
Embrace continuous delivery by frequently integrating small batches of work directly into the source control trunk (at least once daily). Short-lived branches can be used to implement pull requests or to isolate release candidates, but should never persist longer than a day. Utilize Feature Toggles to turn off features that are not yet ready for release. Pull the Andon Cord and... Read More
assistant Development Tip
Feature Toggles
Decouple feature releases from code deployments by encapsulating features and infrastructure changes inside switchable software modules. Facilitate continuous delivery by deploying code with isolated features that can be released on-demand, enable A/B testing, support operations with automated circuit breakers and kill switches, and... Read More
assistant Development Tip
CI Theatre
Avoid CI Theatre by applying the fundamental practices of Continuous Integration (CI), along with supporting engineering principles, to achieve a mature DevOps Model for continuous software delivery. Precursors of CI Theatre include large user stories, difficult code merges, lengthy code reviews, poor test coverage, long-lived branches, siloed code ownership, broken builds for more than several minutes, and... Read More
assistant Development Tip
Frequent Check-Ins
Promote a DevOps model for software delivery by checking code into the trunk multiple time each day. This will ensure the changes are smaller and less likely to break the build, foster greater discipline in refactoring by preserving behavior through small changes, and ensure you can revert to a good, known version of the software when a mistake is made. Avoid using branches as that will... Read More
assistant Development Tip
Small Releases
Make frequent, small releases so as to not impede the progress of others.1 Avoid modifications to large portions of code, which promote large, infrequent releases. Big changes will make merging difficult, increase the risk of deployment, and impede your productivity along with your teammates. Read More