I’m working currently with the customer who wants to accept separately all the things that are put into production. All bug fixes, features and even config changes. Good thing about this is that customer only gets changes what they really want to into production and they have deep knowledge of what is happening in their software. However this brings some challenges into version control and branching strategy, because features and fixes needs to hand picked.
We have solve this problem by moving into two branch strategy, where master branch is the production branch and the test branch is the UAT branch where features and fixes are tested.
When we start a new development, we first create new development branch from master. When development is completed, reviewed and tested, branch is merged into test. Customer does their acceptance testing in test environment and if the feature is good to go, they will indicate that into work item tracking system (Youtrack). All accepted features are then transferred into master with pull requests. At this point we also delete the development branch.
There are few downsides of this strategy though:
- If feature is never accepted into production it will still stay in test. They could be of course easily reverted from test, but the practice has shown that they are also easily forgotten.
- master needs to be merged into test periodically. In practice people will do minor fixes and merge conflict fixes into master, so they need to be synced into test. Otherwise test will crawl away from master too much
- Test should NEVER be merged into master, because this will bring all the unaccepted changes from test to master.
We have found this branching strategy to work really well for this use case. We rarely have any problems with branching and because number of developer is quite low (3-5), we rarely get any merge conflicts.
Huge bonus in this strategy vs. master-test-production strategy is that master is the production. So every development starts from production state.