Understanding Trunk-Based Development

Trunk-based development (TBD) is a software strategy where developers work on a single main branch of code, often called the “trunk.”

Instead of constantly creating many different branches, everyone merges their changes directly into the trunk, typically resulting in smaller changes.

The method encourages frequent integration, helping avoid merge conflicts and ensuring the codebase stays up-to-date. Everyone works on the same project in real-time rather than creating separate versions and trying to combine them later.

TBD is especially useful for experimentation. New features are often hidden behind feature flags until they’re ready for release. Or, if you’re part of a larger team, you might create a short-lived branch, make your change, and then merge it back into the trunk as soon as it’s ready.

This practice makes it easier to experiment, learn, and adapt. You can quickly test ideas and gather user feedback without getting bogged down in complex branching strategies.

Core principles

The TBD process uses a few key characteristics. These principles guide how teams collaborate on a codebase.

• Single branch: The main trunk is the central branch where all code changes occur. It simplifies the workflow and keeps the project organized.

• Frequent commits: Developers commit changes to the trunk regularly, often several times daily. This habit keeps the codebase updated and ready for new experiments, reducing the risk of large, disruptive changes.

• Short-lived branches: Larger teams can create new features or fixes on short branches, which developers then merge back into the trunk as soon as possible. Short-lived branches support quick experimentation and adaptation.

• Continuous integration (CI): Automated tests run with every commit to ensure new changes don’t break the existing code. Constant testing enables you to experiment with new ideas confidently.

• Code reviews: Before merging changes into the trunk, developers check each other’s code. Reviews improve code quality and knowledge sharing within the team.

• Feature flags: You can add new features by hiding them behind feature flags (switches in the code). Toggling the features on or off lets you test incomplete elements in the trunk without disrupting the user experience.

How does trunk-based development work?

When practicing TBD, most teams go through these steps if they need to make a product change or update.

1. Start development: Begin working on a new feature or bug fix.
2. Branch off trunk: Create a short-lived branch off the trunk to work on the change.
3. Work on small changes: Make small, gradual changes to ensure each change is manageable and testable.
4. Run local tests: Run tests locally to ensure the changes work as expected and don’t break the existing functionality.
5. Push change to trunk: Commit and push the changes to the trunk branch.
6. Automated tests: A CI server automatically runs a suite of tests on the new code to verify it integrates well with the current codebase. If the tests pass, continue to the code review. If they don’t, provide feedback to the developer to fix the issues.
7. Code review: Other team members check the code’s quality and whether it follows coding standards. If the code is approved, merge it to the trunk. If it’s not approved, provide feedback to the developer for improvements.
8. Merge to trunk: The approved change is merged into the trunk branch.
9. Feature flags: If a feature isn’t finished yet, it is placed behind a feature flag so it doesn’t impact the trunk's deployable state.
10. Trunk is deployable: The trunk remains ready to deploy, and the process repeats for new changes.

Trunk-based development vs. Git Flow

Git Flow is another approach to managing code and releases.

The method’s main differences to TBD are its workflow and how often you integrate:

• Git Flow uses multiple branches for different purposes, such as feature branches, release branches, and hotfix branches.

• Changes are merged less frequently, often at the end of a feature or release cycle.

TBD is more straightforward and faster than Git Flow, making it great for quick experiments and product updates. The approach helps teams move fast and adapt to new insights.

However, with its structure and branch separation, Git Flow can be helpful for larger teams or projects with complex release cycles. If you need to test more thoroughly and aren’t as concerned about speed, Git Flow might be best.

TBD often wins out for most product experiments due to its flexibility and speed. You can quickly test ideas and deliver new features to your users—ideal for innovation-focused teams.

TBD goes hand in hand with continuous integration/continuous delivery (CI/CD) pipelines.

Many developers believe this strategy is the only way to accomplish continuous integration, as the trunk is kept in a constant, healthy, and releasable state. Using many feature branches can undermine the main advantage of CI/CD, which is enabling quick, reliable, and regular releases.

CI ensures developers' frequent changes to the trunk integrate smoothly. Automated builds and tests verify that the new code is compatible with the current codebase and doesn’t introduce bugs. Unit, integration, and end-to-end tests are part of CI.

CD builds on CI by automating the deployment process. Once pushed, changes might go through staging environments for further testing or production environments for live deployment. CD also means the codebase is always up-to-date and ready for deployment—frequent commits and feature toggles support this approach.

Here’s how TBD might work within a CI/CD pipeline:

