Open2023/07/09にコメント追加3

webアプリのリリースフロー自動化

yoonchul koh

git flowで管理しているプロダクトのリリースフローを自動化したい。

筆者はiOSアプリのリリース自動化は経験があるが、Webアプリでは無い。
デファクトがあるならなるべくそれに寄せたいところ。

現状の開発からリリースまでの流れ

開発は develop から feature ブランチを切る。
開発したら PR を出してレビュー依頼。
Approve されたら develop ブランチにマージ。GitHub Actions で開発環境にデプロイされる。
リリースのタイミングで、 develop から release(eg. release/v1.0.1) ブランチを切る。
releaseブランチをステージング環境にデプロイ（GitHub Actions を手動実行）して確認する。
ステージング環境で問題なかったら、 release ブランチを main ブランチにマージしてプロダクション環境にデプロイする。
main ブランチでタグを切って push。GitHub の releases ページを作成する。
release ブランチで fix したものがあれば、main -> develop にPR出してマージする。

この手順の中で、手作業が多いので自動化したい。

手作業している内容

release ブランチの作成と push 。バージョン（セマンティックバージョン）を自分で決める必要がある。
ステージング環境へのデプロイ。GitHub Actions 上で、フロントエンドとバックエンドのデプロイを手動実行。
main ブランチでバージョンタグを切って、push。
GitHub の releases ページ作成。リリースのノートの記述。
main -> develop マージPR作成。

yoonchul koh

リリース自動化に関する情報収集

release-drafter という Github Actions で、半自動的にリリースノートを作成。
これを使うことで、バージョン番号のタグがつき、GitHub Releases にリリースを作成できる。
ただ、 GtiHub Flow を想定してるっぽい？main ブランチと feature ブランチでの開発。

こちらはリリースブランチを main ブランチにマージしたときだけ動かすパターン。
ただし、当然ながら feature ブランチをマージしたタイミングで、今どこまで変更入るんだっけ？は確認できない。

自動化について、5つほど方法を紹介している。

Release Please という Google 製ツールの紹介。
良さそうではあるが、 main ブランチを開発ブランチとしていて、どこにリリースPRをマージするのか読み取れなかった。。
develop で開発して main にマージと考えれば良いのかも？

全体の流れとしてはやりたいことに一番近いかもしれない。
ただ、それぞれの実際の自動化手法などは記載されていない。

yoonchul koh

まとめるとこんな流れが良いかも。

develop から release ブランチを切って、release ブランチをステージングにデプロイする。
そのタイミングで、 release ブランチ → main ブランチへのリリースPRを作る。そのPRにはリリースする feature PR 一覧が載っている。
main にマージしたら本番にデプロイされ、GitHub Releases が draft で自動生成される。
確認して Publish release して完了。