![自社のGitブランチ戦略
大きく分けて「メイン」と「サポート」の２系統
メインブランチ
開発Team以外に公開するブランチ。
ブランチには寿命はなくの開発開始からサービス終了まで存在
サポートブランチ
開発Teamのみでブランチ。
ブランチには寿命があり役割が終わると破棄
系統
ブランチ名規約
master
メイン
develop
ブランチ
v_x.x.x
役割
現在リリース中の状態を保持
最新の開発結果を保持
過去のバージョンを保持
feature/[#refs] 追加機能用
サポート release/[#refs] リリース準備用（使用しない）
ブランチ
hotfix/[#refs]
不具合修正用
[#refs]には関連する作業チケット番号を記載
© CROOZ,Inc.
分岐元
マージ先
寿命
(起点)
-
なし
-
master
なし
master
-
なし
develop
develop
あり
develop
master
あり
msater
develop
master
あり
13](https://image.slidesharecdn.com/gitlabwebhooksgit-flowgit-140127064657-phpapp02/85/GitLab-web-hooks-git-flow-git-13-320.jpg)
![ブランチ戦略
タグ命名規約
v_1.0[.1]
① ②③④ ⑤⑥
No
項目
説明
① タグ接頭辞
“v_”
② メジャーバージョン
機能追加以上の大規模な変更がある場合に0から順に
インクリメントする。
新規開発時は0で、正式リリースバージョンより1と
する。
○
③ 区切り文字
“.”
○
④ マイナーバージョン
機能追加の際に0から順にインクリメントする
○
⑤ 区切り文字
“.”
×
⑥ リビジョン
バグFixなど不具合修正や緊急対応の場合に0から順
にインクリメントする。
⑤と⑥は作成不要
© CROOZ,Inc.
固定
必須
固定
固定
○
×
20](https://image.slidesharecdn.com/gitlabwebhooksgit-flowgit-140127064657-phpapp02/85/GitLab-web-hooks-git-flow-git-20-320.jpg)
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
- 1. GitLab & Web Hooks & git-flowで実現する 企業向けGit環境の構築 CROOZ株式会社 技術統括本部 鈴木 優一 © CROOZ,Inc. 1
- 2. Gitが開発者もたらした恩恵 『ブランチ管理が容易 & ブランチ作成が高速』 Subversionと比較すると… ・ローカルにリポジトリを持っているため自由度が高い。 ⇒ サーバ側を気にせずブランチを切ったり、 ワークスペースを切り替えたりできる。 ⇒ ワークスペースの切り替えが超高速 ・trunk、branchesごとに再チェックアウトが不要 etc … Git が開発者にもたらした恩恵は非常に大きい！ 一方、企業で開発する場合にGitだとつらい部分もある。 © CROOZ,Inc. 2
- 3. 企業でGitを利用する場合にツラいこと １．Bareリポジトリが複数サーバに分散しがちになる。 展開の容易さから、開発サーバごとにBareリポジトリを 作成しがち。 ⇒ バックアップやgcなどのメンテコストが増加する。 ２．ブランチの管理コストが増大する。ログが汚れやすい。 ブランチが容易に作成できる。 ⇒消し忘れ多発 & branch作成 & ｍerge 多発。 ３．権限の管理が難しい & 管理コストが多い。 数百人分sshの鍵設定はさすがに運用きつい。また誰でも pushできる状況はオペミスを誘発しやすい。 ⇒役割毎に権限設定できないと運用に耐えない。 ４．なんだかんだいっても、導入障壁が高い。 特に非エンジニア層。クライアントツールが変わることに 抵抗がある。また移行のメリットを説明しづらい。 © CROOZ,Inc. 3
- 4. 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 開発サーバ #1 ２．Document Rootに展開 (local) 開発サーバ #2 (プロダクトA) (プロダクトB) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 認証 … RedMine (リポジトリ連携) ３．hooksでpush Bare データ コスト増加 １．HTTPプロトコル でpush Bare 認証 Jenkins ４．ポーリング Local ５．pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…？ ツール覚え直さなきゃ… 4
- 6. 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … 企業で運用するには 若干の難あり… 開発サーバ #1 ２．Document Rootに展開 (local) 開発サーバ #2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 ３．hooksでpush Bare データ コスト増加 １．HTTPプロトコル でpush Bare Jenkins ４．ポーリング Local ５．pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…？ ツール覚え直さなきゃ… 6
- 7. 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … この問題を回避するには… 開発サーバ #1 ２．Document Rootに展開 (local) 開発サーバ #2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 ３．hooksでpush Bare データ コスト増加 １．HTTPプロトコル でpush Bare Jenkins ４．ポーリング Local ５．pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…？ ツール覚え直さなきゃ… 7
- 9. システム連携図で表すと 情シス Active Directory アカウント管理 認証 認証 開発サーバ #1 開発サーバ #2 (プロダクトA) (プロダクトB) 認証 … 認証 RedMine GitLab ３．Document Rootに展開 (local) Bare マウント 運用ブランチへのmergeを承認 エンジニア © CROOZ,Inc. Local ４．pull エンジニア(リーダー) １．HTTPプロトコル でpush Jenkins ３．ポーリング ２．Web hooksをpost 展開 スクリプト 認証 git-flow ブランチ運用ルールを統制 リポジトリ の状況を 可視化 非エンジニア層 まずは可視化し、 Gitの導入障壁を下げる 9
- 11. 自社に適応可能なブランチ戦略とは？ １．ベストプラクティスから学ぶ ・「A successful Git branching model」を参考にブランチの運用 モデルを考える ２． Mergeを行う回数を減らす ・ミスの確率を減らすためには元となる母集団のMerge回数自体を減らす。 ・ミスの確率を減らすために技術的に対応できる（すべき人）にMerge操 作を限定する。 ３．Mergeに対し承認のワークフローを入れる ・Mergeに対し申請、承認のワークフローを設けることでmergeを意識 的に行うように促し、結果としてmergeミスによる意図しない破壊を防 ぐ。※意味合い上のコードレビューが同時に行われる、 ４．システム化できるルールとして作成する ・人のオペレーションである以上オペミスは発生するのでシステム化が行 えるルールとして作成する。 © CROOZ,Inc. 11
- 12. 自社ならではの制約は？ １．性質の異なる複数のプロダクトの存在 ソーシャルゲーム ：リリース周期が極めて速い。 （最大で１日あたり5回なんて日も） プロジェクトのライフサイクルが短い。 コマースサイト ：リリース周期が長い。 プロジェクトのライフサイクルが長い。 ２． Dev環境からPre環境へのデプロイプロセス ソーシャルゲーム ：Dev環境のmasterリポジトリをPre環境の masterリポジトリにpush。 リリース周期が極めて速いため、Pre環境で問題が 発覚してもバージョンを指定してchedkoutするな ど悠長なことを行うほど余裕がなく、dev環境で修 正をかけてPre環境にすぐpush。 ※バージョンの巻き戻しは行わない コマースサイト © CROOZ,Inc. ：基本はソーシャルゲームと同じ。 ただし、問題の対処が場当たり的になったりログが 汚れるので可能であればなんとかしたい 12
- 13. 自社のGitブランチ戦略 大きく分けて「メイン」と「サポート」の２系統 メインブランチ 開発Team以外に公開するブランチ。 ブランチには寿命はなくの開発開始からサービス終了まで存在 サポートブランチ 開発Teamのみでブランチ。 ブランチには寿命があり役割が終わると破棄 系統 ブランチ名規約 master メイン develop ブランチ v_x.x.x 役割 現在リリース中の状態を保持 最新の開発結果を保持 過去のバージョンを保持 feature/[#refs] 追加機能用 サポート release/[#refs] リリース準備用（使用しない） ブランチ hotfix/[#refs] 不具合修正用 [#refs]には関連する作業チケット番号を記載 © CROOZ,Inc. 分岐元 マージ先 寿命 (起点) - なし - master なし master - なし develop develop あり develop master あり msater develop master あり 13
- 14. ブランチの種類 ～メインブランチ～ master ブランチ 現時点で本番環境で「Ｐｒｅ環境」もしくは「本番環境」で利用されてい るソースコードの状態を管理するブランチ。 このブランチは develop および hotfix ブランチからのみmergeされ、 commit は一切行わない。 develop ブランチ 最新の開発の結果が常に保持されているブランチ。 このブランチ上はサポート (feature, hotfix) ブランチからのみmerge され、 commit は一切行わない。 v_x.x ブランチ 運用中のマイナーバージョンを管理するブランチ。原則すべてのリビジョ ン(HotFix)は適応されない。 分離するメリット ・運用中のリリース資産と開発資産を分離して管理することができる ・開発中に本番環境に不具合が発生した際にmasterからソース取得可能 14 © CROOZ,Inc.
- 15. ブランチの種類 ～メインブランチ～ feature ブランチ 新機能を開発する際に develop から作成するブランチ。開発完了後に developにmergeする。 hotfix ブランチ リリース後に発生した不具合の修正や、緊急の設定変更対応などの緊急対 応時に master から作成するブランチ。開発完了後に master, develop の両方にmergeする。 release ブランチ Pre環境のorigin/masterが代行するため利用しない リリースの準備のためにdevelop から作成するブランチ。 開発完了後に master にmergeする。 © CROOZ,Inc. 15
- 16. ブランチ戦略 プログラマ ～新機能開発時～ ローカルリポジトリ feature develop hotfix master Bareリポジトリ Web UI feature develop hotfix master v1.0 ① origin develop をpull ② feature branch を作成 ③ commit ④ origin feature にpush 同時にorigin に feature branch を作成 ⑤ merge request 申請 プログラマ(PL) 承認 ⑥ develop に対し merge ⑦ feature branch を削除 © CROOZ,Inc.
- 17. ブランチ戦略 プログラマ ～緊急対応時～ ローカルリポジトリ feature develop hotfix master Bareリポジトリ Web UI feature develop hotfix master v1.0 ① origin master をpull ② hotfix branch を作成 ③ commit ④ origin hotfix にpush 同時にorigin に hotfix branch を作成 ⑤ merge request 申請 プログラマ(PL) 承認 ⑥ develop, master に対し merge & tag付け ⑦ hotfix branch を削除 © CROOZ,Inc. v1.0.1
- 18. ブランチ戦略 プログラマ ～機能更新時～ ローカルリポジトリ feature develop hotfix master GitLab Web UI Bareリポジトリ feature develop hotfix master v1.0 ① origin master をpull ② develop master をpull ③ merge対象を 確認しmerge request 申請 プログラマ（PL） 承認 v1.1 ④ master に対し merge & tag付け ⑤ develop branch をrebase プログラマ ① origin develop, masterをpull (localのbranchとmerge) © CROOZ,Inc. v1.1
- 19. ブランチ戦略 プログラマ（PL） SAP ① post-receiveで 自動でソース展開 ② post-receiveで 自動でソース展開 ～Pre環境反映時～ リモートリポジトリ Pre環境 Dev環境 (SAP) feature develop hotfix master v1.1 展開スクリプト develop master sh master v1.0 v1.1 sh ③ remote 上で pre master に push v1.1 プログラマ（PL） コマースサイト Pre環境 Dev環境 (コマース) develop master ① remote 上でtag 指定でcheckout ② Pre環境上でtag 指定でcheckout © CROOZ,Inc. v1.0 master v1.0 v1.1
- 20. ブランチ戦略 タグ命名規約 v_1.0[.1] ① ②③④ ⑤⑥ No 項目 説明 ① タグ接頭辞 “v_” ② メジャーバージョン 機能追加以上の大規模な変更がある場合に0から順に インクリメントする。 新規開発時は0で、正式リリースバージョンより1と する。 ○ ③ 区切り文字 “.” ○ ④ マイナーバージョン 機能追加の際に0から順にインクリメントする ○ ⑤ 区切り文字 “.” × ⑥ リビジョン バグFixなど不具合修正や緊急対応の場合に0から順 にインクリメントする。 ⑤と⑥は作成不要 © CROOZ,Inc. 固定 必須 固定 固定 ○ × 20
- 22. 諸問題の解消案 １．GitLab Rails製のGitHubのOSSクローン ２．展開スクリプト WebHooksを受け付けて、各Dev環境にソースコードを展開するWebの エンドポイント ３．git-flow 「A successful Git branching model」に基づく運用を補助する Git Plugin。 ※CUIに抵抗のある人にはSourceTreeに連携させて使うことを推奨 © CROOZ,Inc. 22
- 23. なぜGitLab？ イニシャルコストが低く、最も要求に近いため 下記４ツールで比較 ツール名 GitHub Enterprise GitLab Gitorius Gitblit 実装 ？ Rails Rails Java OSS × ○ ○ ○ インストール 容易(VMで提供) 比較的容易 若干難あり 容易 Pull Request あり 類似機能あり 類似機能あり 無し GitLab とGitoriusの決め手はインストールの容易さ。 Github Enterpriseは年間$750,000（300名）≒約800万 購入なんてあり得ない！ PHPエンジニアが圧倒的に多いので本当はPHP実装が望まし かったが、メンテする人が少ないのでRubyは覚える。 まぁエンジニアなんて一生勉強なんだからそれでいいでしょ！ © CROOZ,Inc. 23
- 24. GitLabの特徴 ・リポジトリブラウザ ・Merge Request ・プロジェクト毎の権限、ロール管理 ・Active Directory連携 ・コミットログ、ネットワークグラフ ・リポジトリ統計 ・Issues、Milestone ・Wiki ・Wall ・Web API ・Web Hooks、System Hooks etc… © CROOZ,Inc. 24
- 26. GitLabの特徴 ～Merge Request～ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 26
- 34. GitLabの特徴 ～Web Hooks～ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 34
- 36. メリット レビュー & 承認を行う文化の導入 Merge Request を活用することでレビュー＆承認のワークフ ローを導入し、ソースコード品質を向上。 「見られる」という意識が、汚いソースを減らすことに有効 権限 & Role制御 全従業員どのリポジトリにも全員PUSH可能な状態から脱却！ 役割およびリポジトリについて個別に権限制御することでよりセ キュアに。またオペミス防止に有効 ブラウザ上で可視化 『目に見える』は非常に重要！ 特に非エンジニア層にGitがオタクの道楽ではなく、組織にもたら す利益が大きいことを理解してもらいやすい © CROOZ,Inc. 36
- 38. 想定利用規模 利用者数 参照のみ 参照＆書き込み ：約３００名 ：約２００名 リポジトリ数 会社プロダクト用 開発者個人用 © CROOZ,Inc. ：約50リポジトリ ：約50リポジトリ 38
- 39. サーバ構成 サーバースペック タイプ CPU メモリ ：仮想 ：4 Core ：8 GByte OS・ミドルウェアバージョン OS Git GitLab Ruby Python Redis mysql nginx © CROOZ,Inc. ：CentOS 6.4 ：1.7.12.3 ：6.0 ：1.9.3p448 (2013-06-27 revision 41675) ：2.7.3 ：2.4.10 ：5.5.31 ：1.4.2 39
- 41. １．想定以上のシステム負荷 Active Directory連携ができない… 【原因】 GitLabの仕様？ CROOZではGmail (Google Apps)で電子メールを運用し ているため、Active Directory上のユーザの電子メールが 設定されていなかったことが原因。 【対策】 Active Directory上のユーザ全員にメールアドレスを設定 過去分についてはvbsで一括登録。 © CROOZ,Inc. 41
- 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. 42
- 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. 43
- 44. ４．展開スクリプトがBranch非対応 Dev環境にBranchが展開できず、現場から不満増大 【原因】 今まではDev環境がBareであったため、Bare上での branch作成から Document Root 側へのソースコード 展開（ローカルリポジトリ）までを行うシェルスクリプト が存在していたが、Bareが別サーバとなったため、 Document Root 側への自動ソース展開ができなくなった ため 【対策】 展開スクリプト修正。 Web HooksでローカルリポジトリとBareのリポジトリを 比較し、新規ブランチであれば、ディレクトリを作成して clone。既存ブランチであればpullするに仕様変更。 © CROOZ,Inc. 44
- 49. 実感したこと ～管理側の立場として～ Dev環境の設定が楽！ 【導入前】 新規にBareリポジトリ作成ごとにhookスクリプトの作成が 必要。 またDev環境のリプレイスのたびにBareリポジトリの移行が 発生。 【導入後】 Web HooksのURLを設定するだけ。 またDev環境のリプレイスの際もWeb Hooks のURL中の ドメインを変更するだけ © CROOZ,Inc. 49
- 51. 実感したこと ～その他～ Gitは意外と使われている 【導入前】 Git 利用対象プロジェクトに所属している人以外は利用して いない。 また個人リポジトリを作成する人はいない （いままでする場所がない） 【導入後】 Git 利用対象プロジェクトに所属している人以外も意外と個 人リポジトリを作成し、活用している また個人リポジトリについても想定の約２倍。 ・導入時の個人リポジトリの想定数 約50 ・実際に作成された個人リポジトリの数 約100 © CROOZ,Inc. 51
- 52. 残課題 ブランチ戦略 & Merge Request 文化の定着化 メリットは大ききものの、まだ定着していない 地道に教えていくしかない バイナリ管理系のリポジトリの移行が未実施 大きすぎてGitに向かない。HTTP経由なんて非現実的 Windows Shadow Copy & Extreme Z-IPへ移行 Merge Request に気づきにくい 基本は声を掛け合ってやっているものの、たまに漏れる RSSを解析して社内のチャットツールに流す © CROOZ,Inc. 52