Git workflow with continuous deployment team

Question

I'm struggling with finding the best branching model for my team and would like advice on what branching models will work best.

We have 2 enviroments - Test & Production. I recently started to work with "nvie gitflow" with my team, without the release branches - so we have a develop branch that is the Test enviroment, which all feature branches are merged to it, and master which represents our production environment.

When a developer finishes a feature - he creates a pull request and merge it to the develop branch, and after the merge a new release is deployed to Test enviroment.
When the QA team approves the feature, we cherry-pick all the commits from the pull request and creating a new pull request, now to master. We do that in order to control which changes will be deployed to production.

Everything works really good except the cherry-pick to master - we often deploy code that depends on other code which is not on master, and our deployment fails.

I look for a way which we can control the code that is deployed to Production but also handle the dependencies between code sections. I tried to merge the feature branch to master but in this way a lot of unneccsary changes are committed also.

Answer 1

I tend to find it works well to treat develop as a sandbox that you want to keep in order. Yes, you want to use it to store all of your features merged from other branches, but you also have a goal of making it into a product that QA can accept and move-wholesale into the production branch. If a feature isn't earning it's keep, you may want to actually move it out of develop and into its own branch, just to keep develop clean enough to take wholesale.

Treat develop not as the ending point for developed changes, but as the starting point for selling those changes to QA. Work with them to find out what kind of repository-fu is acceptable to them, and what is not. For example, if you have a feature that shouldn't go in develop, but got in there anyway, figure out what QA wants to see to be convinced that the feature has been removed (and put in its own branch).

Depending on how rigorous QA is, you may need 2 develop branches. One is the version which is ready for QA to use, and one which the developers use internally. You keep this internal version "close" to develop. The idea should be that if QA accepts the changes on develop, then you and QA continuously progress in lockstep. However, if QA needs major changes (such as rejecting a feature), you need to be ready to nuke the developer branch (which is now far out of date), and recreate it from the last accepted QA branch. Expensive, yes. If you're in a business where QA is so strict that they're making it hard to develop, you're probably in a business that is willing to pay the cost to integrate the changes from your branches twice.

Answer 2

You need to deploy the same thing to the live environment that you had in the test environment. If you start picking and choosing code to deploy to live the testing becomes meaningless, since you tested a package as a whole and now you've built something different to push to live.

Give up on the idea of of 'controling which changes will be deployed to production'. If you don't want something deployed to production, just don't write the code for it in the first place.

Of course this doesn't mean that you have to give up control of what features get released to production. Firstly try to only write the features you want to release. Secondly remember that for many features there's a single line of code somewhere that can be deleted or put in inside an 'if' statement to inactivate the entire feature. In the worst cases you may need to use a 'feature toggle' system to turn off any features that aren't ready for release.