Introducing trunk-based delivery to a team that had never tried it

A client team we joined had a familiar setup: feature branches that lived for weeks, a develop branch, a release branch, and a monthly deploy that took a day and usually slipped. Every merge into develop was a small negotiation. Nobody enjoyed it, but it was the process, and changing a process mid flight is risky.

We moved them to trunk-based delivery over about six weeks, without stopping feature work. This is roughly how.

Week one: make main deployable

Before changing anyone's habits, we made sure main could actually go to production at any time. That meant a pipeline that ran the full test suite, built artifacts, and deployed on merge, plus a fast rollback. Until that exists, asking people to merge to main daily is asking them to be reckless.

Weeks two to three: feature flags

We added a simple flag system: a config driven toggle with per environment values and a clear owner for each flag. New work went behind a flag from the first commit. This is what lets an unfinished feature sit in main without being visible. It is also the single biggest unlock, because it separates deployed from released, and once those are separate, small merges stop being scary.

1. 1Every new feature gets a flag on day one, default off
2. 2Merge to main whenever the code is safe, not when the feature is done
3. 3The flag comes on when the feature is ready, in a separate change
4. 4The flag comes out once the feature is stable, as cleanup

Weeks three to five: shrink the branches

We set a soft rule: a branch lives at most two days. If it is going to take longer, the work is too big and needs to be split. This is uncomfortable at first because it forces you to design changes so they can land incrementally. That skill is the actual point. After two weeks it stopped being a rule anyone thought about.

Weeks five to six: drop the ceremony

With small branches, flags, and an automated deploy, the develop and release branches had nothing left to do. We deleted them. Releases stopped being a scheduled event and became a property of merging.

What changed

• Lead time from merge to production went from weeks to under an hour
• Rollbacks became routine and boring instead of alarming
• Code review got faster because reviews got smaller
• The monthly release day, and the stress around it, disappeared