Problem
A branch per project is where the time and money go.
Each project keeps its code on its own branch until its go-live — a quarter or more, even when the organisation releases every month. Then come late, painful merges and a test environment per project.
Parallel projects on long-lived branches
- Code waits for the project, not the release. The organisation may release every month, but a project going live once a quarter keeps three months of work on its own branch.
- Merge cost. Branches that live for months integrate late, and merging them takes days of work — "merge hell".
- Environment cost. Every isolated branch needs its own test environment, each with its own set-up and running cost.
- Release risk. A release carries whatever projects were merged into it. One late or faulty project holds back the others.
- Late feedback. Problems between projects show up only when they merge, just before go-live.
Who feels it
The same branches, seen from each seat.
Finished work waits for the whole project; one late feature holds back the release; teams merge and re-test instead of building.
A new feature reaches every customer at once, on the release date, with no safe way to try it with some first.
Toggle needs are free text in each story, and who gets a feature first is explained again to every team.
Code sits on its own branch for months, then merge hell before every release.
An environment per project; system testing waits until every feature is ready, and every merge means testing it all again.
Integrated applications must go live together; a late feature means pulling code out at the last minute.
Going live is an out-of-hours deployment, and undoing a feature means another one.
Each application has its own toggle mechanism, or none; one feature across applications can't be switched as one.
The way out: trunk-based development
Everyone merges small changes into one main branch, often. Feature toggles are what make it safe.