N予備校 Androidチームでは、アプリの配信形式を従来のAPKからAAB（Android App Bundle）に変更しました。

Google Play Storeで新しく配信する全てのAndroidアプリは、2021年8月からは配信形式をAABにしなければなりません。既存のアプリではAABへの対応は必須ではないですが、AABの恩恵を受けられるので対応するに越したことはないと思います。

しかし、CI/CDでどのようにAABをビルド・配信するか、という資料はまだ少なかったため、AABに対応するためにかなりの試行錯誤を行いました。その過程と結果を以下にまとめましたので、これからAABに対応する開発者の方々の参考になれば幸いです。

CI/CDでAABをビルド・配信する

AndroidチームのCI・CDの構成は以下になっています。

f:id:hiraike32:20210506182923p:plain

GitHubでPull Requestが作成されると、Bitrise が起動してアプリをビルド、そのアプリを DeployGate に配信して、完了したらSlackに通知します。

BitriseでAPKをビルドしていたときは、そのままAPKをDeployGateに配信すればよかったのですが、BitriseでAABをビルドするようになると、そのままAABをDeployGateに配信するわけにはいきません。

とはいえ、AABから生成されたAPKの動作確認を全くしないのはリスクがあるので、どこかでAAB→APKの変換をして動作確認をする必要があります。

AAB→APKの変換を行う場所としては2つの候補がありました。

当初は1の方法で進めていましたが、この方法ではDeployGateで本番環境の署名を用いてAABからAPKを生成する必要がありました。本番環境の署名を複数のサービスに置くことは避けたかったので、2の方法を採用しました。

（デバッグ用の署名を使ってDeployGateでAAB→APKを生成する方法も試してみましたが、アプリインストール時に「不明なアプリの警告」が出てしまったので断念しました。）

2の方法を実現するために、BitriseのWorkflowは以下のようになっています。

f:id:hiraike32:20210506183115p:plain:w450

まず、 Android BuildでAABをビルドして、Export Universal APKでAABからユニバーサルAPKを作成し、それをDeployGateに配信しています。

ユニバーサルAPKなので各端末ごとの最適化は行われていませんが、動作確認としては十分に行うことができます。署名情報もBitriseに置いておくだけで済むので、安全性も高まります。

ちなみに、APK→AABの変換はどの環境（buildType, productFlavor）でも同じように実行できるので、_deploy-universal-apkという一連のWorkflowとして、各環境のWorkflowで使い回しています。

まとめると、AABの取り扱いは以下のようになります。このような形でCI/CDを実行して、リリース前にAABの動作確認を行っています。

f:id:hiraike32:20210506183134p:plain

リリース時にAABのビルドとリリースノートの作成を自動化する

上記のWorkflowでAABの動作確認ができたら、AABをリリースノートに配信します。

リリースノートの作成からAAB配信までの一連の流れを自動化したかったので、GitHubで新しいタグが作成されたときに、Bitriseで以下のWorkflowを実行しています。

f:id:hiraike32:20210506183151p:plain:w450

という一連の流れを実行しています。

リリースノートが作成されたら、あとはChange Logを整えて、添付されたAABをPlay Storeにアップロードして完了です。

Bitriseは様々なステップが用意されていて便利ですね。他にもアプリのバージョン更新を自動でやってくれたり、Play Storeに直接配信してくれるステップもあるようなので、導入を検討していきたいです。

N予備校Androidチームでは、新しい環境に対応していくために様々なツールを検討・導入しています。

今後チームとしてやっていきたいこと、N予備校全体としてやっていきたいことはこちらの採用資料に記載していますので、よろしければご覧ください。

また、Androidチームの採用活動も継続中ですので、ぜひ気軽にお声がけください。