Androidアプリのリリースフローを考えた2016冬

はじめに

AndroidアプリのGoogle Playへのリリースって、皆さんどうやってますか？

最近お仕事でGoogle Play Publishing APIやBaltoを使った開発フローを構築しつつあるので、普段どのようにアプリをお届けしているか紹介したいと思います。
これからPublishing APIを使ってみたい方や、リリースフローを改善したい方のご参考になれば幸いです。

使っているサービス

今回の記事はフローを中心にご紹介し、各ツールの詳細な説明は省略しました。
以下にリンクを用意しましたので興味のある方はご確認ください。
メジャーなサービスばかりですね

• Google Play Publishing API
• Balto
• Fabric(Beta)
• Travis CI
• GitHub

なんでやったの？

リリースフローを整理した背景には、1バージョンのリリースにかかる時間が多すぎたことがあります。

最近は、おおよそ２週間〜1ヶ月毎にアップデートを配信することが多いですが、GooglePlayへの配信にあたっては、英語/日本語のリリースノートやアプリ内の文言の準備などで開発チーム以外とのコミュニケーションも発生します。
これからローカライズを増やしていくことも考えると、これらのフローをもっと円滑にしたさがありました。
また、個人的に割りと些細なミスをしがちなので出来るだけ手作業を減らしたかったというのもあります。手作業怖い

---

作業フロー作ってみた

というわけで今回の本題ですが、この課題を解決するため、
Google Play API とGitHubを活用して、極力開発チームが普段行っているPullRequestを使った開発フローにこれらの作業を乗せられないか検討しました。
こんな感じになりました。

• 普段の開発 GitHub -> Travis CI -> Balto or Fabric (Beta)

PullRequest毎にFabricで配布、PullRequestがマージされるとBalto/Fabricに同時配信します。Baltoは実装メンバー以外の方からのフィードバック、FabricはPullRequestのレビューなどで利用します。

Baltoへのアップロードはお手製ですがこちらを使用しています。
https://github.com/ymegane/gradle-balto-upload-plugin

• リリース GitHub -> Google Play Publishing API -> Google Play(クローズドβ)

このフローを導入して以降、Google PlayにアップロードするときはPublishing API経由でしか行っていません。
TravisCIを挟んでいない理由は最後に書いています。

---

運用してみた

実際にどんな感じで運用しているかご紹介します。

ローカライズ

翻訳依頼/レビューは基本的にGitHubを使って行います。
PullRequestをこちらで発行しておいて、そのブランチに直接GitHub上でコミットしてもらうことも可能にしています。
たまにXMLのルールに従っていないなんてこともありますが、TravisCIがコケるだけなので全く問題ありません。

先のフローのようにPullRequestを発行/コミットするとFabricで配信されるため、
開発環境がなくても反映結果を確認できます。

フィードバック

UIフィードバックは主にBaltoを使っています。
手前味噌ですが、Baltoはスクリーンショット付きでフィードバックを貰える高速フィードバックツールです。

• Baltoを少しだけ触ってみた http://qiita.com/gupuru/items/4f3850b0a4780964676a

プロダクトマネージャやデザイナーから受け取ったフィードバックはGitHubのissueとして登録されます。(※2016年11月β版時点の仕様です。）

基本的に開発中の最新版がいつでも試せるようにしています。

ストア配信

配信時にはリリースノートやGooglePlayストアに掲載する内容を調整します。
これもGitHub上でPullRequestを作成して行います。

よく言われていることですが、前回のリリースノートとの変更差分が確認できることと、
煩雑なDeveloperConsole上での作業が幾分か自動化できます。
apkの取り違えみたいなヒューマンエラーもほぼ起き得ないので安心です。

PullRequestがマージされたらPublishing APIを使用してアップロードを行います。
現在のところ、こちらのGradle pluginを使用しています。

• GitHub - Triple-T/gradle-play-publisher: Gradle Plugin to upload your APK and metadata to the Google Play Store

• 参考 : http://asmz.hatenablog.jp/entry/use-gradle-play-publisher

以下のような設定を行って、

app/build.gradle

play {
    serviceAccountEmail = "${props.getProperty("service_account")}"
    jsonFile = file("${props.getProperty("keyPath", "")}")
    errorOnSizeLimit = true
    track = 'beta' // or 'production' or 'rollout' or 'alpha'
}

./gradlew clean assembleRelease publishApkRelease

と実行することでGooglePlayのβ版に公開します。
β版にアップされたAPKが問題なければ製品版として公開しています。

実際には、Proguard関連のアーカイブ処理を含めてShellScriptにしています。
また、この操作に限り、現在のところ手動で実施しています。

課題など

• Publishing API経由で公開すると、リリース前レポートが実施されません Firebase Test Labなど別の手段を検討する必要があります。

  • Google Play Developer Consoleの「リリース前レポート」を試す

• 実装メンバー以外にもGitHubを触ってもらえることはありがたいですが、コミットルールなど、開発チームのルールを徹底すると負担が増してしまうのと、やっぱりGitHubは開発者向けのツールなので難しいこともあります。今のところ、SlackやGoogleドキュメントなども併用して進めています。

• PrivateRepositoryとは言え、KeyStoreをコミットすることに抵抗があるため、今のところ商用リリースに限り手動実行になっています。

  • Bitriseなどのサービスが十分に信頼できると判断した場合はもう少し自動化を検討するかもしれません。
  • ちなみに個人では使用していますが最高にハッピーです

むすび

2016と銘打っておきながら、割りと枯れたサービスの集合だったりしたことにお気づきの方もいらっしゃると思いますが、ご了承ください
リリースフローに自動化を取り入れるのは、開発者が開発に集中する時間を増やすためにとっても重要だと思っています。
これからも日々検討していきたいものです。（事実、実は書いているうちに少し変わってしまいました。。