Throughout the history of computer software development, organizations have often managed independent streams of development on a single code base by using “branches”. Multiple streams are often perceived as being necessary in order to allow different individual developers or teams to work on different sets of changes, simultaneously. The sets of changes could be new features, fixing bugs, or refactoring existing code.
Multiple branches offer the appearance of isolation, especially in the early stages of the development cycle. However, they often cause problems down the road, due to the inevitable necessity to combine, or “merge”, all the different branches together. The different new features may not all be ready for release, even though some of the critical bug fixes are. Attempting to merge different branches together inevitably causes conflicts, and unforeseen problems, due to it being the first time they can be tested together. The longer the branches were isolated, the greater chance there is for incompatibilities between them. The term “big-bang merge” is often used to describe this process. A rush to fix any resulting bugs becomes necessary, often with a “code freeze” on new features. Valuable developer time gets wasted. The release date often slips unpredictably.
From the customers’ point of view, they only see the delays in the release. And when the release is finally received, it often has bugs, sometimes major ones, which were never discovered due to the lack of testing after the big merge. Customers end up constantly dealing with a buggy product, and waiting long periods of time for updates to the software.
Customers (whether external or internal) want to see improvements in the software, at a regular cadence, and without the introduction of new bugs. This can be facilitated by using a trunk-based strategy when developing the software. In a trunk-based development strategy, all developers work in the same branch simultaneously. All new features or bug fixes are developed in the main trunk branch; there are no other branches.
There are many advantages to this strategy, which prevents big-bang merges. Integration between multiple independent changes happens sooner in the development process. This allows them to be tested thoroughly, in smaller chunks, and find any any bugs early. They can be fixed without requiring a code freeze. It allows more time to evaluate whether any bug or bad feature found should be fixed, or redesigned, or even abandoned (thereby cutting any losses). With an effective trunk-based development process, and a full suite of automated tests, in place, teams can deploy new versions of the software to a production environment on a frequent, regular basis: weekly, daily, or even multiple times per day, allowing for quick, “agile” reaction to customer needs, as well as proactive changes, fixes, and refactoring.
In practice, a trunk-based development strategy prevents most bugs from even being deployed. But in the event a bug is discovered after release, it can usually be easily and quickly fixed. This is a “fix forward” strategy, as opposed to a “roll back” one. The end result is the customers see a more stable system, with a steady stream of smaller changes, happening more often, with less bugs, and quicker response to fixes.