1

We are working using Agile methodoly and we need to deploy our code into three environments (DEV / UAT / PROD). Only Features validated in UAT can go in production at the end of a sprint.

To do so, we are currently using 3 branches: master (which goes to PROD), release (which is not deployed or only in QA env' to validate the package) and pre-release (which is deployed in UAT). 'release' is a fork of 'master', and 'pre-release' is a fork of 'release'.

Branching: Master --> release --> Pre-release

Development: release --> Feature Branch 1-X

Deployment: feature branches --> dev environments pre-release --> UAT env for validation release --> staging master --> production

Once a dev is starting to work on a user story, he is creating a feature branch, based on 'release', and once the dev is done, a pull request to pre-release is created. After this step, we only want to have in 'release' validated feature by the Testing team, so once the feature is validated a Pull Request is created from the Feature branch to the 'release' and at the end of the sprint a PR is created from 'release' to 'master' in order to be deployed in production.

Is this behavior logical? Currently we are having huged conflits on PR from Feature Branch to pre-release. Is it normal or do we need to do something else?

What is the best approach?

Orkhidion
  • 11
  • 1

1 Answers1

1

In an agile approach we want to be able to react quickly to change. To achieve that we want to release our work incrementally and to keep our release pipeline as short and as simple as possible.

A great way to achieve that is to keep the master branch releasable at any time.

It is fine to have the developers do work in branches, but the aim is to bring those branches back to master as quickly as possible.

To make this work you may want to consider:

  • UAT testing small bits of work, as and when they are ready
  • Using automated regression testing, run from continuous integration to continually validate that your master branch is in good shape
  • Using feature toggles to allow code to be merged to master even before it has been UAT tested and still retain the ability to release from master
  • Use continuous integration to frequently merge master into branches so that branches never drift far from the master branch

With this approach your branching strategy is simpler and less likely to cause merge conflicts. It also means you can change priorities quickly, release bug fixes quickly, etc.

Barnaby Golden
  • 4,176
  • 1
  • 23
  • 28