去る 6月4日、Microsoft による GitHub 買収が発表されました。過剰に反応するニュースではないものの、この機会に GitHub 以外の Git ホスティングサービスに触れてるのもいい経験になるのではないでしょうか。本稿は、GitHub からの有力な移行先の一つとして GitLab を提案するものです。
GitLab が単なる GitHub のクローンサービスだったのは過去の話です。GitLab は 2014 年の法人化をきっかけに、ここ数年で積極的な機能追加がなされており、他の競合に引けも取らない Git ホスティングサービスに成長しています。
GitLab の変遷
GitLab のスタート
GitLab は 2011 年に、現 GitLab 社 CTO の Dmitriy 氏によって開発が始められました。
後に、現 CEO の Sid 氏が開発に加わり、翌年 2012 年に初めて公開されました。
「安価な GitHub クローン」
人気の高い GitHub のエンタープライズ導入コストが高い一方で、
GitLab はサポートが不要であればどんなに大きいチームでも無償で利用可能です。
当時の GitLab は GitHub と差別化できるような機能は実装されておらず、
コスト面の違いだけが大きく目立ったため、
無償の GitHub クローンという印象が強く根付いてしまいました。
ドリコムの @onk さんは、自社での採用事例において GitLab に対して「貧者の GHE」という表現を用いています。
あまり良い表現だとは思いませんが、コスト面での旨みと引き換えに運用面において多くの課題があったことがわかります。
法人化と資金調達
2014 年の法人化に始まり、2015 年の Y コンビネータへの参加、2017 年の資金調達を経て、会社は急成長しました。
この流れを経て、GitLab の活発な機能追加が行われるようになりました。
さらに、2017 年には Gitter を買収しました。
GitLab はこの時点で「打倒 GitHub」という姿勢を明確にしていて、
この買収についても、Gitter を利用している多くの OSS プロジェクトを取り込むことが目的であるとされています。
完全 DevOps サービスへ
GitLab の「打倒 GitHub」は変わりませんが、そのゴールは既に単なる Git ホスティングサービスではなくなっています。
現在の GitLab は完全 DevOps サービスを目指していて、その目的はプロジェクトの開発・運用の全てを GitLab が支援することです。
GitLab の特徴
プロダクトは OSS として公開
GitLab はオープンソースなので、ソースコードは GitLab 上で公開されています。
何か問題があった時に、それを報告するだけでなく実際に修正する変更を送るすることができます。
オンプレミス運用であれば、自分で直してすぐにデプロイできますし、既存の機能の振る舞いを調整することもできます。
競合サービスと比較して機能が充実している
GitLab は本当に多機能で、GitHub の多くの機能を忠実に取り込んでいます。
GitHub にしかないという機能は、自分の調べた限り見つけられませんでした。
そして、注目すべきは GitLab にしかない機能です。
以下の表中に太字で示した機能について順に紹介します。
| 機能 | GitHub | GitLab |
|---|---|---|
| Git ホスティング | o | o |
| Issue 機能 | o | o |
| カンバンボード | o (Projects) | o (Issue Board) |
| レビュー機能 | o (Pull Request) | o (Merge Request) |
| Pages 機能 | o (GitHub Pages) | o (GitLab Pages) |
| スニペット管理 | o (Gists) | o (Snippets) |
| API | o | o |
| DevOps 支援機能 | x | o |
| ダイアグラム言語サポート | x | o |
機能紹介：GitLab CI/CD
GitHub にはないもっとも代表的な機能が、この CI/CD 機能です。
オンプレミスで動かす場合には Runner と呼ばれる専用のサーバが必要になりますが、
サービス的に完全に統合されていて、UI 上でパイプラインの実行状況や結果が確認できます。
パイプライン設定は、リポジトリルートの .gitlab-ci.yml に基づきます。
また、Runner の実行方式（Executor）は、Docker, Shell といった中から選べます。
さらに、他社 Git ホスティングサービスに対する CI/CD にも対応しています。
例えば GitHub 上の Git リポジトリに対してパイプラインを作成し、実行結果に応じて GitHub 上の Git リポジトリのコミットステータスを更新するようなことが可能です。
機能紹介：GitLab Container Registry
GitLab は、Docker Hub のようなコンテナレジストリ機能も提供します。
Docker Repository manifest v2 へのサポートに遅れているものの、使い勝手の点では特段問題ありません。
プロジェクトに関連するイメージを、一律の公開設定で一元管理できます。（プロジェクトがプライベートならイメージもプライベート）
もちろん、CI/CD の Runner 用イメージを管理することも可能です。
機能紹介：Kubernetes クラスタへの自動デプロイ
よそで構築した Kubernetes クラスタに対して、アプリをデプロイする機能です。
プレビュー用にバージョン単位でアプリをデプロイすることも出来るようです。
# 正直あまり詳しくないので、良いソースがあれば教えてください！
機能紹介：ダイアグラム言語（Mermaid, PlantUML）のレンダリングサポート
Mermaid と PlantUML は共に、ダイアグラム（図やグラフ）をテキストとして記述するための表現形式です。
Markdown や Asciidoc といった、軽量マークアップ言語と併用される形でよく利用されます。
Mermaid なら Snippets でも使えるので、ぜひ試してみてください。
PlantUML は Asciidoc 限定でサポートしています。
ただし、こちらはオンプレミス限定の機能で、GitLab.com ではサポートされておりません。
機能紹介：GitLab Pages
GitLab Pages は、静的サイトの生成からホスティングまで一気通貫で提供する機能です。
これだけ聞くと GitHub Pages と変わりませんが、GitLab Pages の方が柔軟性の高い機能となっています。
まず、GitHub Pages は Jekyll のみに対応する機能で、プロジェクトのオプション機能の一つとして提供されています。なので、Pages を始めるには、プロジェクト設定から Pages のオプションを有効にします。一方の、GitLab Pages は CI/CD 機能の一部として提供されます。そして、GitLab Pages を有効にするには、それに応じた CI パイプラインを .gitlab-ci.yml 上で構築することになります。以下の .gitlab-ci.yml は Jekyll の例ですが、CI パイプラインでは任意の処理が実行可能なので、Hugo や Hexo といった静的サイトジェネレータにも対応できます。
image: ruby:2.1
pages:
script:
- gem install jekyll
- jekyll build -d public/
artifacts:
paths:
- public
only:
- master
GitLab のよくないところ
議論の公平性を保つために、GitLab のダークサイドについても挙げておきます。
UI がわかりづらい
最初は慣れの問題かと思いましたが、いつまで経っても慣れない自分がいます。
それとも、私の修行が足りないのでしょうか。
私は UI デザインの専門家ではないので、何が良くないかをうまく表現できないのですが、
ごちゃごちゃしていてどこに何が書かれていて、どこのボタンを押せばいいのかわかりにくい気がします。
GitLab.com が不安定
たまにダウンしてます。
GitHub.com もダウンすることがあるので何とも言いづらいですが、Snippets は明らかに重いです。
なので本当のところは、自社サーバやクラウドサーバを使ったオンプレミス運用がオススメです。
インストールに手間取るようであれば、専有サーバ上でマネージド GitLab を提供する GitLabHost を使うという手もありますし、
まだアルファリリースですが、helm chart もあります。
過去に本番データベース吹き飛ばしかけた
オペレーションミスによる障害で、Issue や Merge Request に関するデータを飛ばしかけました。
加えて、用意されていたバックアップ機構がうまく動いていなかったことが問題視されました。
驚くべきことにこの障害の復旧作業は、YouTube の GitLab 公式チャンネルでストリーミング配信されました。
配信中にはリクルートの呼びかけもあり、転んでもただでは起きない精神は呆然を通り越して感心してしまいます。
- 参考：GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
- 参考：GitLab Live Stream - YouTube
総括
GitHub から GitLab へ移行すべきか？
GitLab は現在のところマイナーサービスです。多くのオープンソースプロジェクトが GitHub で運用されていますし、なんだかんだみんな GitHub に慣れているので、開発者視点でみると移行はなかなか難しいと思います。
しかし、いまや GitLab の最も大きな強みは DevOps 支援機能です。
自動化を必要としない多くの趣味プロジェクトにおいては GitLab は機能過多となりますが、SRE を重視する中〜大規模なチームにおいては大きな役割を持つことになるでしょう。
以上のことから、個人用途には GitHub 、エンタープライズ用途には GitLab といった棲み分けが今後進んでいくんじゃないかなーと個人的には思っています。
まとめ
- もはや GitLab は単なる GitHub クローンじゃないよ！
- SRE を重視するチーム開発にフィットするよ！
- ダークサイドを踏まえると、オンプレミス運用がおすすめだよ！
- オープンソースなのでコントリビュートするといいよ！