Open2
branch戦略についての調査
iwamasa初めに
直近でリリースフローなどでちょっと困っている事があるのでブランチ戦略で解決できないか調査する
困っていること
GitHub Flowを採用しているが、本番リリース前のテストでmain/masterブランチのコードフリーズが発生する。
その間はmain/masterブランチに完了したPull Requestを混ぜることができないため、サイクルタイムで見た時にApproveからマージ→デプロイまでの時間が伸びてしまう。
また、完了しているにも関わらず、リリースされずに残っていると価値提供の面や精神衛生上もあまりよろしくないので終わったら直ぐに混ぜる事ができる状態にしたい。
iwamasa他社事例の調査
「リリースフロー」で検索してみて、他社がどのような取り組みをしているか調査してみる。
Hakkyさんの記事
望ましいリリースフローについての記載がある。
- リリースノートを都度書いている
- 一度に多すぎる機能・画面のリリースをしない
- それは本当にそう。今は複数チームで動いている関係でこの問題が発生している
- マージのタイミングから考えるべきか？
- テストフェーズではバグ・不具合以外の対応はしない
- フリーズ日時を事前に Slack と README で共有する
- フリーズ自体は発生するが、事前に共有を行なっている
- この頻度はどれくらいなのか？
releaseブランチを使ったブランチ戦略
- main ブランチ+dev ブランチ+release ブランチ+feature/fix ブランチ
- prod ブランチ（本番環境用ブランチ）: main
- develop ブランチ（開発用ブランチ）: develop
- release ブランチ（リリース準備用ブランチ）: release/**
- 個人の開発ブランチ: feature/** または fix/**など
releaseブランチでの検証、修正中はdevelopはコードフリーズしている？
記事からはちょっと分からなかった。
フリーズしないなら不具合修正中にdevelopにリリースしない資材が入ってしまった場合はcherry-pickとかするのか？