BPSでは、社内のソースコード管理にgitを採用しています。
中央リポジトリには、GitHubのオープンソースクローン、GitLabを利用しています。
GitHubのPrivate Repositoryは便利ですが、ちょっとした細かい案件にリポジトリを作って行くと、価格が馬鹿になりません。
また、日本からだと少し遅いですね。
Github Enterpriseは高かったので、面白そうだしGitLabを導入したところ、使い勝手も良く安定運用できています。
GitLabとは
gitoliteのフロントエンドです。似たようなものに、gitosisがあります。
gitoliteは、UNIXユーザを作らずにSSH鍵によってユーザを識別し、プロジェクト毎のアクセス権を与えられるgitリポジトリの管理システムです。
中央リポジトリサーバに、ユーザ毎のアカウントを作ると、以下のような問題があります。
- 煩雑：単純に大量のユーザを作るのは手間です。
- セキュリティ：リポジトリアクセスさせたいだけなのに、シェルを渡すのは過剰です。
- 権限管理：リポジトリの数だけgroupを作って参加を管理するのは、かなり面倒です。また、read only accessを制御するのが困難です。
gitoliteでは、すべてのユーザは共通ユーザ(git)としてログインします。
ログイン時のSSH鍵で、できる操作（アクセスできるリポジトリ）が制御されます。実際に、/home/git/.ssh/authorized_keysに、鍵毎のcommandが指定されています。
gitoliteは以下のような設定ファイル（これ自身をgitで管理）で権限を編集し、設定ファイルの更新hookでauthorized_keysを更新しています。
repo gitolite-admin
RW+ = admin
repo testing
RW+ = @all
GitLabは、これをWeb管理画面から管理できるようにし、GitHubのようなリポジトリブラウザ・Issue・Wikiなどを搭載したものです。
GitHubとの違い
機能的には、本家GitHubには色々劣っていたりします。
なので、お金があるなら、GitHub Enterpriseを使った方が良いと思います。自分で構築したい人向けです。
リポジトリ名はglobal
これはポリシーの問題ですが、GitLabではリポジトリ名は全体で共有されます。
babatakao/practiceとpeter/practiceを両方作ることはできません。
人数やプロジェクトが増えてきたら、prefixな命名規則を作らないと破綻します。
forkはない
同様に、forkもありません。
Pull Requestに相当するMerge Requestは存在しますが、1つのリポジトリのブランチで実施します。
babatakao:masterからpeter:masterにforkといった運用はわかりやすいのですが、これができないことになります。
public repositoryが存在しない
社内向け用途が想定されているため、public repositoryは存在しません。
そのため、deployやtest用にも、必ずdeploy keyを登録する必要があります。
全プロジェクト共通のreadonly accountを設定する機能も現状ないので（gitoliteを直接いじる裏技は可能）、多少手順は煩雑になります。
その他、巨大ファイルがあると弱かったりします。
それ以外は特に気になることもなく、運用できています。
特に、リポジトリブラウザは、本家にひけを取りません。
一番よく使う機能の1つなので、非常に便利です。やはり、リモートブランチの中身を見やすく見られるのは大事ですね。
コミットへのコメント機能もあるので、継続的なコードレビューもやりやすくなっています。
構築
本当は構築をメインに書こうと思ったのですが、非常に簡単で書くことがないので、リンクだけにしておきます。
https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md
なお、GitLabは特に関係ないのですが、サーバは必ず64bitマシンにしておきましょう。32bitだと、gitプロセスが十分なメモリを確保できず、OutOfMemoryを吐くことがあります。巨大なファイルがpushされてしまったときなどに。
運用
更新が頻繁なので、まめにバックアップ・バージョンアップできる準備をしておきましょう。
また、pull requestへの反応も良いので、気になる部分はどんどん送ると良いと思います。
Railsのアプリケーションとしても、かなり参考になります。
最新のRailsに随時対応し、Resqueなどの流行りのライブラリを取り入れています。
機能が分かりやすいので、チュートリアルを終えた人が実践的なソースコードに触れるのにも向いています。
しばらく使ってみて
現在、以下のような規模で運用しています。
BPSのGitLab
リポジトリは大小あり、ユーザ数1人・ファイル数10個程度のものから、ユーザ数20人近くのものまで。git-svnで移行したリポジトリも相当数混じっています。
サーバは仮想マシン1台（メモリ2GB）、Ubuntu 12.04 LTS。毎日10～15人くらいはpush/pullしているはずです。
この状態で、特に大きなパフォーマンス上の問題は出ていません。
プロジェクト数が増えてから、新規リポジトリの追加・メンバーの追加はやや重くなりました。これは、gitolite-adminのgitolite.confをパース・上書きしてgitoliteに反映する処理に時間がかかっていると思われます。
リポジトリのpush/pullは、さすが社内ネットワーク経由なので、爆速です。
感謝・感謝です。良いpull request遅れるように頑張ります。