Androidのリリースを自動化する

概要

GooglePlay Publisher APIを使って, GooglePlayへのAPKのアップロード, スクリーンショットの更新などまでを自動化する.

Publisher APIについて

できること

通常のリリース作業まわりまでのことならだいたいできる.

APKのアップロード. アルファ, ベータ, 段階公開のいずれかを指定してのアップロード
スクリーンショットなどの各種素材の更新
リリースノートなどのメタデータの更新

できないこと

リリースのサブミット
公開する国などの指定
ほかいろいろ.

準備

APIが用意されているが, より簡単に使えるようにbuild.gradleに設定を記述することで使えるようになる下記のライブラリを使う.
https://github.com/Triple-T/gradle-play-publisher
ライブラリでは, alpha, beta, 段階的リリースの割合のいずれかを指定したリリースの設定までを行うことができる.

上記のライブラリのREADMEに設定方法があるのでそれに従う.
src/main/play/… で各言語毎に設定を用意でき, publishApkRelease（APKのアップロード）, publishListingRelease（metaデータの更新）, publishRelease（両方）のタスクが増えるので用途に応じて上記のgradle taskを実行する.
あとは基本的なgithubの運用が, release-*でtagを切った際に上記のtaskを実行するようにjenkins, circleCIなどの設定を行う.

Google Domainsでドメイン購入した

今までBiglobeのDDNSのサービス使って,サブドメインもらってサーバー運用していたのだけれども, Bloggerのサービスでメモ残すようにしようとしたときに Google Domainsでドメイン買うと簡単に連携できるよってことで, ドメイン買ってしまった.
調べてみるとGoogle Domainは以下のことができたので, Biglobeのサービスも解約して, 運用費が40%くらい下がった.

サブドメインの割当
DDNS
GSuiteのカスタムドメイン運用
DNSのいろいろ

Androidでのマルチモジュールのいいところ

前回, 設計についてまとめた.
その設計思想に基づくと, UIを含むモジュールとは別に、ドメイン部分を別モジュールとして切り出すことができる.¹
そうすると何が嬉しいのかを列挙していく.

テストカバレッジを上げやすい

UIと同じモジュールに含めていると, UIのテストコードは複雑で書きづらいので、ドメイン部分のテストコード書いていてもカバレッジが上がりづらく, カバレッジを品質の指標にしづらい.
分けておくとUI部分を含まない形でカバレッジを求めることができるのでよい.

Phone, タブレット, TVなど各種デバイスごとのコードを書きやすくなる

そのまま

ドメインとの区別を強制できる

ドメインのモジュールはPureなKotlin(Java）のモジュールとしやすいのでAndroid側の都合が出てきたら怪しむことができる. なんか思いついたら追記していきます.

1: Androidの開発でのこと.

このまとめとは

PDSを意識した結果をパターン化されたFlux,MVVM,MVPなどを当てはめて開発されているということが勉強会とかでよく見るようになり, 最近ようやくPDS（Presentation Domain Separation）を理解して,アプリを作る際に大枠で反映できてきてると思い始めたのでそれについてどう考えているかのまとめ.^{1, 2}

各種の定義

プレゼンテーション（Presentation)

ユーザー、もしくは別のシステムに対して,自身のドメインに対する入出力を請け負う部分と定義する. Androidで言えば、ユーザーに対するシステムの出力はActivityで画面を作り,各システムの状態をViewを用いてユーザーに対して状態を理解できる形で見せること, ユーザーからの入力は,表示しているButton, EditTextなどからの入力を受けとることとも表現できる.

ドメイン（Domain)

入力を受けた際にその入力に対する適切な計算を行った結果を出力する部分と定義する.

ここでいう適切な計算とは

簡単なところでは, 電卓であるなら四則演算.
レジのシステムなら, バーコードの画像を解析して十数桁の文字列を出力する処理, その十数桁の文字列を入力として商品名,価格などの情報を検索し出力する処理などなど

こうしてプレゼンテーション,ドメインを定義するとそれらを橋渡しするのが必要なのが見えてくる.
橋渡しの仕方で,MVP,MVVM,Fluxなどなどと名前がつけられている.

橋渡しの仕方

MVVM

M: Model（ドメイン）
V: View（プレゼンテーション）
VM: ViewModel（橋渡し）
MVVMではドメインとプレゼンテーションの橋渡しをViewModelと名付けられている部分が行う.
なのでViewModelは,プレゼンテーション側でのユーザー視点でのイベントをドメイン側に通知するためのIFを持ち、その入力に対するドメインの出力を受け取る形を取っている.
重要なのがドメインが持つ状態は,Mに持たせその変化をMVで監視するという形を取る.ViewはMVが持つ状態を参照して構築するようにするがMVが持つのはあくまでドメインの状態のコピーであるところ.
このあたりをうまく実装するのにドメインの状態をRxにあるBehaviorSubjectなどを用いて簡単に監視できるようにしておく.

Flux

FluxはView側にとてもよった形をしており,MV*系とは少し異なると思っている.
Fluxは, Actionにドメインの処理をまとめがちになる³が,ActionはあくまでドメインとのIFに終始するといい感じになる.
ドメインから戻される処理をStoreに反映し,その変更をもってViewが構築される形を取るようにする.

まとめ

MVVMなどはPDSをパターン化したもの. ドメインの設計方法ではない.

宣伝

この記事は下のアプリを作る際に決めた設計方針です. 言わずもがなKotlinで書かれており, またDaggerの代わりにKodein使ってみたり新しめなことを試している感じになっています. 参考になったりしたらstarほしい https://github.com/ttymsd/ConnpassAndroid

余談

Android3.xが発表されたころに出てきたFragmentの思想は,同じ見た目を提供するものであるなら同じドメインに関連するであろうとのもと、プレゼンテーションとドメインをActivityから切り出すためのコンポーネントと思っている. PDSに関心がより始めると、FragmentとCustomViewの違いは些細なことと思い,Fragmentは使わないことを方針にしている.

1: エリックエヴァンスのドメイン駆動設計とかは持っているが未だに最後まで読んでない
2: ちなみに去年はFluxを勉強してたのでそれについてまとめていた.（順序が逆だが）
3: 各種API叩いてまとめるActionとか・・・

ぼんぼるひとのメモ帳