* Re: Hotfix Branching Strategy
2019-02-12 5:21 Hotfix Branching Strategy Roman Gelfand
@ 2019-02-12 9:21 ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 2+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2019-02-12 9:21 UTC (permalink / raw)
To: Roman Gelfand; +Cc: git, demerphq
On Tue, Feb 12 2019, Roman Gelfand wrote:
> At any one time, up to 3 developers could be developing hotfixes
> addressing issues. Whether it is one or multiple people working on
> hotfixes, we always want to produce one hotfix. Each hotfix is a
> cumulative update since beginning of release. Just about every hotfix
> requires database upgrade. Being that it is cumulative each developer
> is dependent on the other. Considering the requirements, what should
> be a strategy to deal with this problem.?
Requirements differ, but you may be interested in the strategy we
(Booking.com) use in git-deploy[1]. It hasn't been updated in a while,
but the hotfix logic is there.
Basically:
1. You have a "master" branch where new development happens
2. When you make deploys to your systems you deploy latest (or recent)
"master". This creates a dated tag like foo-YYYYMMDDHHMMSS or
bar-YYYYMMDDHHMMSS to deploy to the "foo" or "bar" set of servers.
3. Instead of "update to master" you can also "hotfix" which starts a
session where you (usually!) cherry-pick from "master", but you can
*also* make new original work.
Now, the critical thing is that when you sync out #3 we perform the
following dance:
A. Fetch latest upstream, origin/master
B. Make a note of the SHA-1 of the hotfix we're about to sync (let's
call this X)
C. Merge our X into origin/master
D. Push our merged origin/master+X to upstream origin/master (see [2]
for some plans to make this easier)
E. "git reset --hard X". We want to roll out our hotfix, not the merge
with "master"
F. Sync out our "X"
What this ensures is that:
* After hotfixing e.g. "foo" a new deploy of "bar" will include the
hotfix, since we pushed it upstream to master. Thus hotfixes
(including "live" work") don't get forgotten. Imagine a critical bug
discovered & fixed in "foo" during an outage, you don't want a new
deploy of "foo" the next day to regress. Merging upstream to "master"
is critical.
* Since you need to resolve the merge conflicts with origin/master, if
any, things like conflicts due to e.g. DB schema versioning need to
be resolved. E.g. in many cases your conflict with master will
require bumping a "serial" to a value that before the hotfix didn't
exist.
* You can do deployments where multiple hotfixes to a system are
stacked one on top of the other, not as any specially supported
thing, just as an emergent property of a "hotfix" dropping you into a
session where you start with the current rollout, then you can
e.g. cherry-pick on top of the "X" hotfix to produce "Y" etc.
* All deployments ever are merged into "master" including hotfixes, so
you can eventually prune the dated tags, and can just "git log" on
master to see all deployments ever (as opposed to "git log --all"
etc. which would also give you topics...)
So that's one approach.
The other thing people tend to do is to make a release, and at the same
time create a release branch, if they need a hotfix they develop on top
of that
That's also a valid strategy, but I think most shops that do that tend
to invent something to emulate what I've outlined above. I.e. now you
have a "foo" and a "bar" release while "master" is moving forward, and
need to cherry-pick and merge between them to make sure your next
release of "master" doesn't regress.
1. https://github.com/git-deploy/git-deploy
2. https://public-inbox.org/git/87sh7sdtc1.fsf@evledraar.gmail.com/
^ permalink raw reply [flat|nested] 2+ messages in thread