morimorihogeです。RubyKaigi2018は相変わらず濃い内容でしたね。
さて、MSがGitHubを買収というニュースが発表されました。これにより様々な事情によってGitHubから別のGitリポジトリサービスに移行を検討している方もいると思います（2018/06/05追記: Microsoftから公式発表がありました: Microsoft to acquire GitHub for $7.5 billion）。
移行候補の中でもGitLabはかなり長い間OSS版GitHubクローンという立ち位置で続いているプロジェクトで、OSSであることから自社サーバーでホスティングできることもあり、有力候補の一つなのではないかと思います。
※GitLab公式トップページが「Migrate from GitHub to GitLab」になってるあたり「やるな」と思いますｗ
弊社では受託開発という事情もあり、以前から自社でリポジトリサーバを立てて運用してきました（「クラウドサービス上にソースコードを置いてはいけない」というお客様が昔はいたのです 😇）。subversion、gitosisを経て今はGitLabを利用しています。
先ほどGitLabのユーザー情報を確認したところ既に6年ほどGitLab（Community Edition）の運用を続けていたことに気付いたので、これを機にGitLab自社運用に関することを軽くまとめて見ようと思います。GitHubからの移行を考えている方の参考になればと思います。
※参考までに、弊社のGitLabサーバの規模感は以下のスクショの通りです（678 repositories, 226 users）。
GitHubから移行するか否か？
GitHubからの移行にはそれなりの手間が伴います。また、GitHub専用に作られているツールやサービスは使えなくなるので、問題はGitリポジトリサーバーの移行だけでなく開発ツールにも関係してきます。
利用検討の際には開発メンバーが使っているツールも確認した方が良いでしょう（昨今では多くのツールやサービスがGitLabにも対応できますが、古めのサービスなどではGitHub以外連携できないといったものもまれにあります）。
そもそもGitHubから移行すべきなのかを冷静になって考えましょう。MSが買収したからといって直ちに何かが起こることは（きっと）ないでしょうし、今の所ここ最近のMSはOSS界隈に対してもとても協力的です。MS憎しだけで移行するのはあまり賢い選択ではないかな、と思います。
ただ、MSの競合企業やその子会社、所属組織の方針でMSの息のかかったサービスは使えないという事情がある場合には移行もやむを得ないのではないかと思いますので、この辺りは組織の政治背景によりけり、というところだと思います。
自社運用は本当に必要か？
GitHubから出て行くにあたっても、そもそも自社サーバで運用する必要があるかどうかは慎重に検討すべきです。
後述しますが、自社サーバ運用はどうしてもアップグレード対応や障害対応といったオペレーションが必要となるため、マネージドサービスではお任せできたものが自社サーバでは自分達で運用する必要があります。
個人的にはGitHubで料金的に問題なかったのであれば、自社サーバではなくGitLab.comのマネージドSaaSを使うのが良いと思います。弊社では前述の通り自社ホスティングの必要性があったため使っていませんが、マネージド版であればサーバー管理の必要もありませんし、GitHub時代とほとんど同じように使えるかと思います。
また、GitLab以外にもBitbucketやAWS CodeCommitといったサービスがありますので、そちらも当然検討の余地があると思います（CodeCommitはGitホストとしてはともかく、PRレビュー機能などがまだ弱いように思いますが、リポジトリミラーを立てたいだけなら良いと思います）。
少し話が外れますが、弊社の様に受託開発だと多数のリポジトリやユーザー（お客様側のエンジニア・担当者を含む）を登録する必要があるため、ユーザー数やリポジトリ数での課金だととてもコストが嵩んでしまうという問題がありました。
＃昨今であればお客様側にGitHubアカウントを取得してもらうといったことで対応することができますが、昔はなかなかその辺りをやるのも難しかったのです（昔話感）
OSS版（gitlab-ce）か、Enterprise Edition（gitlab-ee）か？
自社ホスティングの場合、OSS版のCommunity Edition（gitlab-ce）を使うのか、Enterprise Edition（gitlab-ee）を使うのかを選ぶことになります。
各特徴は以下のような感じです。
- Community Edition（CE）
- ライセンス料金が発生しないため、いくつリポジトリ・ユーザーを作ってもそれに応じた課金が発生しない
- コミュニティベースのサポートとなるため、トラブル時にはIssue等を見て自己解決・試行錯誤が必要になることがある
- Enterprise Edition（EE）
なお、弊社ではいくらリポジトリ・ユーザーを作成しても無料という点でCommunity Editionを利用しています。Enterprise EditionもCore版であれば無料で使えるようです。
インストール方式はどうするか？
今からGitLabサーバーを新たに立てるのであれば、公式にも記述があるようにパッケージ版が良いと思います。
後述しますがGitLabはアップグレードが頻繁にあり、これを手動で運用しようとするとかなり大変になりますので、なるべく公式から外れた運用をしないのが大事です。
また、DBMSについては今ではPostgreSQLが推奨です（Subgroupsなどの機能はMySQLだと使えません）。
弊社では6年前という昔から運用をしていた都合上、今でもソースインストールにMySQLの組み合わせですが、新たに入れる人はパッケージ＋PostgreSQLでやりましょう（昔はMySQLが推奨だったのです）。
日々の運用について
基本的にはインストールして動き出してしまえばGitHubに慣れたメンバーなら普通に運用できると思います。GitHubではPull Request（PR）が一般的だったのがGitLabではMerge Request（MR）と呼称されていたりと一部異なる点はありますが、GitHubでできたことはほとんどGitLabでも捜せば同等の機能が存在します。
この辺りはGitLabのドキュメントサイトを見たり、適当にポチポチしていればいけると思います。
以下、聞かれそうなことをいくつか書いておきます。
CIはどうするの？
GitLabに公式対応しているサービスを利用するという手もありますし、Webhookに対応するサービスであれば割と問題なく動作するものが多いと思います。
また、GitLabは元々GitLab CIというCIサービスが統合されているため、Docker等でテストが作られているのであれば自前でGitLab Runnerを用意してGitLabに登録するという手もあります。
GitLabはここ数年CI周りの機能にとても力をいれて機能拡張してきていますので、商用CIサービスにあるような基本機能は自前で用意するという手も十分現実的かと思います。
※GitLab CIを使えば全てGitLabの画面上で情報が見れるため、あちこちのサービスを行き来しなくて良いというメリットが出ます
Slack通知（その他もろもろ）はできるの？
当然Slack通知連携は用意されていますし、一般的なWebhookのための機能がありますので大抵の汎用的な連携機能を備えたサービスであれば連携できるでしょう。
ぶっちゃけ使い心地はどうなの？
3〜4年前くらいまではGitHubに搭載された機能をGitLabが追いかける、みたいなイメージだったのですが、最近のGitLabはGitHubでは搭載されていない便利機能も搭載されるようになってきており、GitLabの方がよくね？と思うこともちょいちょいあるくらいには問題ないです。
例えば最近搭載されたWebIDE機能はまだややバギーな動きもありますが、コードレビュー時に差分周辺以外のコードが簡単に参照できるという点で画期的だと思います。
他にも、MR（PR）タイトルに「WIP:」を含めるとWIPモードになり間違ってmergeできなくなる機能などは、GitHubにも取り入れて欲しい機能はあります。WIP PR開発ととても相性が良くてよくできてます :)
参考: Qiita: Work in ProgressパターンによるPull Requestを利用した開発フロー
セキュリティはどうしてるの？
GitLabは開発が活発ということもありますが、かなり頻繁なセキュリティfixを含むアップデートが行われています。
なお、セキュリティ修正を含むアップデートが出ている場合には管理画面を見るとupdate asapなどの通知が出てきます。
こうした事情から、Internet上にオープンなGitLabを設置する場合にはセキュリティ上の注意が特に必要で、定期的なアップグレードが必要となります。
弊社ではGitLabサーバは直接インターネットに公開せず、手前のリバースプロキシでIP認証やBasic認証を追加することで意図しない検索インデックス避けや総当たり攻撃避けを行っています。ただ、GitLabはGit接続にSSHも利用するため（gitlab-shell）、GitLabそのもののアップグレードが不要というわけではありません。
なんにせよ、一般的にサービスをホスティングするのと同程度のセキュリティ対策は必要、ということですね。
アップグレードは辛い（こともある）
恐らく弊社の様に昔からソースインストールで使い続けているユーザーだけだとは思うのですが、ソースインストール環境のアップグレードはやや大変です。
ソースインストールの場合はgitlab、gitlab-shell、gitlab-workhorse、gitalyなどのサブパッケージをそれぞれ上げていく必要があり、サーバ作業に慣れている人でないとこまめに更新していくのは難しいでしょう。
作業自体はマイナーバージョンごとに細かいアップグレード手順書が用意されているので、そこまで難しい作業ではなく、とても高いスキルが必要というほどではありません。
ただ、ごくごくたまにdb:migrateがコケたりyarnが止まったりすることがあるため、事前バックアップを取っての作業は必須ですし、Railsアプリケーションの知識が多少でもないとトラブルシューティングしにくいことはあります。
悲鳴の参考1:「gitlab upgrade "db:migrate" issue」の検索結果
悲鳴の参考2:「gitlab yarn issue failed」の検索結果
パッケージ版は基本パッケージ更新で対応できるかと思いますが、恐らくgitlab.ymlのdiffチェックは新機能が増えたりconfigの仕様が変わる度に自力でやることになると思います。それでもパッケージでサクッと上げられるのであればソースインストールよりはとても簡単でしょう。
というわけで辛いこともあるアップグレードなのですが、この辺りの面倒が見れる人がいない組織では古いGitLabが放置されてしまうという事態になってしまいがちだと思います。
※そして古いGitLabは不便であり、前述の様にセキュリティ上も問題があります
障害対策と対応も必要
今日の開発ではソース管理もIssue管理もGitHub/GitLabがないと始まらないため、障害時の時間的・機会的損失も大きくなります。また、capistranoの様なdeployツールの参照元リポジトリとして利用している場合には、GitLabサーバが落ちるとdeployできなくなります。
まとめ
GitLabは機能面ではGitHubの代替に十分になりますし便利ですが、自社運用しようとすると大変なことも多々あります。
また、この手の社内サービスは社内の一部の人が手空きでメンテするといったことになりがちで、その人がいなくなると更新がされなくなって死ぬといった組織の脆弱性になりやすい所でもあります。
昨今の開発ではGitHub/GitLabがないと開発作業自体が停止してしまうので、利用を決める際には後々のことも考えて適切なリソースを割くようにしていきたいものです。