I'm a lead developer for a small B2B SaaS company, using Django and AWS. We currently run biweekly deploys after hours with a mostly-automated custom Fabric-powered tool.
We're currently exploring options for moving to fully-automated nightly deploys, but want to move to a different branching model to support this.
Right now, topics are branched from dev and merged to dev, a long-running branch which is merged wholesale with --no-ff into master during the biweekly prod deployment process. This necessitates a feature freeze on release days, to ensure that broken code isn't merged right before a release, and isn't really a great solution.
My current plan is to move to a more branch-oriented workflow, similar to Gitworkflow: https://github.com/rocketraman/gitworkflow. This would allow us to merge feature/bug branches individually to dev, then only merge to master the branches (corresponding to Jira issues) that have passed manual QA.
Is this a good approach?
In my mind, there are a few potential open questions, like how to handle issues/branches which have failed QA, and should be removed from the dev branch/environment. I suppose that instead of reverting commits, we could then "refresh" the dev environment by overwriting it with master, and re-merging all branches currently undergoing QA...