How do you deploy and test a hotfix repo branch in different environments, Git Flow variants

Question

I have done thru where do bug fixes go in git flow and the git flow and github flow pages.

There are scenarios many times when we need to show demo of new functionality and on same day fix issues of prod. So for a few hours have one branch in QA and for a few hours another.

Or pushing to beta/ UAT we want to test in staging/ QA env. But our pipeline auto builds master branch push.

Wanted to know what others do? Do you pause the pipeline's trigger and have a parameterised pipeline so that you can trigger it manually and specify the branch that you want it to use?

This is not about git flow as it is about automation, testng and devops process to acheive this.

Answer 1

Yeah, although the hotfix itself will be merged back into master at some point, unless you have multiple, or spin up on demand test/QA environments, you will need to switch your CI/CD pipeline around a bit.

I keep the deployment step manual rather than triggering automatically. Unless you are super confident in your super ninja trunk based mono repo CD pipeline, its nice to have a human pulling the trigger on deploys.

This gives you an intercept point where you can say... you know what, actually deploy this branch build, thanks.

Hopefully your approval/audit stuff is still there and people are actually checking to make sure this isn't abused to deploy feature branches to live without testing etc.

But you know... try it occasionally to see if they are

• Greg Burghardt: Many CI/CD solutions allow you to specify approvers for deploying to each environment. This helps prevent people from circumventing process and paperwork.

Answer 2

This is not about git flow as it is about automation, testng and devops process to acheive this.

You say that but the reason why you are having this problem is a Git Flow-specific assumption about "production":

But our pipeline auto builds master branch push.

From the article:

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

Helpfully the article likes using "per definition" (italic theirs) so there can be no confusion about what the current "production release" is. And you seem to be following that.

So you cannot just use a "always build master automatically" rule as the only way to deploy. You need more.

• You cannot use that rule for staging and QA since that would mean that building for QA would make a new production release (by definition)
• You probably also don’t want to make a merge to master (and hence make a new version release) just for a demo

You need some extra flexibility.

If you want to stick to some branch rules for deployment then you need to make some new branches:

• QA
  • Or QA/dave, QA/philip, etc.
• demo
  • Or demo/susans-showcase, demo/carls-weekly-hangout, demo/for-finicky-customer-X

merge --no-ff from develop into those optional.

Answer 3

For Git Flow specifically, the following practice works well most of the time:

1. release branch is always deployed to QA.
2. Any time master is updated, hotfix is automatically updated with git merge --ff-only origin/master. The only time that fails is if a hotfix is pending and hasn't been merged into master yet.
3. This is the key point: When a hotfix is pending, merge hotfix into release. Then you perform step #1 (release is deployed to QA) and then QA contains both the release and the hotfix.
4. Validate the hotfix change on QA.
5. Merge hotfix into master and deploy master to Prod.
6. Optional: merge master into release with --no-ff. This is optional because it won't bring in any changes, but will instead bring in just the latest merge commit on master, which your pipeline might depend on for confirming your release branch is fully ahead of master before deploying to Prod.

The reason the first sentence says this works "most of the time", is every once in a while the hotfix is to fix something that a new feature replaces, in which case you wouldn't be able to test both the hotfix and the new feature simultaneously in the merged release branch. In my experience this is rare though.

Side Note: You mentioned GitHub Flow as well, and in that case, either QA is currently vetting the new master branch, or it's vetting some feature branch. If it's master, presumably your release cycle is fast enough that you can treat the hotfix as a regular feature- just merge into master and update QA with the new master. If it's a feature branch, then the workflow is identical to what you do in Git Flow above. (Just create a second feature branch off of master and merge that into the feature branch which is being vetted on QA, etc.)

Answer 4

! Deploying and testing a hotfix repo branch in different environments can vary depending on the Git Flow variant being used. Here are some general steps that can be followed for two popular Git Flow variants: Git Flow and GitHub Flow.

Git Flow Variant Deploying a Hotfix Branch Create a new hotfix branch from the production branch. Make the necessary changes to the hotfix branch. Test the hotfix branch locally to ensure that the changes work as intended. Merge the hotfix branch into the production branch. Deploy the production branch to the production environment. Testing a Hotfix Branch Create a new hotfix branch from the production branch. Make the necessary changes to the hotfix branch. Test the hotfix branch locally to ensure that the changes work as intended. Merge the hotfix branch into the production branch. Deploy the production branch to a staging environment. Test the changes in the staging environment to ensure that they work as intended. If the changes pass the tests in the staging environment, deploy the production branch to the production environment. GitHub Flow Variant Deploying a Hotfix Branch Create a new hotfix branch from the main branch. Make the necessary changes to the hotfix branch. Test the hotfix branch locally to ensure that the changes work as intended. Merge the hotfix branch into the main branch. Deploy the main branch to the production environment. Testing a Hotfix Branch Create a new hotfix branch from the main branch. Make the necessary changes to the hotfix branch. Test the hotfix branch locally to ensure that the changes work as intended. Merge the hotfix branch into the main branch. Deploy the main branch to a staging environment

• tgkprog: hi thank you for your answer, but my question was not about the brancing but about the pipelines and automation. softwareengineering.stackexchange.com/a/444528/86679 is closer answer to my question
• Guildenstern: What sources did you base this answer on?