How Yipit deploys from Github with multiple private repos

How Yipit deploys from Github with multiple private repos(tech.yipit.com)

23 points by vacanti 13 years ago | 15 comments

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

andrewgross 13 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.

mnutt 13 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.

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

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

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

andrewgross 13 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.

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

bbq 13 years ago |

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

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

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

amccloud 13 years ago | | |

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