AWS Amplifyの自動デプロイを減らすために、devをレビュー用ブランチとして使うのをやめた話
GitHubのdevブランチへpushするたびにAWS Amplifyのデプロイが走っていたため、featureブランチをコードレビュー用、devを検証環境用に分離した実例を紹介します。
うにラボでは、Next.jsで作ったWebサイトをAWS Amplifyで公開しています。
開発ではGitHubを使っていて、これまでは変更するたびに dev ブランチへpushし、GitHub上で差分を確認することがありました。
ただ、この運用にはひとつ問題がありました。
devへpushするたびにAmplifyのデプロイが走ることです。
小さな文言修正やレビューのためだけの変更でもデプロイされるため、
「GitHubでコードを確認したいだけなのに、毎回検証環境まで更新している」
という状態になっていました。
そこで、ブランチの役割を整理することにしました。
以前の運用
以前は、おおまかに次のような流れでした。
- コードを修正する
- ローカルで確認する
devにpushする- GitHub上で差分をレビューする
- 修正があれば、また
devにpushする
この方法でも開発はできます。
ただし、dev がAmplifyの検証環境と接続されている場合、pushするたびにビルド・デプロイが発生します。
たとえば、
- 文言を少し変更
- レビューで1箇所修正
- もう一度レビュー
- 別の小さな機能を追加
という作業をすると、そのたびにデプロイされます。
コードレビューと環境への反映を、同じ操作でやっていたわけです。
本当に必要だったのはGitHub上の差分確認だけだった
今回改めて考えると、毎回必要だったのは検証環境ではありませんでした。
多くの場合は、
- 変更ファイルが意図どおりか
- 余計なファイルを変更していないか
- 指定した文言だけ変わっているか
- 実装方法に問題がないか
をGitHub上で確認できれば十分です。
つまり、
コードレビューと検証環境へのデプロイを分ければいい
ということでした。
featureブランチをレビュー用にした
そこで、作業ごとに feature/... ブランチを作るようにしました。
たとえば、トップページのブログ表記を変更するときは、
feature/top-blog-branding-review
運営プロジェクトを追加するときは、
feature/operated-projects-review
プライバシーポリシーを修正するときは、
feature/privacy-adsense-review
といった形です。
作業後は、そのfeatureブランチだけGitHubへpushします。
これならGitHub上でコミットやdiffを確認できます。
一方で、dev には触りません。
devの役割を「検証環境」に限定した
整理後の役割はこうしました。
featureブランチ
開発・コードレビュー用。
GitHub上で変更内容を確認するために使います。
dev
検証環境。
実際にブラウザ上で確認したい段階になったときだけ反映します。
main
本番環境。
リリースするときだけ反映します。
この3つを分けることで、
「レビューしたいからdevへpushする」
必要がなくなりました。
レビュー修正は同じfeatureブランチで続ける
レビューで修正点が出た場合も、新しいブランチを毎回作る必要はありません。
たとえば、
feature/privacy-adsense-review
をレビューして、
「この1文だけ表現を変えたい」
となった場合は、同じブランチで修正します。
そして追加commitして、同じfeatureブランチへpushします。
これなら、
- 最初の実装
- レビュー
- 修正
- 再レビュー
という流れをひとつのブランチの中で追えます。
次の作業では、レビュー済みブランチから新しいfeatureブランチを切る
今回少し特徴的なのは、まだ dev にマージしていない状態で次の作業へ進めていることです。
そのため、レビュー済みのfeatureブランチから、次のfeatureブランチを切っています。
たとえば、
feature/top-blog-branding-review
の変更がレビュー済みになったあと、その状態を引き継いで、
feature/operated-projects-review
を作ります。
こうすると、それまでの変更を保持したまま次の作業へ進めます。
そして、本当に検証環境でまとめて確認したくなった段階で dev に反映します。
ローカル確認は今までどおり行う
featureブランチを使うようにしても、基本的な確認は変わりません。
今回のNext.jsプロジェクトでは、変更後に、
npx tsc --noEmit
と、
npm run build
を実行しています。
つまり、
- TypeScriptの型チェック
- Next.jsの本番ビルド
が成功することを確認してからcommitします。
GitHubへpushするのは、その後です。
devへ頻繁にpushしないだけで、レビューは減らしていない
今回の運用変更で重要なのは、
レビュー回数を減らしたわけではない
ということです。
むしろレビュー自体は、これまでどおり変更ごとに行っています。
変えたのは、
「レビューのためにdevを使わない
という点だけです。
以前：
修正 ↓ devへpush ↓ Amplifyデプロイ ↓ レビュー
現在：
修正 ↓ featureブランチへpush ↓ GitHubでレビュー ↓ 必要な段階だけdevへ反映
という流れになりました。
CI/CDでは「push＝何が起きるか」を意識する
Gitではpushは単純なコード共有操作に見えます。
ただ、実際の開発環境では、そのブランチにCI/CDが接続されていることがあります。
その場合、
pushは単なるGit操作ではなく、ビルドやデプロイのトリガーでもあります。
今回のケースでは、GitHub上でレビューしたいだけなのに、Amplifyまで動かしていました。
ブランチごとの役割を整理したことで、
- コードを書く場所
- レビューする場所
- 検証する場所
- 本番へ出す場所
を分けられるようになりました。
大きな仕組み変更ではありませんが、頻繁にAIを使って細かな修正を繰り返す開発では、こうした運用の整理が意外と効きます。