3 ms·

The fact is that this doesn't work for everyone. What we found to be most workable is master is always "stable", then we have a production branch that is cut fr

The fact is that this doesn't work for everyone. What we found to be most workable is master is always "stable", then we have a production branch that is cut from master. This gives you a few things: 1. More predictable deployments (let's deploy every week with X items) 2. Better rollbacks (rollback to last production deploy instead of guessing SHA1 of last acceptable state)

simplyinfinity 7y ago
we deploy to test multiple times a day from out master branch after a Pull request is reviewed & merged. the deployment bundle (zip of the state of the code) that goes to test later goes to staging and production is the same across environments. The only thing that changes is the configuration variables which are replaced at each env. This ensures predictable deployments and if we want to rollback we just pick the last release bundle and re-deploy that.
bfung 7y ago
My snarky version of this is: ideally head of master is deployable (no regressions, yadda yadda). In reality, how many times has head master of master been broken and one had to rollback, and then had to scramble to find the rollback? Gitflow is fine - better to use it (w/the girl extension) than spend time arguing branches.
- legulere 7y ago
  Having to frequently rollback changes can be argued to mean that you don’t do enough testing before merging but are testing in production.
gardnr 7y ago
The method you describe is functionally the same and only nominally different. It could be said: > What we found to be most workable is develop is always "stable", then we deploy from master.
debaserab2 7y ago
This is what I use tags for. Master = deployable state (stable) Every deploy gets a tag (named with its version). Rollback to previous tag in event of failure. Deployments remain just as predictable.
- mikekchar 7y ago
  I've also seen people have a single development branch and multiple release branches (imagine a 'devel' branch that everyone merges into and a branch for each release that you have, and that potentially merges back into devel if you do hot patches). It's essentially the same thing -- branches aren't really all that different than tags in git.
  - debaserab2 7y ago
    Yeah its basically aesthetics. I do like keeping the release identifier separate from branches though just for categorization purposes (branches = development, tags = releases)

simplyinfinity 7y ago

we deploy to test multiple times a day from out master branch after a Pull request is reviewed & merged. the deployment bundle (zip of the state of the code) that goes to test later goes to staging and production is the same across environments. The only thing that changes is the configuration variables which are replaced at each env. This ensures predictable deployments and if we want to rollback we just pick the last release bundle and re-deploy that.

bfung 7y ago

My snarky version of this is: ideally head of master is deployable (no regressions, yadda yadda). In reality, how many times has head master of master been broken and one had to rollback, and then had to scramble to find the rollback? Gitflow is fine - better to use it (w/the girl extension) than spend time arguing branches.

legulere 7y ago
Having to frequently rollback changes can be argued to mean that you don’t do enough testing before merging but are testing in production.

gardnr 7y ago

The method you describe is functionally the same and only nominally different. It could be said: > What we found to be most workable is develop is always "stable", then we deploy from master.

debaserab2 7y ago

This is what I use tags for. Master = deployable state (stable) Every deploy gets a tag (named with its version). Rollback to previous tag in event of failure. Deployments remain just as predictable.

mikekchar 7y ago
I've also seen people have a single development branch and multiple release branches (imagine a 'devel' branch that everyone merges into and a branch for each release that you have, and that potentially merges back into devel if you do hot patches). It's essentially the same thing -- branches aren't really all that different than tags in git.
- debaserab2 7y ago
  Yeah its basically aesthetics. I do like keeping the release identifier separate from branches though just for categorization purposes (branches = development, tags = releases)