patterngitMinor
Branching model for nightly deploys
Viewed 0 times
nightlyforbranchingmodeldeploys
Problem
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...
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...
Solution
You're bringing up a big pain point - and there are 2 camps here, people who do GitFlow and people who prefer other approaches (with TBD being most popular).
Personally, TBD with release branches is something I would always prefer, but you can find lots of other people who would tell you GitFlow is better - so you'd have to decide for yourself.
In your case TBD would work as following - you keep committing to your master, however before release time you cut a release branch out of master. Once you do that, you don't have to code freeze master and your developers can keep working there.
Some materials for research:
On Gitflow - https://nvie.com/posts/a-successful-git-branching-model/
On TBD - https://trunkbaseddevelopment.com/ (especially check "Scaled Trunk-Based Development" section)
Critics of Gitflow (note that myself I'm biased towards TBD) -
Personally, TBD with release branches is something I would always prefer, but you can find lots of other people who would tell you GitFlow is better - so you'd have to decide for yourself.
In your case TBD would work as following - you keep committing to your master, however before release time you cut a release branch out of master. Once you do that, you don't have to code freeze master and your developers can keep working there.
Some materials for research:
On Gitflow - https://nvie.com/posts/a-successful-git-branching-model/
On TBD - https://trunkbaseddevelopment.com/ (especially check "Scaled Trunk-Based Development" section)
Critics of Gitflow (note that myself I'm biased towards TBD) -
- https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/
- https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0
Context
StackExchange DevOps Q#11334, answer score: 2
Revisions (0)
No revisions yet.