GitLab & web hooks & git-flowで実現する企業向けgit環境の構築

© CROOZ,Inc. 1

GitLab & Web Hooks & git-flowで実現する企業向けGit環境の構築

CROOZ株式会社

技術統括本部鈴木優一

Gitが開発者もたらした恩恵

『ブランチ管理が容易 & ブランチ作成が高速』

© CROOZ,Inc. 2

Subversionと比較すると… ・ローカルにリポジトリを持っているため自由度が高い。

⇒ サーバ側を気にせずブランチを切ったり、ワークスペースを切り替えたりできる。

⇒ ワークスペースの切り替えが超高速

・trunk、branchesごとに再チェックアウトが不要

etc …

Git が開発者にもたらした恩恵は非常に大きい！

一方、企業で開発する場合にGitだとつらい部分もある。

企業でGitを利用する場合にツラいこと

© CROOZ,Inc. 3

１．Bareリポジトリが複数サーバに分散しがちになる。展開の容易さから、開発サーバごとにBareリポジトリを作成しがち。 ⇒ バックアップやgcなどのメンテコストが増加する。２．ブランチの管理コストが増大する。ログが汚れやすい。ブランチが容易に作成できる。 ⇒消し忘れ多発 & branch作成 & ｍerge 多発。

３．権限の管理が難しい & 管理コストが多い。数百人分sshの鍵設定はさすがに運用きつい。また誰でも pushできる状況はオペミスを誘発しやすい。 ⇒役割毎に権限設定できないと運用に耐えない。

４．なんだかんだいっても、導入障壁が高い。特に非エンジニア層。クライアントツールが変わることに抵抗がある。また移行のメリットを説明しづらい。

開発サーバ #2 (プロダクトB)

Bare

現行のGit関連システム連携図

© CROOZ,Inc. 4

開発サーバ #1 (プロダクトA)

Bare

Active Directory

認証

… RedMine

(リポジトリ連携)

Bare

Jenkins

Local

認証認証認証

情シス

アカウント管理

エンジニア

１．HTTPプロトコルでpush

３．hooksでpush

４．ポーリング

５．pull

リポジトリが散在

管理コスト増加

不要なブランチ消してくれない…

担当以外のリポジトリにPUSHできちゃう…

ログが汚い…

データコスト増加

Bare側のブランチが意識しづらい…

自由すぎて運用しづらい…

自由すぎて統制困難

非エンジニア層

Git移行に消極的

意味あるの…？

ツール覚え直さなきゃ…

２．Document Rootに展開 (local)

© CROOZ,Inc. 5

諸問題の解決案


Bare


© CROOZ,Inc. 6


Bare

Active Directory

認証

… RedMine


Bare

Jenkins

Local

認証認証認証

情シス


エンジニア


３．hooksでpush


５．pull





ログが汚い…









２．Document Rootに展開 (local) 企業で運用するには

若干の難あり…


Bare


© CROOZ,Inc. 7


Bare

Active Directory

認証

… RedMine


Bare

Jenkins

Local

認証認証認証

情シス


エンジニア


３．hooksでpush


５．pull





ログが汚い…









２．Document Rootに展開 (local)

この問題を回避するには…

諸問題の解消案

１．『ルール』を制約として付ける

© CROOZ,Inc. 8

２．Bareリポジトリは一元管理する

３．Bareリポジトリを可視化する

４．権限を細かく設定できるようにする

特にブランチ運用。自由度が高い≒統制が困難。自由度を下げることで統制を容易に。

サーバごとにBareを置かずに一つのサーバで一元管理。

可視化することで、意識させやすくする。 ※コマンドライン以外に手軽に見れる環境は非エンジニア層に対し Gitの有用性を理解してもらうことにも役立つ？

pullのみと、push可能な権限をわけてユーザに付与運用ブランチへのmergeは開発リーダーの承認制へ


システム連携図で表すと

9


Active Directory

認証

… RedMine Jenkins

Local

認証認証認証

情シス


３．ポーリング

４．pull


GitLab

Bare

認証

マウント展開

スクリプト

エンジニア


２．Web hooksをpost

３．Document Rootに展開 (local)

© CROOZ,Inc.

エンジニア(リーダー)

運用ブランチへのmergeを承認

ブランチ運用ルールを統制

