ways of deploying master - benclifford/text GitHub Wiki

different strategies I have encountered:

• build master. if it builds, deploy automatically. master can be broken because although testing on a branch, the actual merge of master and branch has not been tested before this.

• only allow master to be fastforwarded to a commit that has already been tested (i.e. on a branch). Can lead to playing catchup on a busy master. But once you've got something on master, it has already been tested and can be deployed right away, with no further testing.

• build master. if it builds, tag it 'green'. separate manual action to deploy, which deploys 'green' rather than than 'master'. so green has the effect of being a branch that follows along behind master and, in the absence of ongoing development, catches up to it. having a manual deploy can lead to: "I know its a bit broken, but thats ok because we won't deploy it yet" rot.

fascist strategy i'd like (but expensive): every commit has been tested before it is allowed to be present in the history of master. encourages squash merging. makes bisecting more useful.