この記事はQiitaのGit Advent Calendar 2014 24日目の記事です。
GitHubEnterprise(以下GHE)を導入するにあたり、技術的なことで気をつけたいところ、技術的でないところで気をつけたいところをつらつらまとめます。
GitHubといえばこの本ですが、Enterpriseのことは1、2ページくらいしか書かれていなくてあまり参考になりませんでしたので、つらつらまとめることにした次第です。
そもそもEnterpriseを使う必要があるのか
ソースコード管理をしたいのであれば、GitHubEnterpriseを使う以外にもいろいろと選択肢があると思います。具体的な例を挙げると、
- GitLab、GitBucketなどのオープンソース系ソースコード管理システム
- GitHubやCodeBreakのプライベートリポジトリ
GHEは20アカウントで年間5000ドル、以降20アカウントごとに5000ドルずつ増えていく計算なので、決して安くはない額のお金がGitHubEnterpriseのために使われることになります。それでもGHEを使う理由は何でしょうか。とりあえずWikiの使い勝手がよくないとかIssueとRedmineの両立とかUI的な不満はあるでしょうが、それは一旦放っておきましょう。
- JSOXなどの理由から他企業サービスに自社のソースコードを管理させたくない
- ソースコード管理システムの保守コストを低く抑えたい
といったところでしょうか。特に2番目については、GitLabみたいなのを使っていると運用が面倒です。GitLabは導入も大変ですが、やたらバグだらけで運用もしんどかったのを覚えています。
周りの賛同を得ること
先程も申し上げたとおり決して安くはない額のお金がGitHubEnterpriseのために使われることになりますから、直属の上司、部長、他部署の開発チームなど、周りの賛同を得ることは必須となります。関係者を集めて一度ミーティングをやることを勧めます。
特に自分の交渉能力に自身がないと感じたら、発言権の高い人間の賛同を得るようにするといいと思いました。
アカウント
アカウントの数に制限があるので、LDAP認証でアカウントを運用している人は気をつけましょう。 アカウントを一時停止(Suspend)すればそのアカウントはアカウントの数に含まれません。
VMイメージからサーバはrootに入れない
GitHubのサポートからVMイメージをもらってサーバを作って運用するわけですが、このサーバはrootに入れません。その点は気をつけましょう。この縛りはネットワークまわりの設定で絶大な威力を発揮します。
https://help.github.com/enterprise/11.10.340/admin/articles/ssh-access/
リポジトリの移行
GitLabなどでソースコードを運用していて、そのリポジトリ数が三桁あったら移行作業だけで死ぬので、予め移行スクリプトは書いておきましょう。 hubコマンドを使うと便利です。
enterprise用に設定をしておくことを勧めます。
いつリポジトリを移行するのか
リポジトリの移行と絡みますが、他部署がメインで開発を進めているリポジトリは、「いつ」移行するかがキーになります。 なので前もって関係者と連絡をとっておきましょう。
そもそもGitHubの使い方を知らないひともいるでしょうから、チュートリアル的なリポジトリを作成しておくといいと思います。
権限まわり
Site AdminやTeamの権限も重要です。
- 誰にVMを再起動させるか
誰にアカウントの管理をさせるか
誰にPRを取り込めるようにするか
誰にリポジトリを作成させるか
Site AdminとTeamの権限の違いはなにか
これらを周知してもらうために、できるだけ多くの関係者を集めてミーティングをしたほうがいいと思いました。
お支払い
お支払いはクレジットカードが有効です。他の方法もありますが、それについてはちょくちょくサポートに聞いてみるといいでしょう。 一応日本語もOKですが、肌感覚的に英語のほうがレスが早いので、英語で書くことを勧めます。
まとめ
GitHubEnterpriseの導入は、開発案件というより、まわりの人たちの調整や協力が必須な案件です。調整とか人とのコミュニケーションが苦手な人は、心してかかりましょう。
