Deploying at GitHub
github.com
Deploying at GitHub
1–10 of 61 posts
Re: Deploying at GitHub
#2I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?
Re: Deploying at GitHub
#3[deleted]
Re: Deploying at GitHub
#4I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?
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.
Re: Deploying at GitHub
#5I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?
Dogfooding aside, the vast majority of the time is spent running tests and actually deploying the code. The time to hit the API to merge the commit is negligible in comparison.
Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.
Re: Deploying at GitHub
#6Encouraging 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.
Re: Deploying at GitHub
#7I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?
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?
Re: Deploying at GitHub
#8I know this is Github, but... Rather than use the Github API, wouldn't it be more efficient to interact with Git directly? Libgit2 maybe?
Dogfooding aside, the vast majority of the time is spent running tests and actually deploying the code. The time to hit the API to merge the commit is negligible in comparison. Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.
But they are hitting the API to get the OID of the master ref as well?
Not having access to the file system is a fair excuse...
Re: Deploying at GitHub
#9Earlier quoted context omitted.
Dogfooding aside, the vast majority of the time is spent running tests and actually deploying the code. The time to hit the API to merge the commit is negligible in comparison. Also, Janky and Heaven are both tiny apps that don't necessarily have access to the file servers.
But they are hitting the API to get the OID of the master ref as well? Not having access to the file system is a fair excuse...
The merge API takes branches: http://developer.github.com/v3/repos/merging/
Re: Deploying at GitHub
#10Encouraging 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.
Amazon generally doesn't have release teams (except for the retail website).
I can't find it right now, but I know someone gave a talk on Apollo, which is how Amazon does deployments.