Contenu connexe
Similaire à GitLab & web hooks & git-flowで実現する企業向けgit環境の構築 (20)
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
- 1. GitLab & Web Hooks
& git-flowで実現する
企業向けGit環境の構築
CROOZ株式会社
技術統括本部 鈴木 優一
© CROOZ,Inc.
1
- 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
- 11. 自社に適応可能なブランチ戦略とは?
1.ベストプラクティスから学ぶ
・「A successful Git branching model」を参考にブランチの運用
モデルを考える
2. Mergeを行う回数を減らす
・ミスの確率を減らすためには元となる母集団のMerge回数自体を減らす。
・ミスの確率を減らすために技術的に対応できる(すべき人)にMerge操
作を限定する。
3.Mergeに対し承認のワークフローを入れる
・Mergeに対し申請、承認のワークフローを設けることでmergeを意識
的に行うように促し、結果としてmergeミスによる意図しない破壊を防
ぐ。※意味合い上のコードレビューが同時に行われる、
4.システム化できるルールとして作成する
・人のオペレーションである以上オペミスは発生するのでシステム化が行
えるルールとして作成する。
© CROOZ,Inc.
11
- 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
- 20. ブランチ戦略
タグ命名規約
v_1.0[.1]
① ②③④ ⑤⑥
No
項目
説明
① タグ接頭辞
“v_”
② メジャーバージョン
機能追加以上の大規模な変更がある場合に0から順に
インクリメントする。
新規開発時は0で、正式リリースバージョンより1と
する。
○
③ 区切り文字
“.”
○
④ マイナーバージョン
機能追加の際に0から順にインクリメントする
○
⑤ 区切り文字
“.”
×
⑥ リビジョン
バグFixなど不具合修正や緊急対応の場合に0から順
にインクリメントする。
⑤と⑥は作成不要
© CROOZ,Inc.
固定
必須
固定
固定
○
×
20
- 36. メリット
レビュー & 承認を行う文化の導入
Merge Request を活用することでレビュー&承認のワークフ
ローを導入し、ソースコード品質を向上。
「見られる」という意識が、汚いソースを減らすことに有効
権限 & Role制御
全従業員どのリポジトリにも全員PUSH可能な状態から脱却!
役割およびリポジトリについて個別に権限制御することでよりセ
キュアに。またオペミス防止に有効
ブラウザ上で可視化
『目に見える』は非常に重要!
特に非エンジニア層にGitがオタクの道楽ではなく、組織にもたら
す利益が大きいことを理解してもらいやすい
© CROOZ,Inc.
36
- 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
- 52. 残課題
ブランチ戦略 & Merge Request 文化の定着化
メリットは大ききものの、まだ定着していない
地道に教えていくしかない
バイナリ管理系のリポジトリの移行が未実施
大きすぎてGitに向かない。HTTP経由なんて非現実的
Windows Shadow Copy & Extreme Z-IPへ移行
Merge Request に気づきにくい
基本は声を掛け合ってやっているものの、たまに漏れる
RSSを解析して社内のチャットツールに流す
© CROOZ,Inc.
52