A GitFlow storyA team I recently started working with has been using GitFlow. Until last week.
A team I recently started working with has been using GitFlow.
They had three long-lived branches:
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
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 reality, QA delays would frequently mean it could take up to 2 weeks to get a change through the entire process.
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!
Implementing Continuous Delivery in Reverse - ATVIE22
If you heard about Continuous Delivery you might find it sounds great, but you are not ready for it because [insert excuse here].
The Technologist Podcast #4: Continuous Delivery, DevOps, Go
Coach Denis interviews me about my mission to bring enterprise-class software delivery to small teams with small budgets.