Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

47.213 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

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

×