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

Deploying at GitHub

github.com

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Deploying at GitHub

#21

Post by psadauskas »

trustfundbaby wrote: post #19

Interesting ... what's your QA process? Do you have a staging environment where you try stuff out (looking for bugs) before pushing to production?

We have a staging environment, but its really only used for really big changes that might need to be experimented with before being deployed. We can also deploy a branch to a single front end to observe how it behaves with a subset of the traffic, and roll it back quickly if needed. Also, most large user-facing features are released as "staff-only" first, so we as GitHub users are able to play around with it for a few days or weeks before enabling it for everyone.

Re: Deploying at GitHub

#22

Post by pbiggar »

alexchamberlain wrote: post #7
badboy wrote: post #4

Earlier quoted context omitted.

Github itself is a Github project, therefore using anything other than the API would be some code duplication. Merging, Pull-Requests, Branches, Issues: all this is already covered when using the normal API. I'm sure it could be "more efficient" when having code explicitely for this purpose, but then again you have to maintain to different code bases which do the same.

You either maintain a codebase that calls out to the Github API or a codebase that calls out to Git? What's the difference?

Theres a lot of things you can do in the API that you can't do in git. For example, pushes exist in the API, but don't really within git.

Re: Deploying at GitHub

#23

Post by tomjakubowski »

jrockway wrote: post #12
wamatt wrote: post #6

Encouraging to know this model scales to 100 employees at least. Purely out of intellectual interest, I wonder if a company the size of Google or Facebook could also ship in this way, or if the whole release manager/team is essential.

Sarbanes-Oxley puts a big damper on production deployments at big companies. I don't fully understand it so I won't try to explain it. (I will complain though: the law says developers shouldn't have control over production systems. If that's a requirement, who's going to write the software?)

Wait, what? Could someone elaborate on S-O restricting developer control over production systems?

Re: Deploying at GitHub

#27

Post by scylla »

jrockway wrote: post #12
wamatt wrote: post #6

Encouraging to know this model scales to 100 employees at least. Purely out of intellectual interest, I wonder if a company the size of Google or Facebook could also ship in this way, or if the whole release manager/team is essential.

Sarbanes-Oxley puts a big damper on production deployments at big companies. I don't fully understand it so I won't try to explain it. (I will complain though: the law says developers shouldn't have control over production systems. If that's a requirement, who's going to write the software?)

I don't know if that's a SOX law. However, I do know that it is a PCI requirement. A single person shouldn't be able to introduce new code and then be able to push their own change out to production.

Re: Deploying at GitHub

#28

Post by kscaldef »

tomjakubowski wrote: post #23
jrockway wrote: post #12

Earlier quoted context omitted.

Sarbanes-Oxley puts a big damper on production deployments at big companies. I don't fully understand it so I won't try to explain it. (I will complain though: the law says developers shouldn't have control over production systems. If that's a requirement, who's going to write the software?)

Wait, what? Could someone elaborate on S-O restricting developer control over production systems?

A lot of this stuff is open to interpretation by auditors. SOX doesn't literally specify any of this sort of stuff.

In my experience, SOX usually ends up meaning that developers don't have access to production systems, or significantly limited access. However, a continuous deployment system should generally be very much in the spirit of SOX, in that it's pretty hard to do without well-defined, highly-repeatable, automated and auditable processes.

Re: Deploying at GitHub

#29

Post by vrish88 »

psadauskas wrote: post #21
trustfundbaby wrote: post #19

Interesting ... what's your QA process? Do you have a staging environment where you try stuff out (looking for bugs) before pushing to production?

We have a staging environment, but its really only used for really big changes that might need to be experimented with before being deployed. We can also deploy a branch to a single front end to observe how it behaves with a subset of the traffic, and roll it back quickly if needed. Also, most large user-facing features are released as "staff-only" first, so we as GitHub users are able to play around with it for a fe…

How do you guys release features as "staff-only"? Do you have some internal tool that manages that?

Re: Deploying at GitHub

#30

Post by rtomayko »

vrish88 wrote: post #29
psadauskas wrote: post #21

Earlier quoted context omitted.

We have a staging environment, but its really only used for really big changes that might need to be experimented with before being deployed. We can also deploy a branch to a single front end to observe how it behaves with a subset of the traffic, and roll it back quickly if needed. Also, most large user-facing features are released as "staff-only" first, so we as GitHub users are able to play around with it for a fe…

How do you guys release features as "staff-only"? Do you have some internal tool that manages that?

No. There's simple conventions for adding feature flags (user.some_feature_enabled?). Features are enabled and disabled by changing the code and deploying. This works because deploying new code is fast.
Post reply on HN