How Yipit deploys from Github with multiple private repos • Hacker News Board

Re: How Yipit deploys from Github with multiple private repos

#11

Post by andrewgross » Thu, Sep 06, 2012, 9:47 PM UTC

dekz wrote: post #10

I believe you can setup aliases in ssh_config where you specify the actual hostname and the key to use. Which is what I've used in the past to get the right key to just work with git (and gitolite). Host github-yipit-main Hostname github.com IdentityFile ~/.ssh/yipit_main_rsa then just go about your merry way of: git clone git@github-yipit-main:/yipit/yipit-main.git

Not a bad idea since it would make easier to pull changes outside of the automation without needing to specify the GIT_SSH variable.

Re: How Yipit deploys from Github with multiple private repos

#12

Post by amccloud » Thu, Sep 06, 2012, 10:11 PM UTC

maratd wrote: post #9

borlak wrote: post #6

best way: don't deploy from github. you should have an internal github server (github enterprise). don't rely on the site to secure your production code. they have had security problems in the past.

How is that more secure? They're both running the same code base. That means they have the same vulnerabilities. Both also need to be public facing to deploy code.

No. Github Enterprise can be setup to be only accessible from your internal network.

Re: How Yipit deploys from Github with multiple private repos

#13

Post by maratd » Thu, Sep 06, 2012, 10:16 PM UTC

amccloud wrote: post #12

maratd wrote: post #9

Earlier quoted context omitted.

How is that more secure? They're both running the same code base. That means they have the same vulnerabilities. Both also need to be public facing to deploy code.

No. Github Enterprise can be setup to be only accessible from your internal network.

You can set it up that way, but then you wouldn't be able to deploy from it ... unless you're developing something that is being used internally?

Re: How Yipit deploys from Github with multiple private repos

#14

Post by amccloud » Thu, Sep 06, 2012, 10:42 PM UTC

maratd wrote: post #13

amccloud wrote: post #12

Earlier quoted context omitted.

No. Github Enterprise can be setup to be only accessible from your internal network.

You can set it up that way, but then you wouldn't be able to deploy from it ... unless you're developing something that is being used internally?

What makes you say that. Just make sure your server are on the same network.

Re: How Yipit deploys from Github with multiple private repos

#15

Post by maratd » Fri, Sep 07, 2012, 12:04 AM UTC

amccloud wrote: post #14

maratd wrote: post #13

Earlier quoted context omitted.

You can set it up that way, but then you wouldn't be able to deploy from it ... unless you're developing something that is being used internally?

What makes you say that. Just make sure your server are on the same network.

> Just make sure your server are on the same network.

Using a VPN? Or are you hosting your own stuff?

If your public facing server gets breached and it is sitting on your actual internal network or is connected through a VPN ... well, that means the attacker just got a free pass right through your firewall.

I used to put my production boxes on a VPN, but now I don't have to because I can deploy from GitHub. That was the main reason I signed up with GitHub.

Re: How Yipit deploys from Github with multiple private repos

#16

Post by mey » Fri, Sep 07, 2012, 6:24 PM UTC

maratd wrote: post #8

mey wrote: post #4

I was looking at this sideways until I read the last statement about the future. There is something bothersome to me about deploying code directly from a code repository. Things I can think of that bother me about it, not clear what code has and has not been deployed, code is not explicitly validated (automatically, manually, on a build/test lab), and it isn't clear who triggered the release. I think it also bothers…

Not if you structure your repo correctly. > not clear what code has and has not been deployed You can have your production machines deploy from specific branches. In other words, master is the development branch, some-version-branch is the production branch. You can also do it vice versa. You can use tags. Lots of solutions. > code is not explicitly validated (automatically, manually, on a build/test lab) If you use…

I guess it depends on your deployment system, if there is an automated system watching that branch on a central repo, you assume any commit is rolled out and who ever pushed triggered it via commit.