スクラムのブランチ戦略例（エンプラ向け定期リリース）

前提

スクラムはリリースの詳細について定めていない

スプリントではリリース判断可能な成果物を完成させる

本番環境にリリースしろとは言ってない

とはいえどこかにリリースするべき

顧客は目に見えるものでしか成果を確認できない

今回は仮に本番環境にリリースすることにする

フェーズによってはリリース先は開発環境かもしれない

そのときはmainブランチをdevelopブランチにとかに読み替えてください

エンプラ向けのリリース事情

顧客は各環境の状態を正確に把握したい

いつ、なにがリリースされているか

ある程度、リリース粒度が大きくなる

スプリント期間の最後に１回リリースが落とし所

ストーリーごとの都度リリースだと細かすぎる

スプリント間でストーリーは持ち越さない

原則

持ち越す＝見積もりをミスってる

epic, featureはブランチと関係ない

今回はリリースインターバルをスプリント期間と決めているので、それを超すものは管理できない

epic > feature > リリースインターバル = スプリント期間 > story

概要

mainブランチ

本番環境にリリースしているソースコードと一致

releaseブランチ

スプリント内の複数のストーリーのコミットをまとめるブランチ

リリース単位

切り戻し単位でもある

リリース作業自体もタスク管理

タスクでもストーリーでもどっちでもいい

リリース手順や確認事項、お客さんへの連絡事項などをタスク内で管理

リリース作業が一番大事

storyブランチ

顧客への提供価値がある機能区分

スプリント内で完結

作り終わったらreleaseブランチにプルリク

hotfixブランチ

本番環境に不具合があった場合の修正リリース

subtaskブランチ

ストーリーを更に細かい作業単位で管理するブランチ

状況に応じて作成する

スプリント期間が長い場合やストーリー内で他メンバーとの分業がある場合は検討してもいいかも

タグ

スプリントの区切りでつける

2スプリント回したときのブランチ戦略のイメージ

code: aa.mmd

%%{init: { 'gitGraph': {'mainBranchName': 'main','showCommitLabel': false}} }%%

gitGraph

commit tag:"s0" type:REVERSE

branch release-s1

checkout main

branch story-hoge

commit

checkout release-s1

merge story-hoge

checkout main

branch story-piyo

commit

checkout release-s1

merge story-piyo

checkout main

merge release-s1

checkout main

branch hotfix-foo

commit

checkout main

merge hotfix-foo

commit tag:"s1"

branch release-s2

checkout main

branch story-bar

checkout story-bar

branch subtask-bar-a

commit

checkout story-bar

merge subtask-bar-a

checkout release-s2

merge story-bar

checkout main

merge release-s2

commit tag:"s2"