what I have
We have two teams with different release cycles. The teams work in the same solution, but don’t change the same files.
We have a developer team that uses 2 week sprints and delivers after each sprint. After the sprint is done, they will create a release branch and release to the Test, Acceptance and eventually Production environment.
We have another team, called implementation, that continuously delivers. Their work is less prone to bugs, so they skip going through the Test environment completely. Their work needs to be released to the Acceptance environment as soon as possible to show customers their upcoming changes, and they want to release to Production environment every a week.
what I want
We want to implement a gitflow based way of working to accomplish the above. So the Acceptance environment gets releases once every 2 weeks from the developer team, but continuously gets releases from the implementation team. And the production environment gets releases every week, one week from both development and implementation, and the other week only from implementation.
The challenge is that when the implementation team wants to release changes to the Acceptance or Production environment, I don’t want to release any untested or unaccepted changes from the develop team.
my proposal
Now I have thought up a branching strategy based upon gitflow, but with a second long lived branch next to develop named impl (see image below). Once a week I create a release branch, one week based from the develop branch (yellow arrows in image) and the other week based from the impl branch (blue arrow in image). Once changes are released to Production environment, they end up on the master branch and get backmerged to both the develop and impl branch.
my question
But I’m afraid I’m doing something dangerous here. My question is, will this branching strategy work, or will it sometimes lose earlier changes because the release branches get pull requests from different ‘parents’?
For example, the changes that the develop team has done in the first two weeks, will end up in the develop branch at the beginning of the third week. At that moment, those changes aren’t yet available in the impl, or production branch.
The develop changes now go to a new release branch (from ‘2’ to ’10’ in image). So now when the impl team pushed another change to the release branch (from ’16 to ’12’ in image), should I fear that the develop changes will go lost? Because the release branch first got changes from the develop branch, and later got changes from the impl branch that doesn’t yet have the develop changes?
PS. The black boxes with ‘T’, ‘A’ and ‘P’ indicate pipelines releasing to the Test, Acceptance and Production environments.
nl-x is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.