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 serve

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: