Gitflow workflow alternate branching strategy

We must have worked on various git workflow by now and we all know there are various issues with them. If you want to read more about other flows, here is the link

Major Workflow we generally use

• Centralized Workflow
• Feature Branch Workflow
• Gitflow Workflow
• Forking Workflow

So what are the issues

How we can deploy changes on the test environment for testing/UAT signoffs?

Possible solution

Deploy the feat branch on some server and test your changes there. We can create a strategy to access the application by appending the branch name in the app URL something like this

https://<appUrl>/<branch>/

Issues with the solution:

• It can work if features require changes in a single repo, But if changes require multiple services, then URL needs to be updated to connect the feature branch application.

Updated Gitflow Workflow

Proposed Solution

• We can have a custom branch(say develop) which on any commit, deploy changes on a test environment.
• A dev will create a branch from master
• He Will do his changes on his branch and commit changes
• He will merge his branch to develop a branch which will deploy his code onto the test environment.
• Dev will test his changes on the test environment and verify integration with other services is working properly or not
• Upon successful verification, the dev will create PR to merge to master
• Upon merge to master, code will be deployed onto the integration environment automatically.
• Since we have verified our changes in the test environment, we can also think of removing the manual trigger for prod deployment.
• A new job has to created to look for changes in develop branch and deploy on the change to the test environment.

Precautions

• Dev has to cut a branch from the master only
• Dev has to take a pull from the master branch only
• In case of a merge conflict, while merging with develop branch, he has to checkout to "develop" branch, merge his branch, and resolve conflict in develop only.
• if Dev takes a pull from the develop branch or merges develop to his branch, then other devs changes will become part of his branch changes and will be shown in his PR.

FAQ

Since multiple branches get deployed on test via Develop, how can we test our feature in isolation?

• We have already tested our feature in isolation while developing. Since on local, we have only our branch, not other branches.
• Conflicting deployments are more frequent than conflicting features. Conflicting deployments here means if 2 features are merged to master and being tested and one is ready for prod deployment while the other is not, then the other needs to be reverted before deploying master to production.
• Conflicting features are rare, there can be conflicting files that can be resolved by properly merging code to Develop branch.

What will happen if Develop contains changes that are never intended to go to production?

• We can always reset develop branch from the master by deleting the branch and create a new one from the master. And ask developers to merge their branches again to start UAT or testing.