こんにちは。コドモンプロダクト開発部の関です。
こちらの記事にもありますが、コドモンの保護者向けモバイルアプリはCordovaからCapacitorに移行しました。 この記事では移行作業を振り返ってみたいと思います。
移行方針
移行要件
移行の前提となる要件は以下の通りでした。
- 開発中のプロジェクトを止めない
- 現行アプリの見た目や挙動はなるべく変更しない
Cordovaプラグインの扱い
Capacitorは仕組み上はCordovaプラグインをそのまま使うこともできます。しかし、Cordovaプラグインの動作が完全に保証されるわけではありません。Capacitorの公式ドキュメントでは、Cordovaプラグインの互換性の問題がある可能性について言及され、Capacitorプラグインへの移行が推奨されています。このことから、CordovaプラグインがCapacitorアプリで意図しない動作を起こすことを懸念しました。
また、今回は後述するアプリの通信の非互換の影響から、広範なテストが必要になることが明らかでしたので、アプリ基盤移行後にCordovaプラグインを段階的に移行する方式は採用せず、アプリ基盤移行時にCordovaプラグインの移行も同時に実施することにしました。
移行対象のCapacitorバージョン
移行作業に着手した当時（2024年3月）、Privacy manifest対応の期限が二ヶ月後に迫っていました。Capacitor v6はRCの段階で、まだ正式リリースされていなかったのですが、CapacitorプラグインのPrivacy manifest対応がCapacitor v6で予定されているものがあったので、Capacitor v6を移行対象のバージョンに選択しました。
移行タイミング
移行タイミングは以下を必須要件としました。
- Capacitor v6の正式リリース後
- Privacy manifest対応版のプラグインが揃った後
移行計画立案
事前調査
Cordovaアプリの移行先のアプリ基盤を選定する段階で、Capacitorの調査を実施していました。調査結果として以下の内容を把握していました。
- Cordovaと同じで、アプリ内のコンテンツをWebViewで読み込む
- WebViewで読み込むコンテンツ自体の修正は主にJavaScriptが中心で、コードベースの差異は非常に少ない
- CordovaとCapacitorそれぞれアプリからの通信はネイティブを経由するケースが存在し、実装が異なる
- Web Storageに互換性がなく*1、データ移行が必要
仕組み上は大きく変わるところはないので、Web Storage移行と通信周りの非互換の懸念が解消し、プラグインの移行方針が定まればリリース日の目処が立てられると判断しました。
移行の流れ
当初計画
当初の計画は次のとおりです。
この計画を立てた時点では、移行対象のCordovaプラグインを洗い出し、移行先のCapacitorプラグインが存在するかどうか*2の調査まで実施できていました。
また、リリース時期を仮置きするために、他チームにリリース日が決まっているものがないかを確認しました。
非互換調査
利用者が影響を受ける非互換の調査と修正箇所の洗い出しを行いました。
非互換調査の詳細についてはこちらの記事をご覧ください。
アプリの通信に関する非互換は、非互換が発生した際の影響範囲が大きく、修正規模が大きく左右される可能性があるので、非互換調査の中でも早めに実施する計画にしました。
Web Storage移行
利用者がWeb Storageを移行用の修正を含むアプリバージョンにアップデートするまで一定の期間が必要なので、こちらも計画上早めに対応することにしました。
移行用ブランチ上で修正
他チームの開発が並行して進んでいくことと、現行のCordovaプロジェクトにCapacitorを追加した際にビルドに問題が発生して共存できなかったことから、最初からブランチを分岐させることにしました。メインブランチの修正を日々取り込み、修正対象が増えてないかを確認しながら進めました。
また、事前に競合が発生する可能性が高かったpackage.jsonや広範なコードフォーマットなどについては、必須の対応を除き控えてもらうように他チームに依頼しました。
CI/CDパイプライン修正
最初にビルド設定の切り替えなどローカルビルドで確認できる範囲の修正を優先させました。次に、テスト開始に必要なパイプラインの修正を計画し、残りはリリース準備としてストアリリースに必要なパイプラインを修正する計画にしました。
サポート調整
移行によって利用者が影響を受ける場合、問い合わせ対応を行なっているサポートチームに情報を共有し、都度調整の上、一緒に対応を検討していました。
特に大きな影響が明らかになった場合、リードタイムに影響する可能性が高いので、早めに情報を共有する必要があります。今回の移行では、Web Storage移行が該当しました。
大きな影響以外については、非互換調査の結果から利用者への影響をまとめて情報共有しました。サポートチームが利用者向けのマニュアルやFAQなどへの反映、問い合わせ対応の検討などを行う期間が必要になるので、スケジュール上ある程度余裕を持たせて共有する必要があります。また、このタイミングで、移行用の修正を含むアプリバージョンへのアップデート率の目標値や追加アクション、リリース時期の決定について調整を行いました。
アップデート促進
移行用の修正を含むアプリバージョンのアップデート率が低かった場合、追加アクションを実施する期間として計画していました。
各チームテスト＆バグ対応
アプリの通信の非互換のような広範な影響が想定されたので、アプリをリリースする上で、アプリ基盤上で開発を行うストリームアラインドチームにテストを依頼する必要があると判断しました。テストを依頼する時期について、この計画を策定した後、すぐにストリームアラインドチームに伝えました。
テスト開始前の準備として、重点的に確認してほしい箇所がわかるようにテスト観点をまとめ、チェックリストを準備し、説明会を実施しました。
テストで問題を検知する都度フィードバックをもらい、テストの進行を妨げてしまう問題を優先的に対応することでバグ対応を進めました。配布するアプリのリリースノートにバグ対応の履歴を記載することで、他チームに状況がわかるようにしました。
リリース準備
ストアリリース用のパイプラインの修正、リリース後の監視手順の整備、環境構築手順や調査結果など残しておくべき情報の整理を行いました。
また、他チームの開発が並行して進んでいたので、移行用ブランチのマージタイミングの調整を行いました。
振り返り
当初計画とのギャップ
アプリ基盤移行を担当したチーム内の作業については、概ね当初計画通りに対応することができました。一方で、他の開発との兼ね合いで当初計画通りにテストに着手できないチームが出てきてしまい、結果的にリリース時期を後ろ倒しにする形になりました。余裕を持って伝えていたつもりでしたが、予定の確度まで伝えきれなかったことが原因の一つと考えています。これについては、確度を含めて伝えること、一度だけでなく繰り返し伝えることが重要ではないかと思います。
また、現在コドモンではすべての開発チームでロードマップを共有、調整を行う新たな取り組みが始まっているので、今回のような課題も解決しやすい組織になったと感じています。
テストの結果
テストで検出したバグを次のようにまとめました。
いくつか修正時に気付ければよかったものもありますが、テスト観点に取り上げたものが大半を占める形になりました。アプリ基盤移行の特性上、非互換調査結果を元にしてテスト戦略を検討していけば効率的に進められるということを示していると思います。
また、コドモンの保護者向けモバイルアプリに自動化されたテストは存在するのですが、ハイブリッドアプリという特性を活かし、すべてブラウザ上でのテストになっています。今後はCapacitorやプラグインのバージョンアップをこまめに実施できるように、アプリの自動テストにもチャレンジしたいと考えています。
Capacitorに移行してみてどうだったか
こちらの記事で言及しているメリットはその通りです。
- コドモンの既存のコードベースを使うことができるので、小さいコストで移行ができる
- プラグインも比較的メンテされている
- ビルドが早くなる
- ストア申請ではなく、コードプッシュでリリースができ、リリース頻度を上げることができる
新たに、現在感じているメリットがあるので紹介しておきたいと思います。
CapacitorではXcodeプロジェクトやAndroid StudioプロジェクトをGit管理する形であり、Info.plistやAndroidManifest.xmlなどの設定ファイルやプロジェクトファイル、AppDelegateやMainActivityを修正する機会が増え、少しずつネイティブ慣れできるのではと考えています。モバイルエンジニアを一気に増やすのが難しい中、開発メンバーみんなが少しずつネイティブ領域に慣れていき、次のアプリ基盤の選択肢を広げる、という中間ステップとしても有効なのではと思います。
また、Capacitoprのプラグインは結果としてCapacitorメジャーバージョンのリリース後、一ヶ月でアプリで採用しようとしていたすべてのプラグインが新バージョンに対応していて、メンテナンスが行われていることも確認できました。
