DroidKaigi 2017 の発表資料です

1. minneにおける
テスト〜リリース〜
リリース後
にやっている事の紹介
SmartDrive
Masataka Kono
2017-3-9
DroidKaigi 2017

2. 自己紹介
● PHP/Android
● minne（〜2016年12月）
● 株式会社スマートドライブ
● Twitter @mapyo
● GitHub @mapyo

3. minneとは？

4. minneとは

5. minneでのAndroid開発
● 2013年11月リリース
● Androidチーム 3人
● 3人で１つのアプリを開発
● 2週間に１回定期的にリリー
ス

6. 今日伝えたい事
● 複数人数のアプリ開発事例
● フローを整えましょう
● いろいろと議論したい

7. 目次
● 開発開始からリリースまで
● テスト・CI
● リリース前の検証
● リリース
● リリース後のフォロー

8. 開発開始からリ
リースまで

9. 開発からリリースまで
1. スプリント計画
2. 開発（Unit test, UI test）
3. 検証シート作成
4. 検証
5. 段階的リリース
6. リリース後のフォロー

10. 開発からリリースまで
1. スプリント計画
2. 開発（Unit test, UI test）
3. 検証シート作成
4. 検証
5. 段階的リリース
6. リリース後のフォロー

11. 開発からリリースまで
1. スプリント計画
2. 開発（Unit test, UI test）
3. 検証シート作成
4. 検証
5. 段階的リリース
6. リリース後のフォロー
２週間

12. テスト・CI
1. テストの種類と説明
2. CIで使用するツールと
サービス
3. CIの流れ

13. minneでのテスト
● Unit test
● UI test
● 検証時の手動テスト

14. minneでのテスト
● Unit test
● UI test
● 検証時の手動テスト
その前にAndroidのテストタ
イプの説明をします

15. Androidのテストタイプ
● Local unit test
(test)
● Instrumented test
(androidTest)
https://developer.android.com/studio/test/index.html

16. Local unit test
● JVM上で動くテスト
● Instrumented testに比べて
早い
● Androidフレームワークに依
存するテストはモックが必要

17. Instrumented test
● 実機・エミュレータ上で動くテ
スト
● Local unit testに比べて遅い
● Androidフレームワークに依
存しててもOK

18. minneでのテスト
● Unit test
● UI test

19. Unit test
● Local unit testで実行
● Robolectricでモック
● UIのテストはしない
※モックが難しい場合は
Instrumented test

20. Unit testでやってた事
● 単純なモデルのテスト
● MVPのPのテスト
● APIをモックしたテスト
● ディープリンクのテスト
● SharedPreferencesまわり

21. ● Instrumented testで実行
● Espressoで記述
UI test

22. ● 実行タイミングによって謎の
落ち方
● 実行時間が長い
● Espressoの書き方
MVPで書いてPのテストをUnit
testでやっていく！！
UI test 辛い。。

23. テスト・CI
1. テストの種類と説明
2. CIで使用するツールと
サービス
3. CIの流れ

24. ● Drone
● AWS Device Farm
CIで使用するツール・サービス

25. ● Travis CI, CircleCI, Wercker
と並ぶCIツール
● Docker
CIまわりの機能とUnit test
Drone

26. open source edition
Drone

27. 詳しくはこちら。
https://speakerdeck.com/gs3/pepabowozhi-eruda-tong-ciji-pan-toren

28. AWS Device Farm
● クラウド上で実機を使ったテ
スト
● apkをアップし手動テスト
UI testを実行

29. テスト・CI
1. テストの種類と説明
2. CIで使用するツールと
サービス
3. CIの流れ

30. CIの流れ 〜Unit test〜
PUSH

31. CIの流れ 〜Unit test〜
PUSH
Unit test！

32. CIの流れ 〜Unit test〜
PUSH
Unit test！

33. CIの流れ 〜UI test〜
PUSH
Unit testを実行後に動
く

34. CIの流れ 〜UI test〜
PUSH
Device
Farm
web hookの仕組みが
ない...

35. CIの流れ 〜UI test〜
PUSH
Device
Farm
監視
サーバ
polling

36. テスト実行タイミング
● Unit test
→PUSH毎に実行
● Ui test
→develop, master, release
ブランチ

37. リリース前の
検証

38. 1. リリース担当を事前に決める
2. リリース用issue立てる
3. 検証シート作成
4. 検証
5. 検証で出たバグを修正する
流れ

39. 1. リリース担当を事前に決める
2. リリース用issue立てる
3. 検証シート作成
4. 検証
5. 検証で出たバグを修正する
流れ

40. ● 検証シートへのリンク
● 検証開始〜リリースまで流れ
● 今回のリリースのメモ
随時修正・追記して
次回のリリース時にも使う
リリース用issue

43. 1. リリース担当を事前に決める
2. リリース用issue立てる
3. 検証シート作成
4. 検証
5. 検証で出たバグを修正する
流れ

44. ● どの画面？
● ログイン／ログアウト？
● どういう操作？
● 結果どうなればいい？
他の人が検証するために必要な
情報を書く
検証シートとは？

46. 1. リリース担当を事前に決める
2. リリース用issue立てる
3. 検証シート作成
4. 検証
5. 検証で出たバグを修正する
流れ

47. 検証 〜検証する人〜
● Androidエンジニア１〜２人
● ディレクター １人
● 合計３人くらい
iOSエンジニアも検証しよう！
という流れも。

48. 検証する！
● 検証シートに沿って粛々とやる
● バグを見つけたら再現手順や
スクショなどを貼る
● 機能開発した人に伝えた直して
もらう
● 再度検証

49. リリース

50. 段階的な公開
● 20%リリース
● ２営業日後50%リリース
● ２営業日後100%リリース
休日の前日はなるべくリリースし
ない

51. リリース後の
フォロー

52. リリース後のフォロー
● クラッシュの監視
● アプリレビューの監視と対応
● ふりかえり

53. クラッシュの監視
● Crashlytics
● Slackと連携
● 毎朝Slackでリマインダ

54. アプリレビューの監視
● Slackに１日１回流す
● google-play-review-watcher

55. アプリレビューの監視と対応
https://github.com/Konboi/go-google-play-review-watcher

56. レビューの様子

57. レビューの対応について
● 当初はエンジニアが選定して
CSさんに依頼
● 現在はCSさんが直接返信

58. ふりかえり
● ふりかえりissueを立てる
● Androidチームの３人
● リリース後(20%)に実施
● １時間程度
● Keep・Good/Problem/Try

61. まとめ

62. まとめ
● テスト・検証・リリース・リリース
後について話した
● チームによってそれぞれ違う
● ふりかえり重要
● 少しでも皆さんの参考になれば
幸いです

63. ありがとうござ
いました！！

64. ふろく

65. CIの流れ 〜UI test〜
PUSH
Device
Farm
監視
サーバ
polling

66. AWS Device Farm Gradle Plugin
https://github.com/awslabs/aws-device-far
m-gradle-plugin