Re:Improving how we deploy GitHub
by bswinnerton on Monday January 25, 2021 @03:37PM
(#25908454)
This is known as “GitHub Flow” (https://guides.github.com/introduction/flow/). I was pretty surprised by it when I first joined GitHub but I’ve grown to love it. It makes rolling back changes much faster than having to open up a revert branch, get it approved, and deploy it. When something goes sideways, just deploy master / main, which is meant to always be in a safe state.
[ Parent
| on HN ]
How does this work if two (or more) engineers touch the same file at the same time?
EG: If two engineers have two different PRs open modifying `index.html`, how does that go to canary?
Re:Improving how we deploy GitHub
by bswinnerton on Monday January 25, 2021 @07:23PM
(#25910826)
Before every deploy your branch has master merged into it. There’s some clever work by Hubot while you’re in line to deploy to create a version of your branch that has the potential new master / main branch. If conflicts arise you fix them before it’s your turn to deploy.
how deep does this deploy queue get? And does everything that lands on master have to first be deployed?
This seems like a bit tough for getting work done if you have enough people all waiting around for this
The deploy queue usually gets to be a couple of "trains" deep which usually includes work from 4-10 devs. This represents a couple of hours. We have had issues with it taking too long, but this work I wrote about has improved that! We continue to try to improve it.