GitHub Enterprise TechTalk に見る、各社の運用法

弊社もバリバリ GHE を使ってるので落ちると開発が回らなくなる(pull request できないのは、master に merge できないのとほぼ等価)ので、他社どうやってるのかーと大変気になってたのでしれて良かった。

間違ってたら教えてくだしぃ

• クックパッド
  • 開発者は GHE へ push, webhook でメインの git サーバに同期
  • GHE の git レポジトリは本番からは利用しない
  • GHE が死んだ場合はメインの git サーバを向けることで継続開発・デプロイ可能
• はてな社
  • 開発者は GHE に push したり場合により別のサーバに push したり
  • GHE から webhook でミラーリング
  • GHE / 別 git を開発者がうまく使いこなす必要がある。混乱するので git-hatena コマンドを用意してよしなにラップしてる
  • GHE のサーバは Active Standby 構成らしいけどどうやってるのか聞きそびれた！
• DeNA 社
  • 開発者は GHE へ push
  • GHE から各種 ghe- ツールを使いバックアップ
  • repos は巨大すぎるので ghe- ツールで無くて rsync
    • 某権限でｺﾞﾆｮｺﾞﾆｮ…仮想マシン上のｳﾌﾞﾝﾂですし…
  • 構成は Cold Standby 構成
• - VMWare の仮想冗長化はお値段が…
• GREE 社
  • 大場さんがんばって(´；ω；｀)

というわけで

• GHE が死んで pull request できなくなると死ぬ
  • DeNA でやってる Cold Standby 構成で
• 本番に deploy やレポジトリ参照できなくて死ぬ
  • 参照するのは GHE レポジトリで無く別のメインのレポジトリで

が良さそうだナーと思いました。へーしゃも DeNA 社的なアプローチとりたいなぁ。あと GHE も日々進化してるので、そのうちきっと低コストな手法で SPOF が排除される機能がつく…はず…といいなぁ…

あと感想で GHE 使うの苦行だけじゃ、って話しを何件か見たけど、実際 github.com の運用だけで問題ない会社なら

• github.com を使ったときのセキュリティリスクをとれる
• github.com が死んでてもなかない

なら、github.com を使うべきですよ。GHE に github.com で実装された機能が入ってくるのにも時差あるし、github .com を使わない理由は無いです。安易に GHE を使うと運用をしっかりしないと死ぬので。