Btukfyl

At my last workplace, we had a flow similar to "git flow" but we had three continuous branches instead of new release branches for every release.

• Develop


• Staging/Release (I'll call it release for remainder of the post)


• Master

We had automation in Jenkins so at any time QA could pull the full Develop branch into Release and begin testing the work that was available.

Any bug fixes to this work were done on the release branch to isolate the current build from unwanted changes on develop and were then merged back into develop once completed.

The idea was that the release branch was a completely isolated build and at any point in time if QA was happy with the state of the release branch, they could press another button in Jenkins and automatically deploy the whole branch into production and tag it.

• Develop was the history of work


• Release was a history of testable builds


• Master was official releases

At my new workplace I'm currently the only one working on my specific project, and there wasn't any automation or proper git flows set up so my plan was to continue using what I've been using for years, but other projects are using the standard Git flows and we've been discussing the differences and such.

In their flows - QA is testing individual tickets off of develop and only when an actual release is planned to be cut do they get put onto a new release branch for additional testing. From that point forward we follow the same flow where bug fixes happen on the release branch and are merged into develop.

We've been debating which way works better, but after having used my flow for years, I'm not able to find anything online that talks about it's strengths or weaknesses to help back me up and I'm wondering if there are problems with it I'm not aware of as it seemed to work really well? I'm either failing on my googlefu or surprised I can't find existing discussion? I also see a few problems with their way that mine would address?

With my current way

• I have a stable QA environment that can be released on a moments notice.


• QA never needs to be concerned about what's happening on Develop until they want new work.


• I have a history of unique builds on Release that can always be easily found


• I'm always merging from the branches head.

With the other way,

• By the time a build is tested, develop has already moved forward. If QA wants to deploy this build to production, they now need to pick a point in time and create a release branch from that (which can be error prone as it's not the branch HEAD anymore)




• One of our main test environments always represents the current develop code base, so when Develop breaks, the website breaks and can't be tested on.

Is there some flaw in the continuous release branch method that I'm missing vs the gitflow of individual release branches when a release is ready to be cut?

I feel like it's more straight forward to deploy to production with a continuous branch? Even if they stopped testing off of develop and created the unique release branch right away, what benefit does that have over a continuous branch that's been tagged?

Note - I was not the one to initially set this up at my last workplace and would be setting up the automation for my first time. Are their issues in the automation I would encounter in my method vs the normal git flow?