I have the following scenario:
We are using a feature branch workflow and containers.
Team A's developers create branches (from master/main) to work on features, and once they are finished, the code is merged with the release branch. Commits on the release branch start a pipeline to build, run tests and deploy the containers to the staging environment. After user approval, the container is "promoted" to production and the developer merges the release branch with the main branch, creates the tag and the job is done.
This works fine, except when we need a hotfix.
While team A's code is in the staging environment, team B starts to work on the "hotfix" branch, and their commits also start a pipeline that runs the build, tests, creates a container, and deploys to a special staging environment, let's call it "hotfix-stage". At this point, we have 2 containers of the same project, with different codes being validated.
If team A's container is approved, it is deployed to production, but if team B's container is approved, it is also deployed to production. The problem is that Team A's container is going to production without the hotfix, and team B's container does not have the features from team A.
Team A and Team B are different companies, each with its own SLA. They don't want to merge the "hotfix" branch with "feature" branch (or the "release" branch).
Is there a git workflow that can solve this?
In git flow feature branches should be started from develop branch.
When it's time for a release a release branch is created from develop. If a bug is found during the release fase then a fix branch is created from the release branch, when the bug is resolved the fix branch must be merged both into the release branch and into the develop branch (that can evolve in the meantime). You can do this for all the bugs found during qa.
If a bug is found into a previous release then a hotfix branch must be started from main and closed into develop. If there is a release branch in that moment you can choose if you want to release the hot fix as well.
When things seem stable a tag on the release branch is created, this is the release. You can also use release candidates tags and then tag the final release candidate.
When the release is done you can close the release branch into main, during all this time develop can evolve and recieve bug fixes