Androidアプリの One Experience リリース

by こやまカニ大好き

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2024 Cookpad Inc. 6 クックパッドではレシピサービスを67ヶ国、26言語で展開中これまでは日本とそれ以外で独立した2つのサービスを運用していた One Experience は日本向けのクックパッドサービスを Global で運用されていたサービスに統一し、全てのユーザーに同じ体験を提供するプロジェクト詳しくはクックパッド開発者ブログを御覧ください。 https://techlife.cookpad.com/entry/2024/10/10/105832 One Experience プロジェクトについて

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2024 Cookpad Inc. 13 ● JP版アプリのビルド設定は、 ﬂavor で切り替え ● この作業は後続の作業をブロックするので、最初期に行う必要がある ● 具体的な手法については開発者ブログを参照 ● Android では ﬂavor dimension という仕組みを使った柔軟なビルド設定が可能で、ドキュメントも充実している ○ https://developer.android.com/build/build-variants Gradle Composite Build を用いたビルドロジックの共通化について https://techlife.cookpad.com/entry/2024/11/20/130000 JP版アプリのビルド設定

Slide 14

Slide 14 text

© 2024 Cookpad Inc. 14 ● JP版とGlobal版はバージョニングルールにも違いがあった ● Global版はセマンティックバージョニング ○ major.minor.patch.build ○ 毎週リリースのたびに minor を繰り上がる ○ hotﬁx では build が繰り上がる ● JP版は yy.ww.bb.bb ○ ww はリリース日の週番号 ○ bb はビルド番号(最大4桁) ○ 毎週リリースのたびに ww が繰り上がる ○ hotﬁx では bb が繰り上がる ● 今後も週次リリース予定なので、JP版のルールで統一することにアプリバージョン

Slide 15

Slide 15 text

© 2024 Cookpad Inc. 15 One Experience の段階リリース中はアプリバージョンのルールを一部変更していたブランチ運用やバージョニングを簡略化することで Global アプリの週次リリースへの影響を抑えるため ● 100%になるまではJPアプリを v24.27.xx.xx で固定 ● xx.xx の部分はリポジトリで管理せず、 Google Play のバージョンを見て自動で繰り上げアプリバージョン(段階リリース中)

Slide 16

Slide 16 text

© 2024 Cookpad Inc. 16 JPアプリとGlobalアプリは Firebase プロジェクトも別だった今回のプロジェクトにあたり、以下の2つの方針のどちらを取るか悩んだ。 ● Global/JPアプリで同一の Firebase プロジェクトを利用する ○ Google Analytics や Crashlytics の情報の継続性が失われる ● JPアプリではこれまで利用していた Firebase プロジェクトを維持する ○ 主にプッシュ通知まわりでバックエンドの追加開発が必要プッシュ通知のような重要な仕組みを壊さない事を優先し、 JPアプリの Firebase プロジェクトを切り替えることにした。 Firebase プロジェクト

Slide 17

Slide 17 text

© 2024 Cookpad Inc. 17 旧JPアプリ内のローカルデータを OneExperience版で扱うためには、データのマイグレーション処理が必要になる。クックパッドではほとんどのデータをサーバ側にもたせているが、以下の2種類のデータはマイグレーションが必要だった ● 認証情報のマイグレーション ○ AccountManager に保存されていた ○ 旧JPアプリのトークンとGlobalユーザーのトークンを交換することでログイン状態を継続できる ● 検索履歴のマイグレーション ○ 検索履歴はローカルDBに保存されていたローカルデータのマイグレーション

Slide 18

Slide 18 text

