Gitlab(Githubクローン)サーバーを社内に立てた記録(その後)

社内に、Gitlabサーバーを立ち上げて、約10ヶ月経ちました。
日本では、Gitには興味あるけど会社ではまだ使っていないという人も多いんじゃないでしょうか。
数件のプロジェクトを回してみたところ自分的には非常に満足できたので、後に続く方のために少し情報を書き留めておきたいと思います。

■事前情報
 私が務めている会社は、小規模ソフトウェアハウスで、社員の人数でいうと50人くらいでしょうか。
そのなかで、純粋にプログラムを書いている人数は、約半数くらいです。
(あとは、総務だとか管理やデザイナーなどの非プログラマーですね)
SVN,VSS,TFSなどのバージョン管理システムは、私が転職してきた頃には、既に使われていました。

■導入経緯
 IT系のニュースなどで、非常にGitが話題になっており私の見立てでは、次世代のバージョン管理システムは、Gitで決まりという状況でした。
(今のところ状況は予想道理の推移ですね)
私の個人的な経験談で恐縮なのですが、昔客先でVSSを使ったプロジェクトがあったのですが、使い方を知らず顧客に教えて貰いながら苦労して覚えた苦い経験があります。
(ファイルを上書きしちゃったりして怒られたり・・)
まだ、バージョン管理システム自体が一般的じゃなかった頃の話なのですが、私にとってバージョン管理システムは、そんな経緯で少々思い入れの強いツールなのです。
SVNを既に使っていましたからバージョン管理という面では、困っては居なかったのですが、導入すべく社内調整を始めました。

■導入計画
 Gitを導入するにあたって、どのようなツールが必要なのか、調べることにしました。
オンプレミスでなければ、ソースコードを保存することはダメという契約になっているためGithubクローンにするという方向は、すぐに決まりました。
問題は、Githubクローンが複数存在するという所でした。
まあ、気に入らなければ潰して別なツールへ移れば良いと考えて、Gitlabを選択したのですが、結果的には正解でした。
検証PCへインストールしてみたときは、Version1.Xの頃で、正直機能も見た目もボチボチだったのですが、毎月22日に最新版リリースというスケジュールで、ガンガン機能も見た目も成長しており非常に安定して動作しています。
サーバーが落ちたのは、数回でしかもVersion2.0の古いバージョンでの検証中のことでした、Version2.6以降の本番環境では一度も落ちていません。

 いきなり導入してプロジェクトに使ってみたら使い物にならなかった。
というケースは最悪なので、次のステップで導入を行いました。
【1】検証PCで、安定性、機能(特に日本語との相性)、パフォーマンスを検証
【2】検証PCで、小規模案件にて検証
【3】検証PCで、中〜大規模案件にて検証
【4】Hyper-Vの仮想化環境にて、本番環境を構築

■導入方法
インストールは、次のページの通りに進めれば、それほど難しくはありません。
https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md
ただし、Linuxコマンドラインで、ある程度作業ができることが前提です。
Windows,Macしか使ったことの無い方には、ハードルが高いかもしれません。

私が唯一躓いたのは、課題管理のメール通知が動作しないという不具合でした。
検証PC(Version2.0)では、動作していたのですが、仮想環境(Version2.6)では、通知メールが飛ばずかなり悩みました。
Issue #1068
で、同じ現象を訴えた人がおり問題はどおやらresque_worker.pidのパーミッションのようです。
ここで指摘されている通りに操作してみたところ通知メールが飛ぶようになりました。

■良い所
(1)非常に動作が軽い
Gitを導入するまで社内では、SVN,TFS,VSSを使っていました。
どちらも集中管理型のバージョン管理システムですが、使い比べてみると非常に遅かったんだなあと感じました。
Gitのリモートリポジトリは、非常に低スペックな環境で動作させていますが、非常にサクサクと動作します。
ただし、Git以外のシステムに関しては、Windowsサーバーで管理されているみたいなので、OSにリソースが食われている可能性がありそうです。
Gitに関しては、Linux上に構築されており仮想環境で、メモリ割り当てが少ないにも関わらずスワップなどは発生していません。
予算のない中小企業でも余った古いPCで十分動作しますので、是非試してみて欲しいと思います。(検証PCは、Pentinum4の古いPCを使いました)
本番環境では、バックアップなど管理面からHyper-Vの仮想PCに、Ubuntu12.04 Serverをインストールして構築しました。
Linuxのデストリビューションは好みがあると思いますが、Ubuntuは情報も多いのでお勧めです。

(2)ソーシャルコーディング!
Gitlabは、リポジトリ管理、ユーザー管理、課題管理、スニペットWiki、ウォールの機能を持っています。
全ての操作をWeb上で行えるため管理者の負担が軽減できます。
正直Gitlabが無ければ、Git導入は成功していませんでした。
それほど便利な機能が提供されています。
特に便利だと感じたのは、Webでリポジトリの状態が簡単に判る機能です。
Git以外のシステムでは、誰がどのようなコミットを行ったのか、調べるコストが大きかったので、なかなかプロジェクトのステータスを把握できませんでした。
Gitlabでは、コミット履歴が一覧で見えてDiffも簡単に見えます。
プロジェクトリーダーは、Gitlabのアクティビティとコミット履歴を監視していれば、メンバーの作業の進みが手に取るように分かります。
「今日、山田くんは、課題の消化とコミットが一件も無いぞ。何かハマってるんじゃないか?」という具合です。
ウォールは、メンバーへの技術的な質問とか、「俺この機能の実装で躓いたから他の人気をつけて」のようなコミュニケーションがとれます。
私の印象では、Gitlabがあれば、朝会とかしなくても十分プロジェクトメンバーのステータスは把握できそうです。

■悪い所
(1)ドキュメントの共有
VSSは、特定のディレクトリ配下をソースコード用、ドキュメント用に分けて使うことができます。
要するに、履歴管理がファイル単位なので、こういった運用ができるわけです。
Gitは、リポジトリ全体のチェンジセットなので、そういった運用はできません。(Submoduleとかもたぶん違う)
そのため、プロジェクトの設計書を何処で管理するかという問題が生じます。
VSSを併用するのもイケてませんし、ドキュメントだけのプロジェクトを作るのも変な感じです。
Gitlabは、現状大きなファイルをアップロードすることはできませんので、ドキュメント管理機能が追加されると嬉しいんですけどね。

(2)複雑でマニアックなツール
プロジェクトメンバーからは、初め必ず「良くわからない。使いたくない!」という反発が起きます(苦笑)
プログラミングスキルとか、関係なく皆一様に、不満から始まるので、今では笑ってしまう程です。
一旦慣れてくると便利さが分かってもらえるようなのですが、ツールのセットアップからしてかなりハードルが高いので、理解して使ってもらうには根気よく説明する必要があります。

■今後の目標
社内ライブラリをサブモジュールとして切り分けて、案件プロジェクトとリンクした形で、保守したいと考えています。
ただし現バージョンのGitlabは、サブモジュールに対応していないので、(Version3.0で対応予定)今後の目標としたいと思います。