26
25

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

AndroidアプリにおけるCIベストプラクティス(案)

Posted at

なんとなく考えているものです。
もう少し考えがハッキリしてきたら別でエントリをまとめます。

基本的に継続的インテグレーション入門に書かれている内容や考え方を参考にしています。

CIの流れ

本にも書かれている通り、Androidアプリの場合でも3種類のビルドがあれば良いかな―と思ってます。

  1. コミットビルド - コミットの度に実行し、数分以内に終わるビルド
  2. 2次ビルド - 定期的(1日1回など)に実行し、時間が長くかかっても良いビルド
  3. リリースビルド - リリース直前に実行するビルド

それぞれのビルドで実行する内容(の案)について書いていきます。

コミットビルド

  1. コンパイルが通るか → ./gradlew assembleなど
  2. コード解析
    • Checkstyle
    • PMD
    • FindBugs
    • Android Lint
  3. テスト+カバレッジ計測(短い時間で実行したいのでJavaVMでテストする)
    • Robolectric
    • JUnit
    • Jacoco(もしくはCoberturaかEmma??)
  4. ドキュメンテーション
    • JavaDoc
    • クラス図の生成(やり方はわからない...)
  5. フィードバック
    • Slack、HipChat、メールなどでビルド結果を適切に通知(特にビルドに失敗した場合)
    • DeployGateなどでビルドしたapkを配布

1日1度など定期的に行うビルド(2次ビルド)

コミットビルドに追加して以下の内容を行います。

  1. 単体テスト、結合テスト、UIテスト(本番環境に近い形にしたいので端末もしくはエミュレータ上でテストする)
    • monkey
    • モデル単体テスト、Activity単体テスト、Service単体テスト...
    • Espresso
    • UI Automator

リリースに向けたビルド(リリースビルド)

まず2次ビルドを動作させ、問題なく動作したら以下を行います。
(もちろん、CIとは別にapkの手動確認はすべきだと思います。)

  1. apkをDeveloper Consoleにアップロードし、リリース直前の状態にする
    • Google Play Developer API : Publishing API

以上です。

それぞれのビルドでデバッグ/リリースのどちらの署名を使うかですが、ビルド対象にしているブランチによって変えるのが良さそうな気がしています。(リリースに使うブランチならリリース署名、開発に使っているfeature系のブランチならデバッグ署名)

実際に色々試していってみようと思います。
ノウハウがある!など何かコメントあれば是非いただきたいです。

26
25
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
26
25

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?