0

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?

  • Github releases are essentially just a git tag, i.e. a label for some commit. That won't help you with any QA process. – amon Jul 12 at 15:48
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.