Branching strategy with GitHub releases

Question

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 a new feature from the 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?

Answer 1

You need to work out under which conditions feature branches can be merged. A typical case is when the feature is fully implemented, and automated testing via CI passes.

That means it's up to the automated testing to ensure that the feature is ready for testing by QA on the release branch. That in turn implies the feature should not be merged unless QA can test it prior to release and deployment.

That is, your process contains these stages (well, the part of the process we're talking about here):

1. Development (feature branch)
2. CI Testing (feature branch)
3. Merge feature -> release
4. QA Testing (release branch)
5. Merge release -> master

By writing it out this way, you can see that each time testing occurs is prior to a merge. If you think of the process as a state machine, the branches are the states, merging is a state transition, and testing checks the conditions whether a state transition may occur.

Make sure to define your conditions accordingly.