Trunk-based vs feature-based development dilemma — Part # 1
Industry standard rules and organized work effort are crucial to the success of every team in a software development project. The concept of trunking or feature-based development (same as GitFlow) have been around since the early days of subversion control. Both trunk-based development and feature-based development are widely-used development workflows in the git ecosystem.
Understanding the concept?
Trunk-Based Development
Is a version control management practice where developers merge small, frequent updates to the “trunk”, sometimes referred to as the master branch or main branch. Since it streamlines merging and integration phases, it helps achieve the goal of CI/CD and increases software delivery and organizational performance.
In a trunk-based development, an engineer directly pushes code changes to the master branch, but in situations where the current task requires more time to complete, lets say two to three days. The developer can check out a feature branch from main or master branch, move the changes into it, then merge it back in when development is done.
Fellow developers must then perform a code review based on company set policy before merging the checked-out branch with the main or master branch. The one thing to note in trunk-based development is that, checked-out branches are short-lived, and should be deleted after merge, 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. This workflow requires that the team harnesses the expertise of more experienced engineer on the team. Junior or inexperienced members need enough grooming and understanding of the workflow before they can contribute to the project.
Feature Based Development
A feature-based development workflow also referred to as GitFlow — is a classic approach to collaboration on a software development project. This development approach is most widely used among software development teams.
Feature-based workflow uses many long-lived branches for developing individual features. Before developing a feature, the developer branch out to a “feature” branch and makes all the code changes in this branch, once the code passed all set test, the developer creates a merge request from the feature branch into the main or master. The code changes will be allowed to be merged into the main or master if the changes passed in the code review session (this is obviously not always true, some code slipped into main branch without been reviewed 😍 — we will come back to this in a later series). The key take-away from this is that, developers never ever pushes code directly to the main or master branch in a feature-based workflow.
One of the the advantages of the feature-based workflows in git is developers can branch out and work on different unique features on a single project independently. Feature-based git workflow is ideal in a tea where there are less experience developers (The workflow allows junior devs to get their hands dirty and work on a features in other to learn without worrying about breaking production code).
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.
For example, sometimes if a team must maintain multiple versions of software application, take for example, the python programming language, version 2 is not compatible with version 3, both receives patches and bug fixes, that does not mean a new release of version 3 is based off of the last commit or latest commit of version 2. In such situation, a long-lived branch of different versions can be maintained, therefore a trunk-based workflow may be challenging to implement. The Linux kernel is another classic use case for feature-based development that 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.
Choosing the best for your team?
Both trunk-based and feature-based development workflows have their benefits and drawbacks. Choosing which is best to adopt in your team your team depends on the group’s collective preferences, available experience and the overall suitability approach for the team’s workflow.
For example — a teams that have adopted continuous integration best practices and which have experience developers can adopt a trunk-based branching workflow because it allows for fast iteration and feedback, reducing costly and time-consuming merge conflicts at the end of long feature development cycles.
Feature-based workflow is ideal for team with less experience developers, the workflow is also best adopted in when different versions of a software need to be maintained either by the same of different dev teams.
If you like this article, do well to drop a like and follow. I promise, I’ll write another article tomorrow..
