How to structure git workflow for multiple features with different timelines for production?

Question

I am new to Git. I am trying to learn it and implement it in my environment. I am working on a dashboard that has 2 features that developers are working on in my team.

Workflow

3 branches in the repository: Development, Testing and Production.

• Developers work on fixes for features in separate branches.
• Once fixes are implemented, they are merged into the testing branch for the corresponding feature and deployed to the testing environment for testing.
• After testing is complete, the branch is merged into the development branch.
• Once the feature is ready for production, the development branch is merged into production and then deployed to the Production environment.

Type	Time0	Time1	Time2	Time3	Time4	Time5
Status	Start of the process	Both features moved to v1	Testing complete	FeatureA moved to v2	FeatureA is ready for release	FeatureA v2 in production
Action			Merge testing to development		Merge testing to development	Merge development to production
Development Branch	FeatureA v0 FeatureB v0	FeatureA v0 FeatureB v0	FeatureA v1 FeatureB v1	FeatureA v1 FeatureB v1	FeatureA v2 FeatureB v1	FeatureA v2 FeatureB v1
Testing Branch	FeatureA v0 FeatureB v0	FeatureA v1 FeatureB v1	FeatureA v1 FeatureB v1	FeatureA v2 FeatureB v1	FeatureA v2 FeatureB v1	FeatureA v2 FeatureB v1
Production Branch	FeatureA v0 FeatureB v0	FeatureA v0 FeatureB v0	FeatureA v0 FeatureB v0	FeatureA v0 FeatureB v0	FeatureA v0 FeatureB v0	FeatureA v2 FeatureB v1

The problem that I am facing with this workflow is that at Time5, the production branch has FeatureA v2, FeatureB v1 but ideally I want it to be FeatureA v2, FeatureB v0. This is because only FeatureA is ready for production and FeatureB is still in testing phase.

My desired output at Time5 for production branch would FeatureA v2 FeatureB v0.

What am I missing in my workflow? How do I manage my workflow deployments when developers are working on multiple features but different timelines for release to production? Can someone point me in the right direction?

Answer 1

There's a contradiction in your workflow

You say:

My desired output at Time5 for production branch would FeatureA v2 FeatureB v0.

yet in Time1 you have both FeatureA v1 and FeatureB v1 pushed to Test.

If you want to be able to release feature changes into production independently, you must test them independently. Otherwise you are not testing the exact code you putting into prod.

Since the path must be: dev --> test --> prod, and since from your chart it looks like you have only one test team, then only one feature branch should be merged into Test at a time; the others will have to wait.

Nix the Development branch. Having both doesn't buy you anything

I'm not sure what role the Development Branch in your workflow plays. The only point of having a Development branch is so that you can integrate separate feature branches that are going to be released together. But you want features to be released to prod totally independently, so it doesn't make sense for you.

If you want to keep each feature's development, test and release to prod independent, they have to stay separate until tested and released to prod! In your workflow in Time1 you merged two features into Test... So (1) you are not testing them separately making it unsafe to push to prod separately and (2) if you merge them you can't push only one to prod anyway!

Merging your features branch changes into each other introduces a lot of complexity, as explained in Topic branches. So it is better to keep them separate until production. When a feature does goes into production, or into pre-production, passes testing and is scheduled to go into production, only then do you merge that feature into all the other feature branches (simplest approach is to rebase all feature branches onto the tagged commit in Pre-production).

If you need to occasionally make sure the features are compatible, you could use a Throw-away integration branch.

See 5 Git workflows and branching strategy you can use to improve your development process. Essentially I'm telling you to use the Git Feature Branch Workflow and not Git Feature Workflow with Develop Branch, except you will have a Test or Preproduction branch that all changes to Production will go through.

Just have a Pre-production branch for testing

My suggestion assumes you have only one test team. Even if you have multiple, because of your desire to push features to prod independently, you really have to test things in the order they are pushed to prod. For example if A is to be release before B, A must be tested in isolation, then A+B must be tested. If you reverse the release order, you have to redo all the testing (first B, then B+A).

The simplest solution is to have one Pre-production or Test branch (either name works).

• Feature X branches, e.g. FeatureA and FeatureB

  These branches should always include the latest production (via merge or rebase).

• Pre-production branch

  Features that considered done and candidates for production are merged into Pre-production and tested before being pushed to Production. For example:

  Say FeatureB v1 is ready first. It is merged into Pre-production and the branch is locked from further changes while testing is in progress. If tests pass, and a tag is created to mark that commit as having passed tests and OK to be merged to production.

  Now FeatureA v1 or FeatureB v2 can be merged into Pre-production and undergo testing without having to wait for FeatureB v1 to be merged into production because the tag created marking the tested code allows you to push only the tested code into production. FeatureB v1 can be pushed to production on its own, or you can wait until some more features pass testing to do a larger rollout of features.

• Production branch

Other Workflow models

If you need something more fancy, there are plenty of workflow designs you can find on the web.

• Gitflow: A successful Git branching model

• Git Feature Branch Workflow

See also gitworkflows and 4 branching workflows for Git.