Self-Test: How Trunk-Based Is My Workflow?

Until recently I had a naive idea of trunk-based development: every commit goes straight to main, and as soon as CI is green, it is deployed to production. My interpretation was that branches were frowned upon, even short-lived feature branches, and release branches all the more.

I had planned a blog article explaining why I did not consider that sensible. During my research, however, I learned that I was quite wrong and that the definition of trunk-based development is by no means as naive as I thought:

Release branches are even explicitly provided for, and short-lived branches, even with review, are the norm.

Admittedly, I have never worked on a project that claimed to be trunk-based. In hindsight, the workflow of some of those projects was trunk-based development after all. And my own projects come very close to the ideal of trunk-based development.

To classify workflows more precisely, I built a self-test following trunkbaseddevelopment.com. It asks what happens in a team’s daily work, not what the team calls its workflow. Questions, options and weighting reflect my current state of research and probably not the absolute truth. Deeper dives into the individual questions, as well as some critical remarks, will follow in a series of articles I am currently writing.

_{(No data is stored or transmitted; the evaluation runs entirely in the browser.)}

1. How long does a typical development branch live until it is merged into main?

Waiting time for review and approval counts.

There is no development branch, I commit straight to main. A few hours up to two days. Several days up to about a week. Weeks or longer.

2. How often does an individual developer integrate changes into main?

Per developer or AI agent, not the whole team.

Several times a day. About once a day. A few times a week. Less often, usually when a feature is finished.

3. What has to be achieved before a change may go into main? Every small, finished step with a green local build, even without visible benefit for the customer. A usable partial step of a larger undertaking. The complete feature. Every commit, unfinished ones included; the build may be red in between.

4. When is a change reviewed by another person? While writing it (pair programming, AI review) or before the merge within minutes. Promptly after integration, or depending on the risk of the change: small ones directly, risky ones only after review (Ship / Show / Ask). Before every merge, usually within hours. Before every merge, and that usually takes days.

5. How quickly are open domain questions decided during development? Immediately, I or the team decide ourselves. Usually the same day. Within a few days. Often only after weeks.

6. How many development branches are open in the team at the same time, compared with the number of developers and AI agents?

Release branches do not count here.

Fewer, often none at all. About one per developer or agent. More, because branches are waiting for review or decisions. A multiple.

7. Which technique keeps unfinished functionality on main invisible? Feature toggles that switch new functions off at runtime. Keystone interface or branch by abstraction: everything is there, only the entry point is still missing. Only backward-compatible groundwork such as new fields or endpoints; the visible part stays in the branch. None at all; unfinished functionality stays entirely in the branch.

8. How are interdependent changes handled? Cut small; each step lands on main before the next one begins, behind a flag or abstraction if needed. Mostly cut small; if a branch grows too large after all, finished parts are extracted and integrated ahead, occasionally as stacked PRs. As a rule, branches building on each other (stacked PRs, branches of branches), merged one after another at the end. Everything together in one branch or an integration branch for the undertaking, until the whole thing is finished.

9. How long does the automated verification of a change take? A few minutes. Up to about 30 minutes. Longer than 30 minutes. There are hardly any automated tests; verification is done by hand.

10. What are branches used for that live longer than a week? Not at all. For experiments whose code is usually discarded in the end. For architectural rework that is to be integrated later. For normal feature development.

11. How does work proceed in the days before a release? Like on any other day; integrations into main continue at the same pace. Risky changes wait, small ones keep going into main. There is a code freeze: main is closed for new functionality until the release is out. Finished features are removed from main again or held back before the release.

12. How often does a developer pull the current state of main into their working copy? Several times a day, even without a specific reason. At least daily. Shortly before the merge, to resolve conflicts. Rarely; conflicts are resolved when the finished feature is merged.

13. How many people work on the same development branch at the same time? There is no development branch. One person, or one pair, possibly together with their AI agents. Several, when they work on the same feature. The whole team shares one branch per undertaking or release.

14. How does a fix for an already released state come about? Fixed on main and released; there is no separate state. Fixed on main and then cherry-picked onto the release branch. Fixed on the release branch and then merged back into main. The release branch is fixed and also developed further; main catches up later or not at all.

15. How large is a typical backlog item before it may go into main? A few hours of work, a thin slice through all layers. One to two days. Several days up to a week. Longer, often cut by layer (backend first, then frontend).

16. How does the local build work before a change is pushed? Compile, unit tests and smoke test in about a minute; CI checks the rest before the merge. All tests locally, because they run through in a few minutes anyway. A local build is mandatory but takes ten minutes or longer; therefore pushes happen less often. No fixed local build; pushing is how we find out whether CI goes green.

17. What happens when the build on main is red? Revert or fix within minutes; the team keeps working from the last green state. Whoever caused it fixes it promptly, the others wait meanwhile. main often stays red for hours or days. main is regularly red, nobody feels responsible.

18. Who may change which code, and what does a review decide on? Anyone may change anything; reviews reject only for published, objective reasons. There are teams responsible per area, but anyone may submit changes there for review. Only those responsible change their area; others have to ask them. Reviews also reject based on taste or responsibility.

19. Against which state is a change verified before it lands on main? Against the state main will have when it lands (merge queue or speculative merge). The branch is brought up to the main state before the merge, then CI runs again. CI only ran on the branch state, which may meanwhile be behind main. No CI runs before the merge.

20. How quickly could the current state of main be released?

This is about technical and quality readiness, regardless of whether a release is currently permitted, announced or approved.

Every green change goes to production automatically (continuous deployment). At any time within about an hour; no further steps are needed between green CI and deploy. Within a day, after a short manual check. Only after a manual test or stabilization phase of days or weeks.

What the Result Means and What It Does Not
#

The degree of adoption describes, as I understand it, how many of the practices that trunkbaseddevelopment.com names for trunk-based development a team actually applies in daily work, weighted by their importance for short integration intervals. It is a self-assessment, not a measurement: The test only asks about what seems typical to me, and only as honestly as it is answered. Nor is it meant as a measure of quality: A high value is not “better” than a low one, because what probably matters more is which way of working fits the respective context. Anyone deliberately working with long-lived feature branches gets a low value here and may still have a well-functioning workflow.

This article was translated from German with AI assistance.

What the Result Means and What It Does Not#

What the Result Means and What It Does Not
#