Git Flowを運用するために

Git Flowを運用するために
NaITE #23
2017/7/16

自己紹介
• 名前
– 角田俊（ツノダシュン）
• 仕事
– ソフトウェア開発
• SNS
– Twitter(@imtnd)
– Facebook
• 活動
– NaITE（長崎IT技術社会）実行委員
– WACATE実行委員

今日の内容
• Git Flowを運用するときに気をつけること
–テスト計画とブランチの定義について
–適切なFeature分割について

Git Flowとは？
• Gitのブランチモデルの一つ
• Vincent Driessen氏の
A successful Git branching modelから
http://nvie.com/posts/a-successful-git-branching-model/
• 作成するブランチ
– Feature（複数）
– Develop
– Release
– Hotfixes
– Master (元々あるやつ)

Git Flowとは？
• ブランチモデルは他にもある
• もっと詳しく知りたい人は以下の資料参照
https://speakerdeck.com/nihonbuson/knack-of-git-management

Git Flowのメリット
• 機能の独立したリポジトリが作成できる
– 機能の独立性が明確になる
• 機能をリリースする、しないの判断が後から選択可能
• 開発とテスト、テスト工程による明確なブランチ分割
• アジャイル開発や、イテレーション開発に向いている

アジャイルやイテレーション開発
（例）
開発
テスト
開発テスト
• ざっくりとした開発イメージ

テスト計画はプロジェクト毎に異なる
• JSTQB定義のテストレベル
– コンポーネントテスト
– 統合テスト
– システムテスト
– 受け入れテスト
• テストレベルの名前もプロジェクトによって異なるが、
大体こんな感じだと思う
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf

Git Flowとテストの関連付け（例）
• それぞれのfeatureブランチで
コンポーネントテストを実施
• developブランチでfeatureを
取り入れ、結合テスト
• releaseブランチでシステムテ
ストを実施

実際の現場で適応するには
• 実際の現場はテストレベルが4段階とは限らない
– 例
– コンポーネントテスト
– 自分達での統合テスト
– 既存システムとの統合テスト
– 第三者による統合テスト
– システムテスト
– 他会社のシステムを含めたシステムテスト
– 受け入れテスト
• Git Flow運用の前には自分達のテストレベル、テストフェーズに
あったブランチを定義する必要がある
– ブランチ数
– ブランチ名（役割）

失敗
feature1 feature2 develop
time
今回は2週間で、feature1と
feature2を開発しよう。

失敗
time

失敗
time
やっぱり、今回の統合テスト
にfeature1は入れないで。

失敗
time
feature2はfeature1がないと
統合テストが実施出来ません。

Git FlowでのFeature分割
• Git Flowを効率良く運用するには適切なFeature分割が必要
• Featureは、独立した検証可能な単位の最小構成である必要
がある
– featureに依存性がないようにする
– featureがテストフェーズで検証可能な単位である必要がある
– featureに複数機能が入っていると、機能を入れる、入れないという
判断ができないため最小構成が望ましい

まとめ
• Git Flowを運用する前にはブランチの定義が必要
– ブランチ数
– ブランチの定義（役割の定義）
• Git Flowを効率良く運用するには、適切なFeature分割が必
要
– 独立した検証可能な単位の最小構成である必要がある

適切な運用フローを考えましょう

Git Flowを運用するために

More Related Content

What's hot

Similar to Git Flowを運用するために

Git Flowを運用するために