How Yipit deploys from Github with multiple private repos

http://tech.yipit.com/2012/09/05/deploying-from-github-the-right-way/

by vacanti • 14 years ago

23 15 14 years ago

tech.yipit.com

mnutt• 14 years ago

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.

bbq• 14 years ago

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

mey2• 14 years ago

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.

andrewgross2• 14 years ago

I know where you are coming from with compiled languages. A big reason for creating this flow was for working with repositories that are not our primary code repository. We have several internal tools and forks that don't have a complex deployment process. We wanted the simplicity of being able to push to master and knowing that it will be out in ~30 minutes. Our primary code base is rolled out with Fabric instead of Chef (for now) but Fabric will still need to execute a pull from Github at some point during the rollout.

maratd4• 14 years ago

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.

mey2• 14 years ago

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.

borlak• 14 years ago

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.

maratd4• 14 years ago

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.

amccloud2• 14 years ago

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

pbiggar• 14 years ago

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

dekz• 14 years ago

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

andrewgross2• 14 years ago

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

How Yipit deploys from Github with multiple private repos

Related Stories