Branching strategy - for multiple release with gihub

user_2504762 0
Viewed 100

I am working on the project where currently we have following three fixed branches 

Develop - The code is deployed to development environment. It's a base branch for anyone who want to add new feature. 
Release - Deployed in QA environment, And QA can start testing on.  
Master -  Deployed to Production environment and available to clients.

And we have two more dynamic branches, feature and hotfix.

  1. Anyone wants to start new development or bugfix, forks new feature from develop branch, then then creates a pull request.

  2. once development is done it's testing in Development environment from develop branch it then creates a merge request for release branch

  3. QA deploys the release branch on Test environment and start testing, once testing is done. it's merged to master and then deployed to production.

This all works well for most of the part. However, it has following problem

Not every feature in QA (release branch) is tested and ready for deployment (merge to master) at the end of the release. And so we are not sure how to create a pull request as it will select all the commits.

I am thinking Github releases might be a solution for this. I can create a new release with which ever feature is ready for deployment and then merge these releases with master branch.

However, what I am not sure is when to deploy to production, from releases or from master ?

github
1 Answers

You should be following the standard Git Flow:

Git Flow

Instead of merging any feature to the release branch (from develop) after testing, what you'll want to do is make use of a 'release cut'. This is a dedicated point in time at which you decide you want to make a release. Features that are planned to be in this release are evaluated and tested, and the release is confirmed.

You'll want to tag your releases, and optionally include any assets that are associated with that release for future reference. If it's a mobile app, this is a great place to include your .apk or .ipa. After the release cut has been made and tagged, you'll then want to release the release branch to production. Once that has been deployed out to production, you'll then want to merge release into both master and develop.

Under this approach, every feature branch will end up in develop, then release (with a corresponding tag), then master. If a feature is still in progress when the release cut is made, it simply doesn't make the cut! It will get added to the next release. This will give it adequate time for testing before it comes anywhere near release, let alone master. In this regard, master should be a mere representation of your last-known 'good state' -- a point at which you were happy to release to the public.

Also, note that hotfixes and bugfixes are two different things, and neither should branch from develop. Bugfixes should be made to the release branch itself, and hotfixes should be created from master, and merged back into both master and develop.

user_23416030
Related