ブランチ運用とリリースプロセスは不可分

概要

ブランチ運用についてどのようにされていますか？

よくあるパターンはGit flowとGitHub flowですが、ブランチ運用について検討する際にGit flowとGitHub flowのどちらが良いだろうかという観点だけでは片手落ちになってしまっていると感じます。

タイトルの通りですが、全体最適の観点からブランチ運用とリリースプロセスは不可分であると考えて弊チームではどのように運用しているか記載しようと思います。

結論だけ先に記載するとブランチ=環境方式でマルチレポにしています。

前提

• ソースコード管理にはGitHubを使用する
• SaaS開発
  • AsanaやJIRAのようなプロジェクト管理ツールを開発しているイメージです
• フロントエンドとバックエンドに分かれて開発する
  • フロントエンド: Next.js、Vercel
  • バックエンド: NestJS、Cloud Run
• スマホアプリはないものとする
  • iOS/Androidが存在する、クロスプラットフォームフレームワークを使用しているかいないか、など考慮点が増えるので記載しません。
    • 同じ考え方で対応できそうだと考えています。

ブランチ運用とリリースプロセスに求めるもの

• 今デプロイされているソースコードが容易に把握できる
• フロントエンドとバックエンドはそれぞれ独立してデプロイが可能
• Production、Staging、Develop環境が欲しい
  • Staging環境はステークホルダー(PdM、デザイナー、QA)が動作確認するための環境です
  • Develop環境はエンジニアが動作確認するための環境です
    • チームが小さいときなど、Develop環境はローカルというパターンもあると思いますが、一旦クラウド上に構築するものとしてみます
• Production、Staging、Develop環境のデプロイには時差がある
  • Productionデプロイ前にステークホルダーの確認はしたいがすぐに完了するとは限らない
  • Productionデプロイは週1などと決まっているパターンもあると思います

実装完了後のリリースプロセス

1. レビュー済みのデプロイ可能なソースコードが完成する
2. Develop環境にデプロイしてエンジニアが確認する
3. Develop環境で確認OKであれば、Staging環境にデプロイしてステークホルダーが確認する
4. Staging環境で確認OKであれば、Production環境にデプロイする

手段の検討

ブランチ=環境方式 vs リリースタグ方式

デプロイ方式についてはよくあるのがこの2つだと思います。

• ブランチ=環境方式
  • productionブランチ = Production環境にデプロイされているとする方式です
• リリースタグ方式
  • mainブランチにマージした後にリリースタグを打つとそれぞれの環境にデプロイされる方式です

今デプロイされているソースコードを把握するという観点ではどちらでも対応可能です。

リリースタグ方式の場合、「Production、Staging、Develop環境のデプロイには時差がある」に対応するのが難しくなります。できないことはないと思いますが、検討事項が増えたり、「Aの場合はXする」といった独自運用が増えてしまったり、「今ってマージしていいんだっけ？」と悩むことになりやすいです。

ブランチ=環境方式の方がシンプルに運用できるケースが多いのと将来的にエンジニアが増えてDevelop環境が複数になったとしても対応しやすいと思います。

モノレポ vs マルチレポ

モノレポ vs マルチレポはマルチレポがよいと思います。

モノレポで上手くソースコードを管理できたら生産性が上がりそうですが、前提としてモノレポを使いこなして開発プロセスを整備できる人材が必要で、それができる人材には開発プロセスを整えるよりはプロダクト開発をリードするなど別の役割にコミットしてもらった方が事業が伸びる可能性が高いと思います。

詳細についてはいずれ「コアに集中するための技術選定」的な記事を書きたいと思っていますが、モノレポにすることで発生する課題はモノレポにしなければ発生しないんですよね。

多くのCI/CDツールがマルチレポを想定しているのでマルチレポだとCI/CDがすんなり動く可能性が高いというのもメリットとしてあると思います。

まとめ

ここまで記載してきた内容を改めて整理してどのようなプロセスなのか記載するとこのようになります。

• Repository: マルチレポ
• ブランチ運用: ブランチ=環境方式
  • 作成するブランチはproduction、staging、developの3つ
    • mainブランチはdevelopにrenameします
  • 開発者はdevelopからfeatureブランチを切って開発します
  • stagingブランチにマージされたらStaging環境に自動デプロイされるようにする
    • productionも基本的には同様でよいが、バックエンドについてはDB Migrationのタイミングを制御できる仕組みにしておくとよいです
      • マージ後にトリガーを手動でキックするとか
      • API ServerのデプロイとDB Migrationの順番が前後する可能性があるためです

Thanks

Git flowとGitHub flowの説明を読んでもしっくり来なかったのですが、Single Source of Truth となるソースコード管理をどう実現したらよいのか、という観点で考えてみると自分の中では上手く整理できた気がしています。

Single Source of Truthについてはこちらの動画がとても参考になりました。ありがとうございます！

https://event.cloudnativedays.jp/cicd2021/talks/1129

最後に

最後まで読んでいただきありがとうございました！

いいね、コメントなどもらえると励みになるのでお願いいたします！