Trunk-based development is a branching model where developers work together on a single branch. Whereas feature-based development breaks up branches based on the needs of the project.
Setting up a development model with a version control tool is an important step to branch better. It organizes your team, defines how your projects and codebase will evolve, and allows you to implement policies for developers.
There are lot of development methods to choose from. So, which one is best for your team?
Read along or jump ahead to the section that interests you the most.
Table of Contents
- What Is Trunk Based Development?
- When to Use Trunk-Based Development
- What Is Feature Driven Development?
- When to Use Feature Driven Development
- Streamline Cloud Deployment with Version Control
- Other Development Methods
- Choose The Right Development Method For Your Team
- How Helix Core Supports Your Workflow
What Is Trunk Based Development?
Trunk-based development is a branching model that is also referred to as “mainline development.” All branches extend from one trunk/main branch, usually called the master branch. This persistent branch is where all developers commit. The master branch follows the evolution of a software project.
This model was the standard model for software development and is still used today. In this model, developers and release engineers only branch when it was absolutely necessary.
This means developers rarely branch. If they do, they create a short lived feature branch that is merged back into the master after being tested. Using this method, teams can avoid the overhead of branching and merging. Let's review trunk-based development pros and cons.
Trunk-Based Development Pros
Using this development method encourages all changes to come back to the mainline quickly. It can eliminate unnecessary divergence. And with a smaller team, it can keep overall software development costs down. This is because admins and engineers are not trying to maintain several “main” branches.
Because the master branch is the only long-lived branch, all other branches have a defined and limited lifespan. In theory, this can help minimize merge conflicts because no branches are hanging out in development for too long.
It enables developers to move fast. They do not need to deal with multiple steps before merging their code into the mainline. Because the fixes are applied right to the master branch, your code should always be production ready and waiting for the next release.
Trunk-Based Development Cons
One of the main challenges with trunk-based development is contention collision. If too many people are checking their changes into the mainline at the same time, it will be in a constant state of churn.
Developers can end up tripping over each other and constantly breaking builds. One popular (but cumbersome) workaround is to use feature toggles in your code. This add its own level of complexity and overhead.
Also, no one person has control over what is being modified in your code base. It is impossible to separate mature code from immature code. To implement this model, you will want to have only experienced developers on your team. Because a junior developer could merge in immature code that could destabilize your entire project.
Back to topWhen to Use Trunk-Based Development
If you are looking to push out a new product fast, using a mainline model can work. Your developers can get right to work. They do not need to deal with requests for merging. And you can iterate quickly. This is especially helpful in the beginning. If you need to change direction, this model allows you to incorporate new ideas fast.
But trunk-based has drawbacks. Make sure your team is experienced enough to handle the master branch. Mainline models give developers a lot of autonomy when it comes to making changes. It is important to set expectations in the beginning.
If your project uses open source components, you may want to avoid trunk-based development. Open source components can be less secure, and you do not want developers merging in potential threats. You are going to want to control what changes are moved into the master branch, and that means controlling merges.
Back to topWhat Is Feature Driven Development?
Feature driven development (also called feature-based development) breaks up branches based on the features in a product. Teams plan, design, and build by features. This method is closely aligned with the Agile methodology and is a popular pattern in GitFlow.
Breaking up development by feature can help teams (in theory) go faster. These feature branches can more easily be tested in isolation and introduced back into the project when they are ready for integration.
Feature driven development allows teams to truly work in parallel and dramatically reduce mainline contention and broken builds. For large teams this can be a valuable approach. You can allocate resources depending on the needs of the feature as well as have the option to easily move the feature development to a different release. Let's review feature driven development pros and cons.
Feature Driven Development Pros
With feature driven development, you can more easily manage large-scale projects. You can have thousands of developers working on specific features. Then code can be tested more easily before being introduced to your code base.
This system works great if you have lots of teams, geographically dispersed teams, outsourced teams, and/or junior developers. You can more tightly control what is being merged, and where.
Feature Driven Development Cons
Although feature driven development works for large-scale projects better, it can be difficult to manage thousands of branches. This is because not all version control systems help developers branch and merge automatically.
If a feature branch is hanging out in development for too long, it might conflict with another branch when merging. Feature driven development requires a lot of coordination to work. Teams need the expertise of a senior developer or manager to help manage branches and merges.
Back to topWhen to Use Feature Driven Development
If you are just starting up a project, feature drive development may not be a good place to start. That is because you might not even know all the features you want to include.
In the beginning, you need teams to move fast and iterate quickly. Using feature branches can slow you down and not allow you to adapt as quickly. Lots of branches and merge requests take time (and people) to manage.
But if you have a big team with a variety of skill levels, feature based development is a strong choice. You can easily plan out resources you need for specific features. And because you can test code more easily, you can make sure that immature code does not destabilize your codebase.
Back to topStreamline Cloud Deployment with Version Control
Help your remote teams collaborate better, no matter your development model. Watch this on-demand webinar to learn migration tips, deployment considerations, and options to expand your utilization of the cloud as you scale.
Back to top
Other Development Methods
Feature driven and trunk-based development are only two types of development. There are several other methods and model you can use, depending on the needs for your project and team. Some examples are:
Team-Based Development Model
Another way you can break up branches is by specific teams. And there are benefits. You can:
- Develop faster by distributing work to specific sub teams.
- Leverage expertise in specific areas of your project.
- Build closer teams.
This type of development works great for component-based development (CBD). But it is important to examine the challenges.
Team-based development requires a high level of communication to ensure that teams are not duplicating effort. And often teams have dependencies on development being done by another team. You need to set up a system that provides visibility across teams so that their work does not become increasingly siloed.
Also every team might set different standards. The more teams you have, the more critical it becomes to set coding and testing standards across your organization. This will help you sort out any future conflicts.
Stage-Based Development Model
Stage-based development aligns branches with the level of code maturity to help isolate immature code from mature code. For example, you could have branches corresponding to:
- Development
- Integration (CI)
- Nightly builds
- QA
- Pre-production
- Production
Although stages may vary depending on the organization, some teams may choose to set up their teams to align with how the software evolves. For example, you might have developers set up to work on the initial designs and development. Others would be responsible for testing, integrations, and maintaining releases.
The benefit in the example is while developers continue to submit code to development and integration branches, QA is working against a stable QA branch. This can be thoroughly tested.
But when implementing stage-based development, you need to make sure that it easy to propagate code along the various branches that correlate to each stage. In order to do this well, you need to either build automation to propagate the changes, or use a version control system that has this capability build in.
Back to topChoose The Right Development Method For Your Team
In reality, you will most likely need a combination of trunk-based development, feature driven development, and other methods to support your organization as your teams grow and projects get bigger. No matter your development method, you need a tool that can support you. You are going to want your version control system to enable parallel development, enhance visibility, and unite teams.
As your teams and projects grow, you are going to be branching more and more. So what tool supports your development teams?
Back to topHow Helix Core Supports Your Workflow
The only way you can truly scale a large codebase across many developers is by branching more often. Helix Core supports your teams as they grow and branch. You can organize thousands of branches, no matter the development model.
Whether you branch by team, feature, product area/component, or stage of development, Helix Core scales to meet your teams’ demands. It makes managing all your branches easier because you can more easily see dependencies and work being done by other developers (no matter their skill level).
Visualize Development With Perforce Streams
Perforce Streams is the branching solution in Helix Core. It gives teams a better, more visual way to branch and merge. And instead of needing to build automation to propagate changes, Streams always knows where code should flow.
Streams is so seamless, teams can even start using it in the middle of a project. Your developers can merge and switch between codelines fast. Using the Streams Graph, they can quickly see what changes need to be incorporated, and where.
Your teams can branch more, and you can better organize thousands of codelines.
Whether you prefer trunk-based development, feature driven development, or a combination — get branching with Helix Core.
➡️ start using HELIX CORE — FREE