GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 11,578 views

 

Statistics

Views

Total Views
11,578
Views on SlideShare
7,279
Embed Views
4,299

Actions

Likes
25
Downloads
77
Comments
0

12 Embeds 4,299

http://labs.crooz.co.jp 4140
http://chieko.aa-dev.com 69
https://twitter.com 48
http://ishinao.tumblr.com 14
https://www.chatwork.com 7
http://s.deeeki.com 7
http://feedly.com 6
http://ishinao.net 3
http://131.253.14.98 2
https://ocean.cybozu-dev.com 1
http://assets.txmblr.com 1
http://ngw.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • GitLab & Web Hooks & git-flowで実現する 企業向けGit環境の構築 CROOZ株式会社 技術統括本部 鈴木 優一 © CROOZ,Inc. 1
    • Gitが開発者もたらした恩恵 『ブランチ管理が容易 & ブランチ作成が高速』 Subversionと比較すると… ・ローカルにリポジトリを持っているため自由度が高い。 ⇒ サーバ側を気にせずブランチを切ったり、 ワークスペースを切り替えたりできる。 ⇒ ワークスペースの切り替えが超高速 ・trunk、branchesごとに再チェックアウトが不要 etc … Git が開発者にもたらした恩恵は非常に大きい! 一方、企業で開発する場合にGitだとつらい部分もある。 © CROOZ,Inc. 2
    • 企業でGitを利用する場合にツラいこと 1.Bareリポジトリが複数サーバに分散しがちになる。 展開の容易さから、開発サーバごとにBareリポジトリを 作成しがち。 ⇒ バックアップやgcなどのメンテコストが増加する。 2.ブランチの管理コストが増大する。ログが汚れやすい。 ブランチが容易に作成できる。 ⇒消し忘れ多発 & branch作成 & merge 多発。 3.権限の管理が難しい & 管理コストが多い。 数百人分sshの鍵設定はさすがに運用きつい。また誰でも pushできる状況はオペミスを誘発しやすい。 ⇒役割毎に権限設定できないと運用に耐えない。 4.なんだかんだいっても、導入障壁が高い。 特に非エンジニア層。クライアントツールが変わることに 抵抗がある。また移行のメリットを説明しづらい。 © CROOZ,Inc. 3
    • 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ #2 (プロダクトA) (プロダクトB) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 認証 … RedMine (リポジトリ連携) 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare 認証 Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 4
    • 諸問題の解決案 © CROOZ,Inc. 5
    • 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … 企業で運用するには 若干の難あり… 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ #2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 6
    • 現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … この問題を回避するには… 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ #2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 7
    • 諸問題の解消案 1.『ルール』を制約として付ける 特にブランチ運用。自由度が高い≒統制が困難。 自由度を下げることで統制を容易に。 2.Bareリポジトリは一元管理する サーバごとにBareを置かずに一つのサーバで一元管理。 3.Bareリポジトリを可視化する 可視化することで、意識させやすくする。 ※コマンドライン以外に手軽に見れる環境は非エンジニア層に対し Gitの有用性を理解してもらうことにも役立つ? 4.権限を細かく設定できるようにする pullのみと、push可能な権限をわけてユーザに付与 運用ブランチへのmergeは開発リーダーの承認制へ © CROOZ,Inc. 8
    • システム連携図で表すと 情シス Active Directory アカウント管理 認証 認証 開発サーバ #1 開発サーバ #2 (プロダクトA) (プロダクトB) 認証 … 認証 RedMine GitLab 3.Document Rootに展開 (local) Bare マウント 運用ブランチへのmergeを承認 エンジニア © CROOZ,Inc. Local 4.pull エンジニア(リーダー) 1.HTTPプロトコル でpush Jenkins 3.ポーリング 2.Web hooksをpost 展開 スクリプト 認証 git-flow ブランチ運用ルールを統制 リポジトリ の状況を 可視化 非エンジニア層 まずは可視化し、 Gitの導入障壁を下げる 9
    • 自社に適応可能な ブランチ戦略 © 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
    • 自社のGitブランチ戦略 大きく分けて「メイン」と「サポート」の2系統 メインブランチ 開発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
    • ブランチの種類 ~メインブランチ~ master ブランチ 現時点で本番環境で「Pre環境」もしくは「本番環境」で利用されてい るソースコードの状態を管理するブランチ。 このブランチは develop および hotfix ブランチからのみmergeされ、 commit は一切行わない。 develop ブランチ 最新の開発の結果が常に保持されているブランチ。 このブランチ上はサポート (feature, hotfix) ブランチからのみmerge され、 commit は一切行わない。 v_x.x ブランチ 運用中のマイナーバージョンを管理するブランチ。原則すべてのリビジョ ン(HotFix)は適応されない。 分離するメリット ・運用中のリリース資産と開発資産を分離して管理することができる ・開発中に本番環境に不具合が発生した際にmasterからソース取得可能 14 © CROOZ,Inc.
    • ブランチの種類 ~メインブランチ~ feature ブランチ 新機能を開発する際に develop から作成するブランチ。開発完了後に developにmergeする。 hotfix ブランチ リリース後に発生した不具合の修正や、緊急の設定変更対応などの緊急対 応時に master から作成するブランチ。開発完了後に master, develop の両方にmergeする。 release ブランチ Pre環境のorigin/masterが代行するため利用しない リリースの準備のためにdevelop から作成するブランチ。 開発完了後に master にmergeする。 © CROOZ,Inc. 15
    • ブランチ戦略 プログラマ ~新機能開発時~ ローカルリポジトリ 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.
    • ブランチ戦略 プログラマ ~緊急対応時~ ローカルリポジトリ 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
    • ブランチ戦略 プログラマ ~機能更新時~ ローカルリポジトリ 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
    • ブランチ戦略 プログラマ(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
    • ブランチ戦略 タグ命名規約 v_1.0[.1] ① ②③④ ⑤⑥ No 項目 説明 ① タグ接頭辞 “v_” ② メジャーバージョン 機能追加以上の大規模な変更がある場合に0から順に インクリメントする。 新規開発時は0で、正式リリースバージョンより1と する。 ○ ③ 区切り文字 “.” ○ ④ マイナーバージョン 機能追加の際に0から順にインクリメントする ○ ⑤ 区切り文字 “.” × ⑥ リビジョン バグFixなど不具合修正や緊急対応の場合に0から順 にインクリメントする。 ⑤と⑥は作成不要 © CROOZ,Inc. 固定 必須 固定 固定 ○ × 20
    • ブランチ戦略を実現する ための各ツール © CROOZ,Inc. 21
    • 諸問題の解消案 1.GitLab Rails製のGitHubのOSSクローン 2.展開スクリプト WebHooksを受け付けて、各Dev環境にソースコードを展開するWebの エンドポイント 3.git-flow 「A successful Git branching model」に基づく運用を補助する Git Plugin。 ※CUIに抵抗のある人にはSourceTreeに連携させて使うことを推奨 © CROOZ,Inc. 22
    • なぜGitLab? イニシャルコストが低く、最も要求に近いため 下記4ツールで比較 ツール名 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
    • GitLabの特徴 ・リポジトリブラウザ ・Merge Request ・プロジェクト毎の権限、ロール管理 ・Active Directory連携 ・コミットログ、ネットワークグラフ ・リポジトリ統計 ・Issues、Milestone ・Wiki ・Wall ・Web API ・Web Hooks、System Hooks etc… © CROOZ,Inc. 24
    • GitLabの特徴 ~リポジトリブラウザ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 25
    • GitLabの特徴 ~Merge Request~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 26
    • GitLabの特徴 ~権限、ロール管理~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 27
    • GitLabの特徴 ~コミットログ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 28
    • GitLabの特徴 ~ネットワークグラフ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 29
    • GitLabの特徴 ~リポジトリ統計~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 30
    • GitLabの特徴 ~Issues~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 31
    • GitLabの特徴 ~Milestone~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 32
    • GitLabの特徴 ~Wiki~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 33
    • GitLabの特徴 ~Web Hooks~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 34
    • GitLabの特徴 © CROOZ,Inc. ~Web API~ 35
    • メリット レビュー & 承認を行う文化の導入 Merge Request を活用することでレビュー&承認のワークフ ローを導入し、ソースコード品質を向上。 「見られる」という意識が、汚いソースを減らすことに有効 権限 & Role制御 全従業員どのリポジトリにも全員PUSH可能な状態から脱却! 役割およびリポジトリについて個別に権限制御することでよりセ キュアに。またオペミス防止に有効 ブラウザ上で可視化 『目に見える』は非常に重要! 特に非エンジニア層にGitがオタクの道楽ではなく、組織にもたら す利益が大きいことを理解してもらいやすい © CROOZ,Inc. 36
    • 副次的なメリット Gitへの拒否反応の低下 WebUIがあり各個人がサンドボックス的に使えるため、Gitへ の拒否反応を低下させるのに有効。 実際、試しにPrivateリポジトリを作っていた人は多かった ナレッジ共有の加速 今まで開発者個々に作っていた便利ツールやスクリプトはここに しか使われていが、GitLabの活用で開発者間での共有が容易にで きるためナレッジ共有が加速 © CROOZ,Inc. 37
    • 想定利用規模 利用者数 参照のみ 参照&書き込み :約300名 :約200名 リポジトリ数 会社プロダクト用 開発者個人用 © CROOZ,Inc. :約50リポジトリ :約50リポジトリ 38
    • サーバ構成 サーバースペック タイプ 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
    • 導入直後に 発覚した課題と対策 © CROOZ,Inc. 40
    • 1.想定以上のシステム負荷 Active Directory連携ができない… 【原因】 GitLabの仕様? CROOZではGmail (Google Apps)で電子メールを運用し ているため、Active Directory上のユーザの電子メールが 設定されていなかったことが原因。 【対策】 Active Directory上のユーザ全員にメールアドレスを設定 過去分についてはvbsで一括登録。 © CROOZ,Inc. 41
    • 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. 42
    • 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. 43
    • 4.展開スクリプトがBranch非対応 Dev環境にBranchが展開できず、現場から不満増大 【原因】 今まではDev環境がBareであったため、Bare上での branch作成から Document Root 側へのソースコード 展開(ローカルリポジトリ)までを行うシェルスクリプト が存在していたが、Bareが別サーバとなったため、 Document Root 側への自動ソース展開ができなくなった ため 【対策】 展開スクリプト修正。 Web HooksでローカルリポジトリとBareのリポジトリを 比較し、新規ブランチであれば、ディレクトリを作成して clone。既存ブランチであればpullするに仕様変更。 © CROOZ,Inc. 44
    • その後、運用してみて © CROOZ,Inc. 45
    • 実感したこと ~使わせる立場として~ ブラウザのUIは大事! 【導入前】 Bareが存在するサーバにログインし、コマンドを叩かない とブランチの一覧が取得できないため、明らかに利用されて いないものや、命名からは何をやっているかが不明なものが 入り乱れていて整理できない状態。 【導入後】 ブラウザで容易に状況が見れるので自発的に気づいて削除 してくれる。また指摘もしやすい。 またgit-flowによりブランチの命名を守らせる障壁が下がる ため管理が容易。 © CROOZ,Inc. 46
    • 実感したこと ~使う側の立場として~ 開発効率が向上!(Merge Request は偉大!) 【導入前】 ローカルでテスト後にBareのmasterリポジトリにpush。 コードレビューはpush後であったり、Dev上でのバグ発覚 により出戻りが多かったり、Dev環境での動作検証が行いに くい。 【導入後】 masterブランチにpushする前にソースレビューおよび指摘 事項の修正が可能に。 masterブランチに影響を出さずに検証も行えるため、Dev 環境上でのテスト&デバッグ効率も向上。 © CROOZ,Inc. 47
    • 実感したこと ~使う側の立場として~ Pre環境のリポジトリへのデプロイが楽! 【導入前】 コミットハッシュでソース差分を見ていたため、Dev環境、 Pre環境でそれぞれ最新のコミットハッシュを取得してDiff を見るため、運用が面倒 【導入後】 リリースのバージョン管理がリリースTagで行われるため、 GitLab上のTagのDiffのみ見れば差分確認が可能。 © CROOZ,Inc. 48
    • 実感したこと ~管理側の立場として~ Dev環境の設定が楽! 【導入前】 新規にBareリポジトリ作成ごとにhookスクリプトの作成が 必要。 またDev環境のリプレイスのたびにBareリポジトリの移行が 発生。 【導入後】 Web HooksのURLを設定するだけ。 またDev環境のリプレイスの際もWeb Hooks のURL中の ドメインを変更するだけ © CROOZ,Inc. 49
    • 実感したこと ~管理側の立場として~ リポジトリのバックアップが楽! 【導入前】 Bareリポジトリが追加になる毎に、hookスクリプトで バックアップ用サーバ上のBareリポジトリpush。 リポジトリが増えるごとに設定が必要なのに加え、pushが 重い。 【導入後】 GitLabのバックアップコマンドをcronに設定するだけ © CROOZ,Inc. 50
    • 実感したこと ~その他~ Gitは意外と使われている 【導入前】 Git 利用対象プロジェクトに所属している人以外は利用して いない。 また個人リポジトリを作成する人はいない (いままでする場所がない) 【導入後】 Git 利用対象プロジェクトに所属している人以外も意外と個 人リポジトリを作成し、活用している また個人リポジトリについても想定の約2倍。 ・導入時の個人リポジトリの想定数 約50 ・実際に作成された個人リポジトリの数 約100 © CROOZ,Inc. 51
    • 残課題 ブランチ戦略 & Merge Request 文化の定着化 メリットは大ききものの、まだ定着していない 地道に教えていくしかない バイナリ管理系のリポジトリの移行が未実施 大きすぎてGitに向かない。HTTP経由なんて非現実的 Windows Shadow Copy & Extreme Z-IPへ移行 Merge Request に気づきにくい 基本は声を掛け合ってやっているものの、たまに漏れる RSSを解析して社内のチャットツールに流す © CROOZ,Inc. 52
    • まとめ © CROOZ,Inc. 53
    • まとめ ・Gitは自由度が非常に高いため、何かしらの形で統制 (≒制約)しないとを企業で使う場合は運用が大変 ・Bareリポジトリを一つのサーバに統合することの メリットは大きい。 ・Pull Request がもたらす恩恵は大きい。 ・細かい課題はあるものの、GitLabでもGitHub的な ことは十分運用に耐えれる。 © CROOZ,Inc. 54