1. Commit code: Developers commit their changes to the trunk.
2. Automated build: A CI server automatically builds the new code and runs automated tests.
3. Immediate feedback: If the build or tests fail, developers are notified immediately to fix the issues.
4. Staging deployment: Once the build and tests pass, the changes deploy to a staging environment for further testing.
5. Production deployment: After successful staging tests, the changes are automatically deployed to production, ensuring the trunk is always in a deployable state.
6. Feature toggles: New or unfinished features are managed with toggles, supporting a safe and controlled rollout.

TBD has surged in popularity recently, becoming standard for most high-performance, experimentation-focused dev teams.

The strategy’s compatibility with other practices (including CI/CD) means it can be great for products that ship continuous updates, like those in the SaaS industry.

TBD can provide several benefits if everyone follows the main “rule” of regularly committing changes. The practice helps create an environment where product teams can develop faster, respond to user needs more quickly, and maintain a high-quality, dependable product.

Improved collaboration

TBD puts everyone on the same page—literally. With all developers working on one main branch, there’s more visibility into what others are doing, which fosters better communication and teamwork.

Adopting TBD means designers, developers, and product managers stay in sync on new features and experiments. They can review and clearly understand the entire codebase and remain on top of the latest changes.

Reduced merge conflicts

Developers avoid the headache of massive merge conflicts by making small, frequent updates to the trunk. TBD is like tidying up a little each day instead of a spring clean once per month. This practice saves time and reduces frustration, enabling teams to focus on building and testing new product features.

Faster delivery cycles

With code integrated continuously, new features and improvements can be released much more quickly—the codebase is (ideally) always in a releasable state.

This speed is crucial for experimentation, enabling product teams to test ideas, gather data, and iterate quickly based on user responses.

Higher code quality

Regular integrations mean issues are spotted and fixed early. Automated tests run on every commit, catching bugs before they become big problems. As a result, you get a more stable product and are less likely to have to fix critical issues in production, improving the end-user experience.

Simplified development process

TBD means no more juggling multiple branches or complicated merging strategies. Developers can focus on writing code and shipping features. This simplicity translates to more predictable timelines and easier coordination of releases and experiments. Teams can onboard new members into the project and keep track of the codebase.

Adopting any new development strategy involves some challenges—TBD is no different. Businesses should be aware of these hurdles and approach the transition thoughtfully, with buy-in from all organizational levels.

Learning curve

Switching to TBD can be a big change, especially for teams used to long-lived branches. The strategy might require understanding new skills like feature flagging and getting used to more frequent code reviews. This learning curve may slow down progress at first.

Product managers and developers must adapt to a faster, more incremental approach to building features. Good training and grasping best practices help ensure everyone is comfortable with the new approach.

Discipline and practices

TBD demands discipline. Developers must write smaller, thorough, and self-contained chunks of code, while teams need strong testing practices to catch issues quickly.

Using TBD properly means breaking features into lesser, testable pieces and being comfortable with phased rollouts. The code can quickly lose stability without these processes.

Tooling and infrastructure

Businesses might have to invest in new tools, particularly for feature toggles, code reviews, and continuous integration. They might also need to adopt stronger automated testing and deployment pipelines. This upfront cost can be significant and more challenging for smaller organizations but usually pays off in faster, more reliable releases.

Cultural shift

Perhaps the biggest hurdle to overcome when implementing TBD is the mindset change. Teams must embrace continuous integration, be okay with incomplete features living behind flags, and value small, regular updates over big launches.

This shift can be challenging, especially in organizations with established workflows and hierarchies. The transition affects everyone, from developers to product managers to stakeholders. To overcome this initial resistance, encourage more communication, openness, and shared responsibility.

Moving to TBD may seem daunting initially, but the right approach can revolutionize your development process.

Let’s explore some of the most important steps to successfully implementing TBD into your team’s workflow.

Assessment

Start by evaluating your current process. Look at how you manage code, release features, and run experiments. Identify pain points like slow release or regular merge conflicts.

Consider how your current workflow impacts your ability to test ideas quickly. This assessment helps you understand where TBD can have the biggest impact.

Planning

Develop a phased approach to implementation. Begin by training your team on the principles of trunk-based development, and then plan for necessary tooling changes, like setting up feature flag systems. Create new guidelines for code reviews and commits. This is the time to rethink how you break down and prioritize your product’s features.

Implementation

Kicking off TBD with a pilot project to iron out the kinks is great. Implement continuous integration tools and start using feature toggles for new developments. Then, gradually shift more projects to the trunk-based model.

Throughout this process, maintain open communication between development and product teams to ensure everyone understands the new workflow.

Monitoring and iteration

