Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deploying branches to GitHub.com

githubengineering.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Deploying branches to GitHub.com

#21

Post by hckr1292 »

mpdehaan2 wrote: post #7

The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good. It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in. So they could just merge first, and then if staging passes in t…

We've adopted some aspects of this flow, and our take is that we test feature branches on stage thoroughly including CI test run and code review.

Then we merge to master and let all the CI run again while we manually verify. Any troubles and you revert. All green? Deploy right away. We try never to deploy more than 2-3 changes to production at a time.

The main bottleneck for us is the speed of our CI runs. It's tempting to merge in a lot of changes to master and let them accumulate on QA. Reducing the test run time is an ongoing goal and should make this system pretty scalable for our team.

Usually, you won't have merge conflicts if you deploy early and often and keep feature branches deliberately small. For larger stories, consider breaking it into discrete feature branches that implement part of the functionality (ex: behind a feature gate).

Re: Deploying branches to GitHub.com

#23

Post by ykumar6 »

100k wrote: post #10

I really enjoy reading how organizations have implemented continuous deployment. One question I have which is not addressed by the article is how to deal with database changes. Every database has difficulty with schema migrations to one degree or another, but MySQL (which IIRC is what GitHub uses) is particularly bad. In my organization, we are VERY careful with any deploy that contains a migration. (I suppose this i…

Runnable.io makes it very easy to run all your Github branches, using containers. Here's is how it works https://www.youtube.com/watch?v=_uwPKIH990E&feature=youtu.be

Re: Deploying branches to GitHub.com

#24

Post by juliangregorian »

oliverzheng wrote: post #17

If I read this correctly, only 1 dev can test on production at a time. How does this scale as the company grows?

I imagine deploying a green environment[0] to test before merging to master would be one solution. It is interesting that Github seem to not do that.

0: http://martinfowler.com/bliki/BlueGreenDeployment.html

Re: Deploying branches to GitHub.com

#25

Post by juliangregorian »

joelthelion wrote: post #22
oliverzheng wrote: post #17

If I read this correctly, only 1 dev can test on production at a time. How does this scale as the company grows?

I suppose you could have a hierarchy, with team leads pulling from their devs and deploying the whole team's stuff when it's ready.

That would defeat one of their major wins, ownership/agency/responsibility.

Re: Deploying branches to GitHub.com

#26

Post by bhuga »

mpdehaan2 wrote: post #7

The 'merged once deployed to production' thing, yes, I know even if advocated by GitHub, seems extremely weird to me. It does seem they have a staging check first, which is good. It seems you'd want to merge it first, so that you know it when merged with "all the things" on master, so it more closely mirrors what you are going to get once it's merged in. So they could just merge first, and then if staging passes in t…

The deployment system automatically merges master into the branch being tested on deployment, and will not deploy any branch that does not contain master. In fact, there is a check that nags the main app team if master is not deployed to production for some reason (usually someone merging docs changes while someone is testing a "real" branch). It's considered an abnormal state, and I will often block all deployments until we figure out why master hasn't gone out.

Even forced deployments (which ignore CI and a few other checks for emergencies or maintenance mode) won't deploy a branch that's 24 hours behind master.

Re: Deploying branches to GitHub.com

#27

Post by bhuga »

oliverzheng wrote: post #17

If I read this correctly, only 1 dev can test on production at a time. How does this scale as the company grows?

The "lab" environments have enough capacity to allow plenty of parallel testing. When deploying to production, it's expected that you already know your branch does what it's supposed to do. A production deploy is when one makes sure a branch has not introduced regressions, so holding it for more than 15 minutes is rare.

Re: Deploying branches to GitHub.com

#28

Post by tonyhb »

ykumar6 wrote: post #23
100k wrote: post #10

I really enjoy reading how organizations have implemented continuous deployment. One question I have which is not addressed by the article is how to deal with database changes. Every database has difficulty with schema migrations to one degree or another, but MySQL (which IIRC is what GitHub uses) is particularly bad. In my organization, we are VERY careful with any deploy that contains a migration. (I suppose this i…

Runnable.io makes it very easy to run all your Github branches, using containers. Here's is how it works https://www.youtube.com/watch?v=_uwPKIH990E&feature=youtu.be

Do you know how well it works with an SOA setup with multiple repos?

Re: Deploying branches to GitHub.com

#29

Post by ykumar6 »

tonyhb wrote: post #28
ykumar6 wrote: post #23

Earlier quoted context omitted.

Runnable.io makes it very easy to run all your Github branches, using containers. Here's is how it works https://www.youtube.com/watch?v=_uwPKIH990E&feature=youtu.be

Do you know how well it works with an SOA setup with multiple repos?

We run 10 repos in our sandbox
Post reply on HN