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