Keep a close eye on metrics like release and merge frequency, time to market for new features, build success rates, and the number of production issues. This data provides insight into the effectiveness of the new workflow.

Gather feedback from both the dev team and product managers. What are they struggling with? Where can you make improvements? Use this information to refine your process, and be ready to change your approach based on what you learn.

Consider how this new workflow affects your ability to launch and analyze tests when experimenting. You might find you’re able to run more experiments at the same time or build on ideas more quickly.

Several of the world’s largest and most notable brands openly use TBD to their advantage. From Microsoft to Netflix to Etsy, TBD is standard practice for many fast-paced, software-based companies.

However, one of the most successful examples of implementing TBD comes from Amazon.

Approach and release management history

The ecommerce and entertainment giant practices continuous deployment as code changes automatically deploy to production once approved and merged. This approach means Amazon’s developers don’t need to schedule individual releases or decide what changes to include in deployments.

Before TBD, Amazon used a traditional release management system. A release captain managed release branches and scheduled the releases. Now, developers rarely interact with branches other than the main branches. For most teams, release branches are no longer necessary due to the CI/CD pipeline’s automatic release process.

Amazon’s TBD process

Developers make frequent, smaller commits to a single branch called the “main” in Git and the “mainline” in Amazon’s internal Git system. This method replaces the infrequent merges of large changes from long-lived feature branches.

Work is done on local clones of the main branch, splitting the work into smaller, incremental changes. Typical work on an individual change lasts a few hours to a few days before moving to a code review. Developers can automatically back up local commits to a personal branch that isn’t part of the main workflow.

All changes require an approved code review before merging into the main branch. Developers fetch and rebase their changes on the latest main branch before submitting them for review. Amazon’s code review tool automatically pushes local commits to a unique, short-lived Git reference for review.

After approval, changes are merged into the main branch. This action triggers the CI/CD pipeline to build, test, and deploy the change.

Strategy for short-lived branches

Interestingly, the brand only uses short-lived release branches for rare or urgent changes, such as security fixes. These branches contain only the necessary changes, excluding unrelated updates from the main branches.

At Amazon, short-lived branches are scrutinized and reviewed at a high level by experienced developers and Principal Engineers. Once deployed, these release branches are discarded.

Benefits and results

TBD quite clearly works well for Amazon’s culture of constant innovation. The strategy has enabled the brand to:

• Move from weekly or monthly releases to multiple quick and small releases per day
• Free up resources by getting rid of the release captain role for most teams
• Concentrate on building features for its users rather than managing releases
• Rollback fast and easily when problems arise, reducing risk and downtime
• Scale its development process alongside various new services

Using TBD, Amazon has ensured it remains customer-focused and fast-paced while continuing to grow its many product offerings.

As your team and codebase grow, ensuring your TBD strategy can keep up with your needs is crucial.

Scaling means you can continue reaping the rewards of rapid experimentation and development as your product and organization become more complex. You can run more experiments alongside each other and manage intricate feature rollouts across large user bases.

Let’s look at how you might manage scaling TBD.

Modular architecture

Divide your codebase into smaller, loosely coupled modules. This method lets teams work independently while still contributing to the main trunk. Developers can make changes to their modules without disrupting the entire project.

Advanced tools and systems

Use build systems that can handle partial builds and tests to speed up the build time for large codebases. Consider automating parts of the code review process—static analysis tools can catch common problems before a human review.

As your product grows, you’ll likely have more features behind flags and rely more on toggles. Using feature flag management systems can help keep this increase under control.

Large trunks can also slow down version control operations. You may need to adopt specific tools for handling bigger files and ensure your hardware is powerful enough for your CI/CD systems.

Team structure

Organize teams around your business domains or product areas, such as a different group for major elements or features of your software. This structure reduces the chances of multiple teams working on the same code, which can lead to conflict.

Documentation and standards

Clear, up-to-date documentation becomes even more important at scale. New team members need to know where everything is within the codebase and understand the review and merge processes you follow. Set, write down, and enforce coding standards to keep things consistent.

Trunk-based development helps teams deploy more frequently and work closely together. Through implementing the approach, organizations can massively streamline their development process and adapt their product to meet user needs and market changes.

Reliable and effective feature management is one of TBD's core elements. Amplitude helps you manage your feature flags while supporting you with other experimentation tools and analytical insights. The unified platform encourages faster deployment while enabling data-driven decisions for feature releases—the foundation of any successful, cutting-edge product.

With Amplitude, teams can:

• Perform targeted rollouts and easy A/B testing
• Monitor the impact of new features in real-time
• Simplify feature flag cleanup to maintain a clean codebase
• Foster better cross-team collaboration