こんにちは、トレタ VPoEの北川です。

カジュアル面談などでよく聞かれる質問として「開発プロセスはアジャイルですか？」という質問とあわせて「リリースサイクルはどれくらいですか？」という質問を受けることがあります。

そこで今回は弊社のフロントエンドチームでのリリースサイクルとそれに対応するブランチ運用を例にして紹介しようと思います。

リリーストレインによる定期リリースサイクル

弊社のモバイルオーダー・トレタO/Xのオーダーアプリチームのリリースサイクルは週1回となっています。毎週水曜日の定期リリースという形でいわゆるリリーストレイン(ReleaseTrain)の手法となっています。

背景としては、リリース前に必ずQAによる動作確認・品質確認を行なっているという点があります。また、リリース前には利用店へのリリース内容の告知準備などもあります。そのため、開発してすぐにリリースではなくリリース日までに一定のリードタイムを設けています。関係する人が複数いるため、リリースの曜日が固定されているとでコミュニケーションは円滑になります。

ブランチ運用としては以下の図のようになります。

エンジニアは随時開発した機能はdevelopブランチへマージしていきます。毎週水曜にコードフリーズを行い、そこまでのdevelpブランチに入っている差分をpreviewブランチにマージします。previewブランチは主にQA作業を行うブランチです。ここでQAを行い問題がなければ次の水曜日にpreviewブランチをmainブランチへマージしてリリースします。

リリーストレインのデメリット

この運用におけるデメリットは、開発完了したものがリリースされるまでに１週間以上空くという点で、単純にデリバリーが遅くなります。そのため、機能追加や運用がある程度落ちついて開発が安定しているフェーズに向いています。

もう一つデメリットとしては緊急のバグ修正(Hotfix)が多いとブランチが煩雑になるという点です。リリースサイクルが短ければHotfixとせずに次のリリースタイミングに含めればよいものが、上記の周期では修正したものがリリースされるまでに最低でも1週間以上かかるため、mainブランチからHotfixブランチを切るケースが多くなってしまいます。

大規模な機能追加などを行なった後などに起こりがちで、その場合はリリースサイクルは保ちつつコードフリーズ期間を縮めるといった調整を行うことで対応しています。

トランクベースによる不定期サイクル

上記のオーダーアプリのブランチはいわゆるGitflowの手法ですが、同じトレタO/Xの開発チームの中でも管理画面アプリのチームはトランクベースでの開発プロセスをとっているのでそちらも紹介します。

トランクベースでのリリースプロセス

トランクベースの場合はエンジニアは常にmainブランチに対してマージしていきます。ただし上記の背景にもある通り、リリース前にQAを行うためmainブランチにマージされたタイミングではリリースは行われずにリリースタグを打った時点でリリースを行うようにしています。

弊社のフロントエンドのアプリケーションはVercelでホスティングをしているため、こちらもmainブランチでの自動デプロイはせずにPromoteを使ってデプロイを行っています。

QAを行う環境としてはstagingブランチを使い検証環境を用意しています。こちらはmainブランチにマージが行われたタイミングでstagingブランチにも自動で差分を取り込むようにしているため、常にmainとstagingのコードベースは同じ状態になっています。

リリースサイクルとしては不定期です。数日おきにリリースする時もあれば数週間空く場合もあり、その時の開発している機能の粒度に依存します。

トランクベース採用の背景

トランクベースにしている理由としては、オーダーアプリチームに比べてエンジニアが多かったため、featureブランチからdevelopブランチへマージする際にコンフリクトが多発していたことです。業務委託のエンジニアの出入りも多く運用ルールとして保つのも困難であったため、各自でfeatureブランチは作らずに常にmainブランチにマージし続けるという運用に切り替えました。

常にmainブランチに入れていくとリリースタイミングをずらしたい場合も発生するので、その際にはFeatureFlagを設けてリリースはするが機能は公開しない制御を行なっています。FeatureFlagの実装面についてはこちらの記事をご参照ください。