A team I recently started working with has been using GitFlow.

They had three long-lived branches: devel, staging, and main. Devs would create their branch from devel, and merge back to devel when ready.

The code in the devel branch would be deployed to their Development environment, where the QA engineers could run their automated and manual tests. When deemed ready, they’d create a PR to merge any outstanding changes from devel to staging, where the code would be deployed to a public, user-facing Staging environment.

After sufficient testing here, changes would finally be merged to main and deployed into the Production environment.

This team was working on a 1-week sprint cadence.

In theory.

In reality, QA delays would frequently mean it could take up to 2 weeks to get a change through the entire process.

Last week we made the switch to trunk-based development, as part of the switch to my Lean CD approach.

Now developers branch from main, and merge to main when they’re confident their change is sufficiently tested and ready for production. At that point, the change is deployed both to the Staging and Production.

Of course, there’s still a desire for manual QA testing for now. How do we do that? The developers can push their changes to the devel branch, if they wish, in which case it’s merged to the Development environment for QA testing.

In essence, we’ve moved all the manual verification to before the merge. And the immediate result is that now no single feature has to wait for all pending featues to clear QA. Small batches for the win!