{"thread":{"id":"50477","subject":"Hotfix Branching Strategy","startedAt":"2019-02-12T05:21:50Z","lastAt":"2019-02-12T09:21:20Z","messageCount":2,"participants":["Roman Gelfand","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"369126","messageId":"CAJbW+rkn7wbRhDvRTtdp1aF5wd5PWHu9DqvPFm-BdVkR02Wgvg@mail.gmail.com","threadId":"50477","inReplyTo":null,"subject":"Hotfix Branching Strategy","fromName":"Roman Gelfand","fromEmail":"rgelfand2@gmail.com","sentAt":"2019-02-12T05:21:37Z","receivedAt":"2019-02-12T05:21:50Z","isPatch":false,"sender":{"key":"rgelfand2@gmail.com","avatar":null},"body":" At any one time, up to 3 developers could be developing hotfixes\naddressing issues.    Whether it is one or multiple people working on\nhotfixes, we always want to produce one hotfix.  Each hotfix is a\ncumulative update since beginning of release.  Just about every hotfix\nrequires database upgrade.  Being that it is cumulative each developer\nis dependent on the other.  Considering the requirements, what should\nbe a strategy to deal with this problem.?\n\n\n\nThanks in advance\n"},{"id":"369134","messageId":"874l99l5v8.fsf@evledraar.gmail.com","threadId":"50477","inReplyTo":"CAJbW+rkn7wbRhDvRTtdp1aF5wd5PWHu9DqvPFm-BdVkR02Wgvg@mail.gmail.com","subject":"Re: Hotfix Branching Strategy","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-02-12T09:21:15Z","receivedAt":"2019-02-12T09:21:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Feb 12 2019, Roman Gelfand wrote:\n\n>  At any one time, up to 3 developers could be developing hotfixes\n> addressing issues.    Whether it is one or multiple people working on\n> hotfixes, we always want to produce one hotfix.  Each hotfix is a\n> cumulative update since beginning of release.  Just about every hotfix\n> requires database upgrade.  Being that it is cumulative each developer\n> is dependent on the other.  Considering the requirements, what should\n> be a strategy to deal with this problem.?\n\nRequirements differ, but you may be interested in the strategy we\n(Booking.com) use in git-deploy[1]. It hasn't been updated in a while,\nbut the hotfix logic is there.\n\nBasically:\n\n 1. You have a \"master\" branch where new development happens\n\n 2. When you make deploys to your systems you deploy latest (or recent)\n    \"master\". This creates a dated tag like foo-YYYYMMDDHHMMSS or\n    bar-YYYYMMDDHHMMSS to deploy to the \"foo\" or \"bar\" set of servers.\n\n 3. Instead of \"update to master\" you can also \"hotfix\" which starts a\n    session where you (usually!) cherry-pick from \"master\", but you can\n    *also* make new original work.\n\nNow, the critical thing is that when you sync out #3 we perform the\nfollowing dance:\n\n A. Fetch latest upstream, origin/master\n\n B. Make a note of the SHA-1 of the hotfix we're about to sync (let's\n    call this X)\n\n C. Merge our X into origin/master\n\n D. Push our merged origin/master+X to upstream origin/master (see [2]\n    for some plans to make this easier)\n\n E. \"git reset --hard X\". We want to roll out our hotfix, not the merge\n     with \"master\"\n\n F. Sync out our \"X\"\n\nWhat this ensures is that:\n\n * After hotfixing e.g. \"foo\" a new deploy of \"bar\" will include the\n   hotfix, since we pushed it upstream to master. Thus hotfixes\n   (including \"live\" work\") don't get forgotten. Imagine a critical bug\n   discovered & fixed in \"foo\" during an outage, you don't want a new\n   deploy of \"foo\" the next day to regress. Merging upstream to \"master\"\n   is critical.\n\n * Since you need to resolve the merge conflicts with origin/master, if\n   any, things like conflicts due to e.g. DB schema versioning need to\n   be resolved. E.g. in many cases your conflict with master will\n   require bumping a \"serial\" to a value that before the hotfix didn't\n   exist.\n\n * You can do deployments where multiple hotfixes to a system are\n   stacked one on top of the other, not as any specially supported\n   thing, just as an emergent property of a \"hotfix\" dropping you into a\n   session where you start with the current rollout, then you can\n   e.g. cherry-pick on top of the \"X\" hotfix to produce \"Y\" etc.\n\n * All deployments ever are merged into \"master\" including hotfixes, so\n   you can eventually prune the dated tags, and can just \"git log\" on\n   master to see all deployments ever (as opposed to \"git log --all\"\n   etc. which would also give you topics...)\n\nSo that's one approach.\n\nThe other thing people tend to do is to make a release, and at the same\ntime create a release branch, if they need a hotfix they develop on top\nof that\n\nThat's also a valid strategy, but I think most shops that do that tend\nto invent something to emulate what I've outlined above. I.e. now you\nhave a \"foo\" and a \"bar\" release while \"master\" is moving forward, and\nneed to cherry-pick and merge between them to make sure your next\nrelease of \"master\" doesn't regress.\n\n1. https://github.com/git-deploy/git-deploy\n\n2. https://public-inbox.org/git/87sh7sdtc1.fsf@evledraar.gmail.com/\n"}]}