こんにちは。ヨガをはじめたあたぎです。メイン業務はレストラン検索の開発です。
みなさんGitをお使いかと思いますが、そのホスティングはどのように行っていますでしょうか。
弊社ではここ1年くらいGitLab Community Editionを使用しています。世間ではGitHubがデファクトスタンダードになりつつありますが、何故あえてGitLabなのか？その理由について説明します。
主に
- ちょっぴりセキュリティ周りがきつい会社
- うなるようにお金が出せるわけじゃない会社
で働いている人には参考になるかもしれません。
GitLab前史
GitLabを導入する前はこの2つを使っていました。
前者は機能が限られていて無償版の開発が停止していること、後者はPull Requestの機能が足りなかったことによって困るケースがありました。
※2016年10月現在、Backlogに関してはPull Requestの機能が実装されています。あくまでも導入検討時(2014年)の話です。
そこで新しいホスティングサービスを検討しようということに。
ホスティングサービス候補は3つ
まず前提として内部ホスティングか外部ホスティングか、というのがあります。
どちらにも一長一短あると思いますが、一番重要なのはソースコードが外部に公開されないということ。外部ホスティングの場合、誤ってPublicでリポジトリを作成するとソースコードが外部に公開されてしまいます（当然のことではあるのですが）。
弊社としては情報漏洩のリスクが無視しきれなかったため、内部ホスティングでいくことに。そこでさまざまな内部ホスティングサービスを調査して、候補に上がったのは以下の3つの製品でした。
１. GitHub Enterprise
参照：GitHub Enterprise - The best way to build and ship software
２. Atlassian Stash
参照：Bitbucket Server (旧 Stash) | Atlassian
※検討当時はStashでしたが、現在はBitbuscket Serverに名称変更しています。
３. GitLab Community Edition
選定基準
いくつかの基準で比較する
この3つを以下の基準で比較していきます。
- 機能面…開発で利用できるとよさそうな機能の有無。たとえばPull Requestのような機能があるかどうか
- 操作面…使いやすさ、便利さ、レスポンス
- 運用面…発生しうる作業にかかる運用作業負荷
- 費用面…各製品の年間維持費
- 導入企業…どのような企業が各製品を導入しているか
- 更新数…プログラムのFeature, Bug/Security Fix の対応数
特に重要視していたのは費用面・機能面・操作面の3点。
いったんGitLab Community Editionを選択
上記の基準で点数を付けてみたところ、GitHub Enterpriseが一番評価が高かったのですが、いかんせん運用コストが気になる……(´・ω・｀)
また協力会社の方のアカウントを個別に払い出す運用形態を取っていることから、年間の増員ユーザ数・正確な運用コストが見積もりづらいという問題もありました。
ですので「GitLabで行ってみよう」という結論に。2015年6月に導入しました。
運用してみてよかったこと
第二候補のGitLabでしたが、運用して気づいたメリットは次の4つ。
１. OSSのため自分で問題箇所を改修できる
自分で問題箇所を修正・訂正できるのは大きなメリットです。過去には、タイムアウト値を伸ばす（※現在のバージョンではconfigで設定できますが、導入当時はなかったのでスクリプトをいじる必要がありました）、プラグインのHTTP_PROXY対応などの修正を行いました。
２. rootで慣れ親しんだコマンドでシステムを運用・管理できる
利用する機会が多い環境下では機能・操作性が特に重要な要素だと思います。GitLabでは、tcpdumpコマンドなどのroot権限が必要なコマンド類を利用できます。
３. データストレージをNASにできる
必要な容量が不明だったので、データ領域は拡張性のあるNAS（Network Attached Storage）にしようと思っていました。またNASなら、誤って削除してしまった際もsnapshotから復元できるという安心感がありました。
４. 利用ユーザが増えても運用コストを心配せずにすむ
GitLab導入から1年で500ユーザ近く増えていました。もしこの人数規模でGitHub Enterpriseを運用していたら、コストはかなりの額になるでしょう。
運用してみて困ったこと
おおむね順調に運用できているのですが、注意しなければいけないと思った点もあります。
１. Merge Requestをうけてマージしたときのトラブル
ぐるなびはプロジェクトにもよりますが、ブランチモデルとしてgit-flowを採用することが多いです。
GitLabでMerge Request(要するにPull Requestのことですね)を行い、コードレビューが終わったあとMergeをすると、単一のブランチ(デフォルトはdevelop)にマージされます。
以前、あるサービスでhotfixブランチを作ってGitLabの画面上からMergeしたところ、masterにはマージされました。が、実はdevelopにはマージしていなかった……という手痛いミスがありました。
git-flowで運用する際、GitLabの画面上でMergeしようとするときは注意が必要です。
２. Merge Requestが重かった
導入当初はMerge Requestの重さが気になっていましたがver.8系(8.0.0)からのバージョンアップにより直りました。
３. ソース改修は自己責任・問題は自己解決
運用のメリットとして自分で問題箇所を改修できると述べましたが、サポートがないため自己責任で行わなければなりません。自己解決がマストです。
とはいえ現在のところ、大きな問題は起こっておらず快適に運用できています。
おわりに
GitHubに慣れていると、細かなUIの違いにより「あの機能はどこにあるんだっけ」と戸惑うこともしばしばあるかもしれませんが、慣れれば気にならなくなります。
ぐるなびでは現在、数百のプロジェクトをGitLabで安定的にホスティングしています。
もし内部ホスティングでコストを抑えながらソースコード管理をしたい、というときはGitLabは非常に有力な選択肢かと思います。
お知らせ
ぐるなびでは一緒に働く仲間を募集しています。