git-flow

リポジトリの状況を可視化

まずは可視化し、 Gitの導入障壁を下げる

© CROOZ,Inc. 10

自社に適応可能なブランチ戦略

１．ベストプラクティスから学ぶ・「A successful Git branching model」を参考にブランチの運用モデルを考える

２． Mergeを行う回数を減らす・ミスの確率を減らすためには元となる母集団のMerge回数自体を減らす。・ミスの確率を減らすために技術的に対応できる（すべき人）にMerge操作を限定する。

３．Mergeに対し承認のワークフローを入れる・Mergeに対し申請、承認のワークフローを設けることでmergeを意識的に行うように促し、結果としてmergeミスによる意図しない破壊を防ぐ。※意味合い上のコードレビューが同時に行われる、

４．システム化できるルールとして作成する・人のオペレーションである以上オペミスは発生するのでシステム化が行えるルールとして作成する。

© CROOZ,Inc. 11

自社に適応可能なブランチ戦略とは？

１．性質の異なる複数のプロダクトの存在ソーシャルゲーム：リリース周期が極めて速い。（最大で１日あたり5回なんて日も）プロジェクトのライフサイクルが短い。

コマースサイト：リリース周期が長い。プロジェクトのライフサイクルが長い。

２． Dev環境からPre環境へのデプロイプロセスソーシャルゲーム：Dev環境のmasterリポジトリをPre環境の masterリポジトリにpush。リリース周期が極めて速いため、Pre環境で問題が発覚してもバージョンを指定してchedkoutするなど悠長なことを行うほど余裕がなく、dev環境で修正をかけてPre環境にすぐpush。 ※バージョンの巻き戻しは行わない

コマースサイト：基本はソーシャルゲームと同じ。ただし、問題の対処が場当たり的になったりログが汚れるので可能であればなんとかしたい

© CROOZ,Inc. 12

自社ならではの制約は？

大きく分けて「メイン」と「サポート」の２系統

© CROOZ,Inc. 13

メインブランチ

開発Team以外に公開するブランチ。ブランチには寿命はなくの開発開始からサービス終了まで存在

サポートブランチ

開発Teamのみでブランチ。ブランチには寿命があり役割が終わると破棄

系統ブランチ名規約役割分岐元マージ先寿命

メインブランチ

master 現在リリース中の状態を保持 (起点) - なし

develop 最新の開発結果を保持 - master なし

v_x.x.x 過去のバージョンを保持 master - なし

サポートブランチ

