gitlab & web hooks & git-flowで実現する企業向けgit環境の構築
DESCRIPTION
TRANSCRIPT
© CROOZ,Inc. 1
GitLab & Web Hooks & git-flowで実現する 企業向けGit環境の構築
CROOZ株式会社
技術統括本部 鈴木 優一
Gitが開発者もたらした恩恵
『ブランチ管理が容易 & ブランチ作成が高速』
© CROOZ,Inc. 2
Subversionと比較すると… ・ローカルにリポジトリを持っているため自由度が高い。
⇒ サーバ側を気にせずブランチを切ったり、 ワークスペースを切り替えたりできる。
⇒ ワークスペースの切り替えが超高速
・trunk、branchesごとに再チェックアウトが不要
etc …
Git が開発者にもたらした恩恵は非常に大きい!
一方、企業で開発する場合にGitだとつらい部分もある。
企業でGitを利用する場合にツラいこと
© CROOZ,Inc. 3
1.Bareリポジトリが複数サーバに分散しがちになる。 展開の容易さから、開発サーバごとにBareリポジトリを 作成しがち。 ⇒ バックアップやgcなどのメンテコストが増加する。 2.ブランチの管理コストが増大する。ログが汚れやすい。 ブランチが容易に作成できる。 ⇒消し忘れ多発 & branch作成 & merge 多発。
3.権限の管理が難しい & 管理コストが多い。 数百人分sshの鍵設定はさすがに運用きつい。また誰でも pushできる状況はオペミスを誘発しやすい。 ⇒役割毎に権限設定できないと運用に耐えない。
4.なんだかんだいっても、導入障壁が高い。 特に非エンジニア層。クライアントツールが変わることに 抵抗がある。また移行のメリットを説明しづらい。
開発サーバ #2 (プロダクトB)
Bare
現行のGit関連システム連携図
© CROOZ,Inc. 4
開発サーバ #1 (プロダクトA)
Bare
Active Directory
認証
… RedMine
(リポジトリ連携)
Bare
Jenkins
Local
認証 認証 認証
情シス
アカウント管理
エンジニア
1.HTTPプロトコル でpush
3.hooksでpush
4.ポーリング
5.pull
リポジトリが散在
管理コスト 増加
不要なブランチ 消してくれない…
担当以外のリポジトリにPUSHできちゃう…
ログが汚い…
データ コスト増加
Bare側のブランチが意識しづらい…
自由すぎて運用しづらい…
自由すぎて 統制困難
非エンジニア層
Git移行に 消極的
意味あるの…?
ツール覚え直さなきゃ…
2.Document Rootに展開 (local)
© CROOZ,Inc. 5
諸問題の解決案
開発サーバ #2 (プロダクトB)
Bare
現行のGit関連システム連携図
© CROOZ,Inc. 6
開発サーバ #1 (プロダクトA)
Bare
Active Directory
認証
… RedMine
(リポジトリ連携)
Bare
Jenkins
Local
認証 認証 認証
情シス
アカウント管理
エンジニア
1.HTTPプロトコル でpush
3.hooksでpush
4.ポーリング
5.pull
リポジトリが散在
管理コスト 増加
不要なブランチ 消してくれない…
担当以外のリポジトリにPUSHできちゃう…
ログが汚い…
データ コスト増加
Bare側のブランチが意識しづらい…
自由すぎて運用しづらい…
自由すぎて 統制困難
非エンジニア層
Git移行に 消極的
意味あるの…?
ツール覚え直さなきゃ…
2.Document Rootに展開 (local) 企業で運用するには
若干の難あり…
開発サーバ #2 (プロダクトB)
Bare
現行のGit関連システム連携図
© CROOZ,Inc. 7
開発サーバ #1 (プロダクトA)
Bare
Active Directory
認証
… RedMine
(リポジトリ連携)
Bare
Jenkins
Local
認証 認証 認証
情シス
アカウント管理
エンジニア
1.HTTPプロトコル でpush
3.hooksでpush
4.ポーリング
5.pull
リポジトリが散在
管理コスト 増加
不要なブランチ 消してくれない…
担当以外のリポジトリにPUSHできちゃう…
ログが汚い…
データ コスト増加
Bare側のブランチが意識しづらい…
自由すぎて運用しづらい…
自由すぎて 統制困難
非エンジニア層
Git移行に 消極的
意味あるの…?
ツール覚え直さなきゃ…
2.Document Rootに展開 (local)
この問題を回避するには…
諸問題の解消案
1.『ルール』を制約として付ける
© CROOZ,Inc. 8
2.Bareリポジトリは一元管理する
3.Bareリポジトリを可視化する
4.権限を細かく設定できるようにする
特にブランチ運用。自由度が高い≒統制が困難。 自由度を下げることで統制を容易に。
サーバごとにBareを置かずに一つのサーバで一元管理。
可視化することで、意識させやすくする。 ※コマンドライン以外に手軽に見れる環境は非エンジニア層に対し Gitの有用性を理解してもらうことにも役立つ?
pullのみと、push可能な権限をわけてユーザに付与 運用ブランチへのmergeは開発リーダーの承認制へ
開発サーバ #2 (プロダクトB)
システム連携図で表すと
9
開発サーバ #1 (プロダクトA)
Active Directory
認証
… RedMine Jenkins
Local
認証 認証 認証
情シス
アカウント管理
3.ポーリング
4.pull
非エンジニア層
GitLab
Bare
認証
マウント 展開
スクリプト
エンジニア
1.HTTPプロトコル でpush
2.Web hooksをpost
3.Document Rootに展開 (local)
© CROOZ,Inc.
エンジニア(リーダー)
運用ブランチへのmergeを承認
ブランチ運用ルールを統制
git-flow
リポジトリ の状況を 可視化
まずは可視化し、 Gitの導入障壁を下げる
© CROOZ,Inc. 10
自社に適応可能な ブランチ戦略
1.ベストプラクティスから学ぶ ・「A successful Git branching model」を参考にブランチの運用 モデルを考える
2. Mergeを行う回数を減らす ・ミスの確率を減らすためには元となる母集団のMerge回数自体を減らす。 ・ミスの確率を減らすために技術的に対応できる(すべき人)にMerge操 作を限定する。
3.Mergeに対し承認のワークフローを入れる ・Mergeに対し申請、承認のワークフローを設けることでmergeを意識 的に行うように促し、結果としてmergeミスによる意図しない破壊を防 ぐ。※意味合い上のコードレビューが同時に行われる、
4.システム化できるルールとして作成する ・人のオペレーションである以上オペミスは発生するのでシステム化が行 えるルールとして作成する。
© CROOZ,Inc. 11
自社に適応可能なブランチ戦略とは?
1.性質の異なる複数のプロダクトの存在 ソーシャルゲーム :リリース周期が極めて速い。 (最大で1日あたり5回なんて日も) プロジェクトのライフサイクルが短い。
コマースサイト :リリース周期が長い。 プロジェクトのライフサイクルが長い。
2. Dev環境からPre環境へのデプロイプロセス ソーシャルゲーム :Dev環境のmasterリポジトリをPre環境の masterリポジトリにpush。 リリース周期が極めて速いため、Pre環境で問題が 発覚してもバージョンを指定してchedkoutするな ど悠長なことを行うほど余裕がなく、dev環境で修 正をかけてPre環境にすぐpush。 ※バージョンの巻き戻しは行わない
コマースサイト :基本はソーシャルゲームと同じ。 ただし、問題の対処が場当たり的になったりログが 汚れるので可能であればなんとかしたい
© CROOZ,Inc. 12
自社ならではの制約は?
大きく分けて「メイン」と「サポート」の2系統
© 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 ブランチ
現時点で本番環境で「Pre環境」もしくは「本番環境」で利用されているソースコードの状態を管理するブランチ。 このブランチは 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
ローカルリポジトリ
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.
プログラマ Bareリポジトリ
hotfix master develop feature
ローカルリポジトリ
hotfix master develop feature
① 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.
プログラマ Bareリポジトリ
hotfix master develop feature
ローカルリポジトリ
hotfix master develop feature
① 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.
プログラマ(PL)
① post-receiveで
自動でソース展開
② post-receiveで
自動でソース展開
Dev環境 (SAP)
展開スクリプト
リモートリポジトリ
hotfix master develop feature
sh
sh
develop master
Pre環境
master
v1.1 v1.0
③ remote 上で
pre master に
push
v1.1
develop master
Dev環境 (コマース)
プログラマ(PL)
コマースサイト
① 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
諸問題の解消案
1.GitLab
2.展開スクリプト
3.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 ○ 容易 無し
下記4ツールで比較
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
想定利用規模
利用者数
参照のみ :約300名 参照&書き込み :約200名
リポジトリ数
会社プロダクト用 :約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
1.想定以上のシステム負荷
Active Directory連携ができない…
【原因】 GitLabの仕様?
CROOZではGmail (Google Apps)で電子メールを運用し ているため、Active Directory上のユーザの電子メールが 設定されていなかったことが原因。 【対策】 Active Directory上のユーザ全員にメールアドレスを設定
過去分についてはvbsで一括登録。
© CROOZ,Inc. 42
2.想定以上のシステム負荷
導入直後にLA急上昇…
【原因】 想定を超える利用規模となっていたこと、および1GB近い リポジトリが同時に複数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
3.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
4.展開スクリプトが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 利用対象プロジェクトに所属している人以外も意外と個 人リポジトリを作成し、活用している
また個人リポジトリについても想定の約2倍。 ・導入時の個人リポジトリの想定数 約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的な ことは十分運用に耐えれる。