5

I'm implementing Gitflow at the company I currently work for and everything is going pretty well. I'm just not completely sure if I'm dealing with more than one release on the pipeline at the same time in the best way

Our systems have 5 environments as follows:

  • Develop: deployed whenever there is a merge into develop. Used for integrating other systems at dev-time
  • Internal Test: deployed whenever a new release branch is created from develop. Used by QA team
  • External Test: deployed after QA team gives their ok. Used for key users of the system to have a look and aprove what was done.
  • Production: deployed whenever something is merged into master
  • Mirror: deployed whenever something is merged into master. This one is a carbon copy of production for helping us debug production bugs in a safe way. Basically a sandbox with same code as production and the production database of the day before (except for some sensitive data being scrambled)

The problem I want to solve: While release 1.0.0 is being tested by external testing, I may already deliver a new release 1.1.0 into internal testing. But if the external testing finds something that needs to be changed in 1.0.0, this should be applied recursively back until develop, where we are already working on 1.2.0.

What we do today is merge 1.0.0 into 1.1.0 and develop after those changes and send it back to internal test, pausing tests on 1.1.0 in the meantime.

Same idea for hotfixes. I may have 1.0.0 in production and have 1.1.0 being tested. But suddenly I have to fix a prod bug, so I create a hotfix branch from master that will generate release 1.0.1. Today we merge that into 1.1.0, develop and master.

Does any of this make sense?

Is there any better way of dealing with this?

Thanks

Edit:

The original article about Gitflow already has a solution for the Hotfix problem:

[...] when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)

Improve this question
2
  • Is there a reason why you have so much work in progress? It's one thing to move forward with development when there is external testing happening, but is there a need to support 1.0.0 in production, be externally testing 1.1.0, internally testing 1.2.0, and developing 1.3.0?
    – Thomas Owens ♦
    Commented Oct 27, 2020 at 20:37
  • The reason is that the testing phases might take a while. Our QA team is small and we give support to a lot of applications at the same time. Meanwhile, the external testing can take a while as well because those people have their own daily jobs completely unrelated with IT. They are managers, receptionists, professors, etc. We do have a lot of work, but the reason for the eventual moment in time where we can have 3 different non-prod versions around is how slow the testing phases work. It is not a too frequent scenario, but it does happen from time to time.
    – Guilherme Taffarel Bergamin
    Commented Oct 27, 2020 at 20:58

2 Answers 2

Reset to default
2

The process you described makes sense, especially if it is fairly rare that you have multiple active release and/or hotfix branches at the same time.

To keep the merging controlled, you could make the agreement that bugfixes on a release (or hotfix) branch are only merged to other release branches after QA gives their ok for external test on that branch.

According to Gitlow, the merge to develop should happen at the same time as the merge to master, unless there are pressing reasons that the fix is needed sooner on develop. You can choose to do the merge to develop also at the time that the release branch is made available for external testing.

Improve this answer
1
  • That makes sense. Maybe I should just avoid immediately merging it back into develop and just merge into the next active release (which usually won't be more than 1), except of course in case it affects develop in a way it requires being merged there.
    – Guilherme Taffarel Bergamin
    Commented Oct 28, 2020 at 14:45
4

It sounds like you work on a web application, or something similar in the sense that only one version is typically used at a time - whatever was last deployed to production. Given that, I'd suggest that Git Flow is probably not a good fit. As Vincent Driessen, who originally described Git Flow writes:

... Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

My suggestion would be to look instead for some form of trunk based development.

Improve this answer
5
  • You are correct. Most of our applications are web apps and we rarely have to rollback a whole version. I am aware of that other way of versioning, but we decided for Gitflow due to how our versioning was already looking like before that. Having a develop branch helps a lot with automating our development environment for instance (beforehand we had to deploy a feature branch and that would kill other people's changes to dev env). If only Vincent had posted that reflection a couple months earlier, I would have seen that when I was researching about git and git branching models...
    – Guilherme Taffarel Bergamin
    Commented Oct 27, 2020 at 20:20
  • Anyway, Gitflow is what everybody agreed on and our pipelines are following that right now. It has been working very well. My only concern is this "detail" that seems to be missing from Vincent's article (he assumes there will be only one release branch at any time). Though now that I looked into it again, the hotfix problem is in the article. He merges the hotfix into the release branch. The release branch will eventually be merged back into develop bringing the hotfix with it.
    – Guilherme Taffarel Bergamin
    Commented Oct 27, 2020 at 20:43
  • 1
    Just to be clear, even though the other answer is the one that solves my problem, I would like to add to anybody researching the best way of versioning their projects to consider that Gitflow might not be the best alternative for their reality. This answer brings value to the discussion and should be considered. That's why I'm +1ing this one as well.
    – Guilherme Taffarel Bergamin
    Commented Oct 28, 2020 at 14:54
  • 1
    Thanks GuilhermeTaffarelBergamin
    – bdsl
    Commented Oct 28, 2020 at 15:09
  • 1
    just a follow-up. After some time, we ended up changing our branching model to a completely custom one. We don't follow GitFlow anymore, but also not trunk-based development. We work on release-based branches that are sort of like "the master of that release" and that release is going to pass through the environments deployment pipeline. It's much easier to remove a feature that was already completed if it becomes canceled before the release is released without affecting the actual master
    – Guilherme Taffarel Bergamin
    Commented Jul 6, 2022 at 18:52

Your Answer

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

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