Standard guidelines and coordinated work effort are vital to the success of every team-based software development project. Based on Git, both trunk-based development and feature-based development are widely-used development workflows. How do they work? In a trunk-based workflow, only a single branch (trunk) holds the project’s deployable code, whereas a feature-based workflow uses many long-lived branches for developing individual features.
Teams at Facebook, Google, Netflix, and many other tech businesses use these workflows.
In this article, you’ll learn the differences between trunk-based and feature-based development and how to decide which is the right workflow for your team.
What is trunk-based development?
The trunk-based development workflow is one of the most popular development frameworks among developer teams.
A developer can directly push changes to the main branch, but if a coding activity requires more extensive time — perhaps a few days — they can check out a branch from main, move the changes into it, then merge it back in when development is complete.
Fellow developers must then perform a code review based on company guidelines before merging the checked-out branch with the main branch. The crucial thing about checked-out branches is that they are short-lived, spanning two to three days at most.
In a trunk-based workflow, the main branch should always be production-ready. Faulty code can break the entire build and result in a complicated development history. That means that teams should thoroughly test each code change before pushing them to the main branch. Short development cycles and automated testing enable teams to identify defects and recover from failed builds quickly, reducing the risk.
Using the trunk-based workflow requires that there are experienced developers on the team. Junior or inexperienced members need enough of an understanding of the workflow before they can contribute to the project.
What is feature-based development?
A feature-based development workflow — or a GitFlow — is a classic approach to software engineering.
Before developing a feature, the developer checks out a “feature” branch and makes all the code changes there. The developer creates a merge request with the main branch when the development on the feature is complete. Depending upon company policy, there might be a code review before merging the feature branch into the main branch. Most importantly, developers never push code changes directly to the main branch in the feature-based workflow.
The advantage of feature-based workflows is that hundreds of developers can work on hundreds of unique features at any given time. They can carry out feature development in small phases so that multiple merge requests do not conflict with one another.
Feature-based workflows favor less-experienced or less-senior team members. They can work on their features without worrying about breaking the production code. A tech lead, QA, or any development team member can test the build for each merge request.
Managing feature-based development can be tricky, though, especially when multiple pull requests are queued to merge into the main branch. The team lead or senior software engineer is responsible for reviewing these requests quickly and merging them with the main code. This situation can sometimes lead to conflicts that can dishearten newer developers, who may have to wait longer for merge approval. Slower integrations can also lead to less-frequent deployments and longer recovery times for failed builds, so product innovation can lag behind.
There are situations in which you and your team may want to consider a feature-based workflow despite the difficulties.
For example, sometimes you must maintain multiple software versions. In these cases, a trunk-based workflow may be challenging to implement. The Linux kernel is a classic use case for feature-based development and uses long-lived release branches. The feature-based workflow is the most sensible solution in this situation because users may have to maintain each released version of the Linux kernel for years — possibly even decades.
Importance of trunk-based workflows in your CI/CD practice
One of the greatest benefits of trunk-based workflows is that they integrate well with existing continuous integration and continuous delivery (CI/CD) services. When you push each commit to the main branch, you can run automated tests (part of CI) to verify that the new changes do not break the main branch. Then, after all the tests successfully terminate, you can configure a pipeline to create deployments for the QA team on the staging branch.
Based on the QA team’s feedback, the release manager — the person responsible for creating new releases — can publish a new release by pushing the main branch code to the release branch. The release manager can then deploy the latest release to the production environment.
This kind of workflow ensures that the release branches remain unaltered since each release is unique. If there are production issues, a senior developer can sometimes create a fix to patch the bugs in a release.
After creating a new release, the development work continues for the next release by pushing the code to the main branch. Over time, the old releases become stale, and the team can safely delete the corresponding release branches.
Many teams use continuous integration for testing and building their software. The trunk-based workflow method integrates well with CI/CD systems. It allows quick iteration and keeps code ready to deploy.
Feature-based development, on the other hand, has long development cycles and messy integrations. The review process can add a substantial amount to the time it takes to preview the new changes live.
How to implement trunk-based development
A trunk-based development workflow is a good fit for many applications. If you are working on a new project that is either a minimum viable product or a proof of concept, then the trunk-based workflow is likely the way to go.
One advantage is that developers on a team can push changes regularly without waiting for someone else to review and merge pull requests. The only requirement is the on-team presence of some experienced developers who can ensure that the team does not commit any build-failing changes to the main branch. Or, better yet, automated CI/CD tooling can check the new code for errors before pushing the code.
To implement trunk-based development in your projects, you need:
- An online service like GitHub for Git version control.
- To set up a main (trunk) branch, a staging branch, and a production branch. Developers push their code to the main branch and the release manager creates a new release by merging the main branch with the staging or production branch.
- A continuous integration (CI) system to test the new changes the developer submit before they are available for release.
- A continuous deployment (CD) system to build and deploy the project to the staging or production environment.
Having a robust DevOps system and culture is also crucial for any organization implementing trunk-based development. As more customers use your product, you will receive more bug reports and feature requests. These notifications will keep your developers busy, so you need a system to test new changes before making the software ready for the release.
Check out some of the best CI/CD practices for ideas about setting up automated tests and deployment pipelines.
Trunk-based vs feature-based development: Which is best for your team?
Both trunk-based and feature-based development workflows have benefits and drawbacks. Deciding which solution is best for your team depends on the group’s collective preferences and experiences and the overall suitability for the team’s workflow. For teams that have adopted continuous integration best practices, a trunk-based branching model allows for fast iteration and feedback, reducing costly and time-consuming merge conflicts at the end of long feature development cycles.
No matter which development workflow you prefer for your team, you will benefit from using a CI/CD system for testing and building the software. Sign up for a free CircleCI plan to start setting up your project’s continuous integration and deployment pipelines.
