スクラムのブランチ戦略例(エンプラ向け定期リリース)
前提
スクラムはリリースの詳細について定めていない
スプリントではリリース判断可能な成果物を完成させる
本番環境にリリースしろとは言ってない
とはいえどこかにリリースするべき
顧客は目に見えるものでしか成果を確認できない
今回は仮に本番環境にリリースすることにする
フェーズによってはリリース先は開発環境かもしれない
そのときはmainブランチをdevelopブランチにとかに読み替えてください
エンプラ向けのリリース事情
顧客は各環境の状態を正確に把握したい
いつ、なにがリリースされているか
ある程度、リリース粒度が大きくなる
スプリント期間の最後に1回リリースが落とし所
ストーリーごとの都度リリースだと細かすぎる
スプリント間でストーリーは持ち越さない
原則
持ち越す=見積もりをミスってる
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"