![見出し画像](https://assets.st-note.com/production/uploads/images/76385196/rectangle_large_type_2_21593847da65326d5f21798cf0ce8f8c.png?width=1200)
セマンティックリリースでバージョン上げを自動化する
最近、仕事のプロジェクトでReact NativeアプリのCI/CD環境 (Bitrise) を構築して、その際にアプリのバージョン上げをどうしようか考えたときのメモ。
やりたいこと
React Nativeでは、iOSとAndroidそれぞれバージョンをつける必要があり、ユーザー向けの1.0.0のようなバージョン名の他に、ビルド番号(Androidでは内部バージョン)も管理する必要がある。
リリースの際は、これらの番号を更新してストアにアップロードするのだけれど、CIでデプロイする方針だと、事前にファイルのバージョン&ビルド番号を書き換えてコミットしておく必要があって、書き換えるのが少し面倒という問題がある。
今のプロジェクトだと、リリースのタイミングで、develop → mainへのリリース用PRを作り、それをマージする際に、手動でバージョン情報も更新する方法を取っている。mainブランチへのマージをトリガーとして、CI/CDを起動し、ストアにアップロードしている。
セマンティックリリースで自動的にバージョンを上げる
このバージョン上げ作業を自動化するには、「セマンティックリリース」を用いることができる。コミットやPRのタイトルから、[major][minor][patch]のどの変更なのかを判定し、PRマージ後にGitHub Actionなどで自動的にバージョンの更新を行う。このときビルド番号も自動でアップデートしておく。
たとえば、「BREAKING CHANGE」の場合はmajor、「feat: xxx」の場合は、minorをアップデート、「fix: xxx」の場合はpatchをアップデート、のようにルールを事前に決めておく。
バージョンのタグ付け後、自動的にCI/CDを起動して、TestFlightなどにアプリをアップロードする。するとPRマージするたびに特にバージョンのこと考えずに、TestFlightにアプリをアップロードできる。
ただし、毎回のバージョンでアプリをリリースができるとも限らないので、ユーザー視点v1.1.0の後にv1.3.0になってしまうみたいなことが起きる可能性がある。
あとは、機械的にガンガンバージョンが上がってしまうので、途中から採用したときにそれ以前と全然バージョンの上がり方が違うみたいなことが起きる。
この辺が特に問題なさそうであれば、今のところこの方法を採用しようかなと思っている。
その他の方法
Bitriseでもバージョン上げを自動化することはできそう。
ただ、上の仕組みだとユーザー向けのバージョンを意味合いも含めて自動的に上げることはできないので、どちらにしてもセマンティックリリースのようなバージョン上げの仕組みを作っておく必要があると思う。
最後まで読んでいただきありがとうございます。 他の記事はこちらからどうぞ → https://note.com/sat0b3ee/