Git branching model strategy

Question

We are trying to follow the gitflow branching model, but with a twist.

We have have four servers environments where the product can be deployed to, each server serves a purpose : development, internal testing, external testing, and production.

• DevServer, where developers test their different features, while developing. Developers cannot test locally on their machines, they have to make their changes on the DevServer to be able to test
• TestServer, where QA testers test multiple features once developers are done
• ReleaseServer, where releases are tested in isolation before moving them to production
• ProductionServer. The production server

We are trying to make the merging / conflicts resolution as easy as possible, so we created two extra branches which is not part of the gitflow model.

Normal gitflow branches

• develop
• master (matches 'ProductionServer')
• featureXXX
• releaseXXX (weekly releases are deployed to 'ReleaseServer')

But also these two branches which is not standard and might need to change...

• dev-release (copy of DevServer)
• test-release (copy of TestServer)

Then process is then as follow:

• developer create their 'featureXXX' from 'develop'
• multiple developers merge their different 'features' into 'dev-release' branch, and 'dev-release' branch gets released to the 'DevServer' where all the developers can then test their different features. Not all these features will be in the same next release
• Once the developers are happy with their dev testing above, they merge their 'featureXXX' into branch 'test-release', and this gets deployed to 'TestServer'. Not all features here will be part of the same next release.
• Once testing on 'TestServer' is done for featureXXX, the developer can close their featureXXX into 'develop'.
• Developer then either create a new 'releaseXXX' or merge their 'featureXXX' into an existing 'releaseXXX'.
• The 'releaseXXX' branch is deployed to to 'ReleaseServer' and tested.
• Once 'releaseXXX' testing is signed off, 'releaseXXX' is merged into develop and master, and deployed to 'ProductionServer'

Are we messing up the whole gitflow model?

Here is our brancing process:

Answer 1

To answer your question, no you're not messing up the gitflow model - more extending it to meet your needs.

By coupling environments to a given branch, you're giving yourself much more flexibility when it comes to building releases. i.e. lets say you have two non-dependent features (Feature 1 and 2) in progress, both of which have been merged into your 'TestServer' branch. If Feature 1 fails testing, Feature 2 can still be progressed further without Feature 1 - this is because your merge into 'TestServer' is a one-way merge - nothing comes out, no history. Instead, your Feature 2 branch is merged into 'develop' and eventually 'master'.

We're in the process of adopting/developing a similar strategy to yourself. The key requirement for us is to accommodate the unavoidable cherry-picking of features. Note that our solution, although rather complex, has been designed for an enterprise application, serving as a platform for multiple services owned by multiple business-owners and utilise multiple in-house frameworks..

Environments

• QA: for developers to ensure that their feature is testable.
• Stage: for project managers / test managers to smoke-test prior to UAT testing by the various 'Business Owners'
• UAT: for full testing and business sign-off by the 'Business Owners'
• BETA: merely a test of deployment/release
• LIVE: ..

These environments are grouped into two categories, 'in-test'(QA, Stage and UAT) and 'production' (BETA and LIVE).

Branches

Feature prioritisation can change often, from testing issues through to regulatory restrictions/requests. To accomodate this, multiple branches are created to represent the environment/categories as follows:

• Master: Represents the last production release
• Release-Candidate: A collection of features for the next production release
• UAT: Represents UAT environment
• Stage: Represents 'QA' and 'Stage'
• Feature-xxx: For feature development

We also utilise a HotFix branch from Master as required, and prepare production releases in a 'Pre-Production' branch (correcting missed version increments etc - minor stuff).

A diagram of our Branches in use:

Branching and Merging / WorkFlow

1. We always branch new Features from Release-Candidate as this branch always contains the 'Committed for production' features. Nothing leapfrogs once the commitment for production has been made.

2. Once a feature is ready for testing, it's merged (one-way) into 'Stage'. This triggers a CI build and deploys to QA.

3. If the QA server looks stable, the developer triggers an automatic deployment to Stage.

4. If changes are required then make them in feature and repeat. If OK for business testing, then merge from Feature to UAT. This deploys to UAT.

5. If feature fails business testing, then make changes in feature and repeat. If feature is delayed then take no action. If feature is OK and signed-off, then merge to Release Candidate.

6. Once collection (1 or more) of features are in Release-Candidate, trigger production deployment by merging from Release-Candidate to Master (via Pre-Production).

7. Deployment failed, then HotFix. If OK, deploy to Live.

Our workflow, using TFS, looks like this:

Release workflow

And finally, each deployment to an environment/category would look like this: