

How Yipit deploys from Github with multiple private repos - vacanti
http://tech.yipit.com/2012/09/05/deploying-from-github-the-right-way/

======
dekz
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

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

------
mnutt
It seems like it would be easier to just create another github user, add it to
your organization as a read-only user, and then add each machine's ssh key to
that user as a real ssh key rather than a deploy key. The downside is that you
can't restrict certain machines to certain repositories, but the upside is
that it's a lot less complex.

------
mey
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 the side of me coming from compiled languages where
there is more to a code release then copy files from a to b.

~~~
maratd
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 the structure above, you wouldn't commit to a production branch
unless you did that. Another solution is to force validation/testing using
hooks before allowing a commit to a production branch on your development
machine.

> and it isn't clear who triggered the release.

Not sure what you mean here ... every commit is recorded, so you always know
who did what.

~~~
mey
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.

------
pbiggar
If anyone is interested in something very like this, but as-a-service, check
out <https://CircleCi.com>. We do continuous deployment so long as your tests
pass, with key management to support this kind of flow.

(Though to be honest, this flow seems overly complex, and I'm not 100% sure
what problem it's solving).

------
bbq
Great work! Looks like Github has a big area for improvement, though.

------
borlak
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.

~~~
maratd
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.

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

~~~
maratd
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?

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

~~~
maratd
> 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.

