2

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...

Improve this question

1 Answer 1

Reset to default
2

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) -

  1. https://georgestocker.com/2020/03/04/please-stop-recommending-git-flow/
  2. https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0
Improve this answer
4
  • Thanks! I think GitFlow would be a little too cumbersome for nightly deploys, especially with an eye toward CD. Cutting release branches in a TBD-based model might make sense for less frequent deploys, but it doesn't address well the question of UAT (QA) rejection—what happens if a change in a release branch is declined or deemed to need extensive revision? I'm envisioning something in the middle, more like gitworkflow: github.com/rocketraman/gitworkflow which would allow us to integrate branches on master only if they pass UAT, with a throwaway environment for QA.
    – Alex Ball
    Apr 16, 2020 at 20:21
  • > what happens if a change in a release branch is declined or deemed to need extensive revision -- Ideally, you don't change release branch at all apart from critical (i.e. security) fixes. So you do all your testing before cutting release branch.
    – taleodor
    Apr 16, 2020 at 21:07
  • Makes sense. This may be more of a people problem, but UAT delay for any particular issue would run the risk of either delaying the release branch cut, or introducing bad code into the release branch. While we work to improve automated testing coverage and reduce reliance on UAT, I'd lean toward a topic-branch-based paradigm, where topics are individually promoted to a UAT branch/environment and later to master, rather than scheduled release branch cuts, so that only accepted topics make it to master. We don't quite have enough test coverage to make me comfortable with full TBD, either :(
    – Alex Ball
    Apr 16, 2020 at 21:52
  • I think this explains my current idea best: medium.com/@sairamkrish/…
    – Alex Ball
    Apr 16, 2020 at 22:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.