That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.
Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.
Comments
That's really a function of your QA process, not anything specific to branching strategies. If you can automate everything such that continuous delivery (or even deployment) is possible - great. If not, deliver at whatever pace your QA allows (and strive to increase that pace). Trunk based development does not imply a diminished QA process.
Yes, there is always going to be a feedback delay between you making a change and the full impact of that change being known (even if your feature is bug free, will the customer want to use it?), but we should be bringing that feedback forward by moving changes through the pipeline as early as possible. Feature branching delays feedback, which is why I reject it.