モノレポ

• api
• web
• db

という３つのインフラが異なるやつ

trunkベース開発(mainブランチにどんどんコミットしていく戦略)を組み合わせたときのリリースフローを考える。

release-api
release-web
release-db
ブランチをそれぞれ作成する。

mainブランチからPRを作成し、Squashマージする

コミットメッセージをconventional commitなものにする

マージ後、GitHub Actionを発火しsematic versioningによって、バージョンを変更、テストが通過すれば、デプロイする

もっとカジュアルに開発するなら、ローカルでsquash mergeしてpushする。
pushを条件にGitHub Actionを発火し、あとは同じ

モノレポ＆トランクベース開発のつらいところ

影響のあるインフラをチェックするのに、そのライブラリの機能を使うturbo ls --affectedみたいな。
これは、直前のコミットとの差分をみている。
そのため、次のような運用には向かない

• ローカルで複数コミットしてまとめてpush → 最後のコミットしかGitHub Actionでみてくれない
• トランクベースでpushされたらテストして、ビルドして、デプロイ → テストでコケると次のコミットがテストの修正箇所のみになり、他のインフラが影響範囲としてカウントされない

機能ブランチによるプルリクは変更単位として、とてもよいな
差分はメインブランチとの間なので、影響コード情報がなくなることがない。
ローカル複数コミット運用もできる

モノレポ&トランクベース開発をしているところは、ここらへんどうしてるんだろう？