feature/[#refs] 追加機能用 develop develop あり

release/[#refs] リリース準備用（使用しない） develop master あり

hotfix/[#refs] 不具合修正用 msater develop master

あり

[#refs]には関連する作業チケット番号を記載

自社のGitブランチ戦略

© CROOZ,Inc. 14

master ブランチ

現時点で本番環境で「Ｐｒｅ環境」もしくは「本番環境」で利用されているソースコードの状態を管理するブランチ。このブランチは develop および hotfix ブランチからのみmergeされ、 commit は一切行わない。 develop ブランチ

最新の開発の結果が常に保持されているブランチ。このブランチ上はサポート (feature, hotfix) ブランチからのみmergeされ、 commit は一切行わない。

分離するメリット・運用中のリリース資産と開発資産を分離して管理することができる・開発中に本番環境に不具合が発生した際にmasterからソース取得可能

v_x.x ブランチ

運用中のマイナーバージョンを管理するブランチ。原則すべてのリビジョン(HotFix)は適応されない。

ブランチの種類～メインブランチ～

© CROOZ,Inc. 15

feature ブランチ

新機能を開発する際に develop から作成するブランチ。開発完了後に developにmergeする。

hotfix ブランチ

リリース後に発生した不具合の修正や、緊急の設定変更対応などの緊急対応時に master から作成するブランチ。開発完了後に master, develop の両方にmergeする。

release ブランチ

リリースの準備のためにdevelop から作成するブランチ。開発完了後に master にmergeする。

Pre環境のorigin/masterが代行するため利用しない

ブランチの種類～メインブランチ～

Web UI

© CROOZ,Inc.

プログラマ Bareリポジトリ

hotfix master develop feature

ローカルリポジトリ


① origin develop

をpull

② feature branch

を作成

③ commit

④ origin feature

にpush

同時にorigin に

feature branch

を作成

申請 ⑤ merge request

プログラマ(PL)

承認

⑥ develop に対し

merge

⑦ feature branch

を削除

v1.0

ブランチ戦略～新機能開発時～

Web UI

© CROOZ,Inc.





① origin master

をpull

② hotfix branch

を作成

③ commit

④ origin hotfix

にpush

同時にorigin に

hotfix branch

を作成

申請 ⑤ merge request

承認

⑥ develop, master

に対し merge &

tag付け

⑦ hotfix branch

を削除

v1.0

v1.0.1

プログラマ(PL)

ブランチ戦略～緊急対応時～

GitLab

Web UI

© CROOZ,Inc.





① origin master

をpull

② develop master

をpull

③ merge対象を

確認しmerge

request 申請

プログラマ（PL）

承認

④ master に対し

merge & tag付け

v1.0

v1.1

⑤ develop branch

をrebase v1.1

プログラマ

① origin develop,

masterをpull (localのbranchとmerge)

ブランチ戦略～機能更新時～

© CROOZ,Inc.


① post-receiveで

自動でソース展開

② post-receiveで

自動でソース展開

Dev環境 (SAP)

展開スクリプト

リモートリポジトリ


sh

sh

develop master

Pre環境

master

v1.1 v1.0

③ remote 上で

pre master に

push

v1.1

develop master

Dev環境 (コマース)


コマースサイト

① remote 上でtag

指定でcheckout

v1.1

v1.0

SAP

Pre環境

master

v1.0

v1.1

② Pre環境上でtag

指定でcheckout

ブランチ戦略～Pre環境反映時～

© CROOZ,Inc. 20

v_1.0[.1]

① ② ③ ④ ⑤ ⑥

No 項目説明必須

① タグ接頭辞 “v_” 固定 ○

② メジャーバージョン

機能追加以上の大規模な変更がある場合に0から順にインクリメントする。新規開発時は0で、正式リリースバージョンより1とする。

○

③ 区切り文字 “.” 固定 ○

④ マイナーバージョン機能追加の際に0から順にインクリメントする ○

⑤ 区切り文字 “.” 固定 ×

⑥ リビジョンバグFixなど不具合修正や緊急対応の場合に0から順にインクリメントする。 ⑤と⑥は作成不要

×

ブランチ戦略タグ命名規約

© CROOZ,Inc. 21

ブランチ戦略を実現するための各ツール

© CROOZ,Inc. 22

諸問題の解消案

１．GitLab

２．展開スクリプト

３．git-flow 「A successful Git branching model」に基づく運用を補助する Git Plugin。

※CUIに抵抗のある人にはSourceTreeに連携させて使うことを推奨

Rails製のGitHubのOSSクローン

WebHooksを受け付けて、各Dev環境にソースコードを展開するWebのエンドポイント

© CROOZ,Inc. 23

なぜGitLab？

イニシャルコストが低く、最も要求に近いため

ツール名実装 OSS インストール Pull Request

GitHub Enterprise ？ × 容易(VMで提供) あり

GitLab Rails ○ 比較的容易類似機能あり

Gitorius Rails ○ 若干難あり類似機能あり

Gitblit Java ○ 容易無し

下記４ツールで比較

GitLab とGitoriusの決め手はインストールの容易さ。

PHPエンジニアが圧倒的に多いので本当はPHP実装が望ましかったが、メンテする人が少ないのでRubyは覚える。まぁエンジニアなんて一生勉強なんだからそれでいいでしょ！

Github Enterpriseは年間$750,000（300名）≒約800万購入なんてあり得ない！

© CROOZ,Inc. 24

GitLabの特徴

・リポジトリブラウザ

・Merge Request

・プロジェクト毎の権限、ロール管理

・Active Directory連携

・コミットログ、ネットワークグラフ

・リポジトリ統計

・Issues、Milestone

・Wiki

・Wall

・Web API

・Web Hooks、System Hooks

etc…

© CROOZ,Inc. 25

GitLabの特徴～リポジトリブラウザ～

※ 運用環境のため、画像をぼかしています

© CROOZ,Inc. 26

GitLabの特徴～Merge Request～


© CROOZ,Inc. 27

GitLabの特徴～権限、ロール管理～


© CROOZ,Inc. 28

GitLabの特徴～コミットログ～


© CROOZ,Inc. 29

GitLabの特徴～ネットワークグラフ～


© CROOZ,Inc. 30

GitLabの特徴～リポジトリ統計～


© CROOZ,Inc. 31

GitLabの特徴～Issues～


© CROOZ,Inc. 32

GitLabの特徴～Milestone～


© CROOZ,Inc. 33

GitLabの特徴～Wiki～


© CROOZ,Inc. 34

GitLabの特徴～Web Hooks～


© CROOZ,Inc. 35

GitLabの特徴～Web API～

© CROOZ,Inc. 36

メリット

レビュー & 承認を行う文化の導入

Merge Request を活用することでレビュー＆承認のワークフローを導入し、ソースコード品質を向上。

「見られる」という意識が、汚いソースを減らすことに有効

権限 & Role制御

全従業員どのリポジトリにも全員PUSH可能な状態から脱却！

役割およびリポジトリについて個別に権限制御することでよりセキュアに。またオペミス防止に有効

ブラウザ上で可視化

『目に見える』は非常に重要！特に非エンジニア層にGitがオタクの道楽ではなく、組織にもたらす利益が大きいことを理解してもらいやすい

© CROOZ,Inc. 37

副次的なメリット

Gitへの拒否反応の低下

WebUIがあり各個人がサンドボックス的に使えるため、Gitへの拒否反応を低下させるのに有効。

実際、試しにPrivateリポジトリを作っていた人は多かった

ナレッジ共有の加速

今まで開発者個々に作っていた便利ツールやスクリプトはここにしか使われていが、GitLabの活用で開発者間での共有が容易にできるためナレッジ共有が加速

© CROOZ,Inc. 38

想定利用規模

利用者数

参照のみ：約３００名参照＆書き込み：約２００名

リポジトリ数

会社プロダクト用：約50リポジトリ開発者個人用：約50リポジトリ

© CROOZ,Inc. 39

サーバ構成

サーバースペック

タイプ：仮想 CPU ：4 Core メモリ：8 GByte

OS・ミドルウェアバージョン

OS ：CentOS 6.4 Git ：1.7.12.3 GitLab ：6.0 Ruby ：1.9.3p448 (2013-06-27 revision 41675)

Python ：2.7.3 Redis ：2.4.10 mysql ：5.5.31 nginx ：1.4.2

© CROOZ,Inc. 40

導入直後に発覚した課題と対策

© CROOZ,Inc. 41

１．想定以上のシステム負荷

Active Directory連携ができない…

【原因】 GitLabの仕様？

CROOZではGmail (Google Apps)で電子メールを運用しているため、Active Directory上のユーザの電子メールが設定されていなかったことが原因。【対策】 Active Directory上のユーザ全員にメールアドレスを設定

過去分についてはvbsで一括登録。

© CROOZ,Inc. 42

２．想定以上のシステム負荷

導入直後にLA急上昇…

【原因】想定を超える利用規模となっていたこと、および１GB近いリポジトリが同時に複数cloneされていたことが原因。【対策】仮想マシンへの理ステムリソースの追加 CPU 4 core ⇒ 6 core RAM 8 GByte ⇒ 16 Gbyte

リポジトリ中のSWFをGitからWindows Shadow Copy & Extreme Z-IP管理に移行。移行対象は git filter-branch コマンドに--index-filter オプションを付け、全履歴までさかのぼって削除。

© CROOZ,Inc. 43

３．push時にエラー発生

git push に status code 413 が出る

【原因】エラー内容 error: RPC failed; result=22, HTTP code = 413 要はpush するデータサイズが大きいことが原因【対策】 GitLabのアップロード上限を変更する /etc/nginx/conf.d/gitlab.conf の client_max_body_size を500Mへ

/home/git/gitlab/conf/gitlab.yml の max_sizeを52428800へ

クライアントのアップロード上限を変更する git config http.postBufferを524288000へ

© CROOZ,Inc. 44

４．展開スクリプトがBranch非対応

Dev環境にBranchが展開できず、現場から不満増大

【原因】今まではDev環境がBareであったため、Bare上での branch作成から Document Root 側へのソースコード展開（ローカルリポジトリ）までを行うシェルスクリプトが存在していたが、Bareが別サーバとなったため、 Document Root 側への自動ソース展開ができなくなったため

【対策】展開スクリプト修正。 Web HooksでローカルリポジトリとBareのリポジトリを比較し、新規ブランチであれば、ディレクトリを作成して clone。既存ブランチであればpullするに仕様変更。

© CROOZ,Inc. 45

その後、運用してみて

© CROOZ,Inc. 46

実感したこと～使わせる立場として～

ブラウザのUIは大事！

【導入前】 Bareが存在するサーバにログインし、コマンドを叩かないとブランチの一覧が取得できないため、明らかに利用されていないものや、命名からは何をやっているかが不明なものが入り乱れていて整理できない状態。【導入後】ブラウザで容易に状況が見れるので自発的に気づいて削除してくれる。また指摘もしやすい。

またgit-flowによりブランチの命名を守らせる障壁が下がるため管理が容易。

© CROOZ,Inc. 47

実感したこと～使う側の立場として～

開発効率が向上！（Merge Request は偉大！）

【導入前】ローカルでテスト後にBareのmasterリポジトリにpush。コードレビューはpush後であったり、Dev上でのバグ発覚により出戻りが多かったり、Dev環境での動作検証が行いにくい。【導入後】 masterブランチにpushする前にソースレビューおよび指摘事項の修正が可能に。 masterブランチに影響を出さずに検証も行えるため、Dev 環境上でのテスト＆デバッグ効率も向上。

© CROOZ,Inc. 48

実感したこと～使う側の立場として～

Pre環境のリポジトリへのデプロイが楽！

【導入前】コミットハッシュでソース差分を見ていたため、Dev環境、 Pre環境でそれぞれ最新のコミットハッシュを取得してDiff を見るため、運用が面倒【導入後】リリースのバージョン管理がリリースTagで行われるため、 GitLab上のTagのDiffのみ見れば差分確認が可能。

© CROOZ,Inc. 49

実感したこと～管理側の立場として～

Dev環境の設定が楽！

【導入前】新規にBareリポジトリ作成ごとにhookスクリプトの作成が必要。またDev環境のリプレイスのたびにBareリポジトリの移行が発生。【導入後】 Web HooksのURLを設定するだけ。またDev環境のリプレイスの際もWeb Hooks のURL中のドメインを変更するだけ

© CROOZ,Inc. 50

実感したこと～管理側の立場として～

リポジトリのバックアップが楽！

【導入前】 Bareリポジトリが追加になる毎に、hookスクリプトでバックアップ用サーバ上のBareリポジトリpush。リポジトリが増えるごとに設定が必要なのに加え、pushが重い。【導入後】 GitLabのバックアップコマンドをcronに設定するだけ

© CROOZ,Inc. 51

実感したこと～その他～

Gitは意外と使われている

【導入前】 Git 利用対象プロジェクトに所属している人以外は利用していない。また個人リポジトリを作成する人はいない（いままでする場所がない）【導入後】 Git 利用対象プロジェクトに所属している人以外も意外と個人リポジトリを作成し、活用している

また個人リポジトリについても想定の約２倍。・導入時の個人リポジトリの想定数約50 ・実際に作成された個人リポジトリの数約100

© CROOZ,Inc. 52

残課題

ブランチ戦略 & Merge Request 文化の定着化

メリットは大ききものの、まだ定着していない

地道に教えていくしかない

バイナリ管理系のリポジトリの移行が未実施

大きすぎてGitに向かない。HTTP経由なんて非現実的

Windows Shadow Copy & Extreme Z-IPへ移行

Merge Request に気づきにくい

基本は声を掛け合ってやっているものの、たまに漏れる

RSSを解析して社内のチャットツールに流す

© CROOZ,Inc. 53

まとめ

© CROOZ,Inc. 54

まとめ

・Gitは自由度が非常に高いため、何かしらの形で統制（≒制約）しないとを企業で使う場合は運用が大変

・Bareリポジトリを一つのサーバに統合することのメリットは大きい。

・Pull Request がもたらす恩恵は大きい。

・細かい課題はあるものの、GitLabでもGitHub的なことは十分運用に耐えれる。

Technology

GitLab & web hooks & git-flowで実現する企業向けgit環境の構築