When working as a team during development, it's essential to use a standard set of guidelines for easy coordination and collaboration. Most engineering teams use Git to manage and version their software code.
So, the development workflows are also mainly Git-based. Two of the most widely used workflows are feature-based and trunk-based development (aka TBD). Software development teams at Netflix, Google, Facebook, and other tech giants use these workflows.
But which of the two is better for your business? Below, we do a trunk-based development vs feature-based development comparison to help you figure this out.
What Is Trunk-Based Development?
In trunk-based development, a trunk or single branch is the main backbone of the project. It has the deployable code the whole team works on.
The developer will make it to the main branch whenever they have to make a change. When coding may require extensive time, the developer will check out a secondary branch from the main branch.
When finished, they will move the changes onto this branch and merge it back into the trunk. All of this happens through Git, which enables developers to have complete control over their code and ensures a unified version across the team.
You need the following to implement trunk-based development in a project:
- GitHub or similar service for version control
- A trunk-based development staging branch, a central trunk, and a production branch
- A continuous integration system for testing changes
- A continuous deployment system to deploy the project to the production or staging environment
Scaled Trunk-Based Development
Scaled trunk-based development extends the TBD approach to large-scale organizations by creating a hierarchical structure in which each team is responsible for a particular codebase subset. All teams in this hierarchy are assigned a specific subset with its specific branch.
Every team works on its designated branch and merges the changes back to the trunk frequently to ensure the code’s stability, keeping the development process agile.
Branch for release is a common development method used in TBD, in which a separate branch is created for every software release. Every branch is also maintained individually, with changes and bug fixes made to the particular branch associated with the software’s current release. The method allows seamless management of complex software development projects in multi-team organizations.
Trunk-Based Development Example
Three of the most notable companies that use trunk-based development are Amazon, Facebook, and Google. These giants use the trunk-based development workflow to collaborate and manage code efficiently.
Let's look at trunk-based development pros and cons below.
- Reduces the complexity of branching and merging
- Improves collaboration between teams
- Makes it easier to track code changes
- Helps the whole team stay on the same page
- Leads to conflicts in code if not managed properly
- Causes bugs to enter since full regression testing doesn't happen with every merge
- Requires developers to wait for their changes to pass the automatic build before merging
- Can lead to longer build times, since every change must be integrated with the main branch before it can be tested. This could be a disadvantage for some teams.
What Is Feature-Based Development?
Feature-based development or GitFlow means that each feature is in its branch and merged into the main trunk when finished. It allows developers to work on different features without disrupting other components of the codebase.
Feature-Based Development Example
Suppose a company wants to create an app customers can use to buy goods and services. The company would create a separate branch for each functionality, such as the login screen, product pages, shopping cart pages, payment gateway, etc.
Individual development teams or developers will work on their respective branches. After each feature is completed, the code will be merged into the main trunk and deployed to production if necessary.
- Requires fewer meetings
- Has a user-centric approach
- Works ideally for larger or ongoing projects
- Makes tracking and reporting easier
- Results in individual code ownership rather than team ownership
- Requires high dependency on the chief programmer for coordination
- Does not work well for smaller projects with only a few developers
Trunk-Based Development vs GitFlow: Which of the Two Should You Use?
Trunk-based development is better when software frequently changes and requires quick, frequent deployments. It allows developers to integrate small changes into the trunk easily.
For example, you should use trunk-based development when developing a new feature or fixing a bug. It also allows for more frequent code reviews and easier integration with automated tests.
Meanwhile, feature-based development is better for ongoing or long-term projects. For instance, if you're developing a large-scale application, you should use GitFlow.
GitFlow is also a better option if you have a big development team. Since it allows each developer to work on different branches, it reduces the hassle of extensive collaboration and meetings.
Frequently Asked Questions
Here are some common questions about trunk-based development vs feature-based development.
Does Netflix Use Trunk-Based Development?
Netflix is one of the many companies that use trunk-based development.
Is Trunk-Based Development Better Than Feature-Based Development?
Trunk-based development is better if you want to reduce the complications of merging events. It's also a better approach for minor changes in projects with fewer development lines.
Are There Feature Branches in Trunk-Based Development?
Feature branches are a part of feature-based development, where individual developers can work on their own feature branches and merge them into the main codebase. In trunk-based development, developers commit all changes directly to the main trunk. So, trunk-based development in AWS (Amazon Web Services) or Git does not use feature branches.
Merge Code Faster and Safer
Whether you're using scaled trunk-based development or a feature-based approach, automating your code merge process can save you time and energy. Automation also helps improve code security since all merging tasks are performed with predefined rules and criteria.
Mergify's Workflow Automation is just the way to accomplish this. With Mergify, you can write rules for triggering specific actions, allowing frequent merges in scaled trunk-based development.
For instance, the backport command allows you to copy pull requests into another branch automatically after the pull request has been merged. Afterward, Mergify automatically deletes the head backport branch to keep your repository clean.
Meanwhile, the Merge Queue automates the pull request sorting and improves merge frequency. Request a demo to see these features in action.