© 2024 Cookpad Inc. 18 ● 旧JPアプリでは AccountManager という仕組みで認証情報を保存 ● Global アプリでは AccountManager を利用していなかった ● 以下のような実装を追加した ○ 旧JP版と互換性のある AccountManager 定義を Global 版に追加 ○ アプリ起動時にマイグレーション済みでなければ AccountManager から認証情報を取得し、ログインを行う処理を追加 ○ 新しい認証情報の保存先は AccountManager ではないので、将来的には AccountManager の設定は削除予定認証情報のマイグレーション

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© 2024 Cookpad Inc. 20 ● 検索履歴は JP, Global の両方で Room に保存していた ● たまたまDatabase名が違っていたため、JPのスキーマ定義を移植し、 Globalアプリ側のDBにマイグレーション処理を仕込むことができた ● もしDB名、テーブル名が被っていたら検索履歴のマイグレーションはうまくいかなかったかもしれない ● 通常のアップデートではあり得ないDB名・マイグレーション処理の衝突が起きるので注意が必要検索履歴のマイグレーション

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© 2024 Cookpad Inc. 23 今回のプロジェクトでは、アプリのロールバックが非常に難しい ● OneEx -> JP -> OneEx の順にアップデートしたとき認証マイグレーションを適切に行えない ○ 最初の時点で OneEx版にログイン済みの場合があるため ● JP -> OneEx -> JP -> OneEx の順にアップデートしたとき 2回目の OneExアップデートで認証マイグレーションを適切に行えない ○ 1回目のアップデート時点で OneEx版にログイン済みの場合があるため ● 旧JP版とOneEx版の2つのプロジェクトのバージョン番号をあわせて更新していく必要がある ● などなどロールバックについて

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2024 Cookpad Inc. 26 これらの問題から、プロジェクトのかなり初期の段階でアプリのロールバックは行わないことに決めていたロールバックを行わない仕様にしたことで JP版アプリのメンテナンスをほぼ完全に停止できた targetSdkVersion の更新や Google Play Billing Library の更新など細々した作業もなくなり OneExperience 版の作業に集中できたロールバックについて

Slide 27

Slide 27 text

© 2024 Cookpad Inc. 27 Global 版の週次リリースフローを壊さないように、 JP版は以下の手順でリリースを行うことにした ● JPリリース用に jp-release ブランチを用意する ● JP向けの全ての修正は main ブランチにマージする ● リリースしたいタイミングで main ブランチを jp-release にマージし、 jp-release からリリースするリリース手順について

Slide 28

Slide 28 text

Slide 29

Slide 29 text

© 2024 Cookpad Inc. 29 main に常にJP向けの修正が含まれていることで複数のリリースブランチから main にバックマージする必要がなくなり、管理がシンプルになる。 jp-release に global 側の未検証のバグが入る可能性はあるが、そこはJP版のリリース頻度を上げてカバーしている。とにかく、JPアプリを高頻度、かつシンプルなフローでリリースできることに注力リリース手順について

Slide 30

Slide 30 text

© 2024 Cookpad Inc. 30 JPアプリの別ブランチ管理について ● 良い面 ○ Global アプリ側の週次リリースフローに影響を及ぼすことなく、高頻度でリリースが可能になった ○ 実際にリリース初期はかなり高頻度でリリースしていたので、有用だった ● 悪い面 ○ 特殊なリリースフローになってしまったので、リリースの自動化に関する部分が後回しになった ○ Global とリリースフローが揃い、 changelog やストア情報も完全に同期されるようになったのは先月リリースフローの反省点

Slide 31

Slide 31 text

© 2024 Cookpad Inc. 31 ● 段階リリース開始から 100% リリースするまで3週間くらい ● 期間中のAndroidアプリリリース回数は14回 ● 公開率5%で足踏みしていた期間が長く、ユーザーの反応をみてバグを修正したりUIを変更したりしていた ● 旧JPアプリではOneExperience 後のURLから起動できなくなるため、 Webが100%リリースされるタイミングで全プラットフォームが 100% リリース ● 当時は毎日 Firebase の Release Monitoring を眺めて過ごしていたリリース期間

Slide 32

Slide 32 text

© 2024 Cookpad Inc. 32 リリース前に変化を監視するためのダッシュボードを作成したりしていたが、運用してみるとログ内容が想定と違っていたりしてかなり苦労した ● Firebase プロジェクトが切り替わったことで、 Google Analytics 上での変化などを監視できなくなった ● 自前でログを取得していたので集計はできているが、 OneExperience 前後でログの内容もタイミングも変わってしまった ● そのため、ユーザー行動の監視には今でもかなり苦労しているリリース後の監視

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2024 Cookpad Inc. 34 ● リリースだけでも考えることが多くて大変なプロジェクトだったが、致命的な問題なくアプリを上書きすることができた ● ほとんどのユーザーにはUIリニューアルだと感じてもらえていそう ● 段階リリース中の変則的なリリースフローも解消され、現在はJP/Global を同時に週次リリースしている ● 今後も効率的な開発フローでクックパッドアプリの改善を進めていきますまとめ