AmebaアプリでのCI改善

CA.apk #4 https://cyberagent.connpass.com/event/65347/

Transcript

1. AmebaアプリでのCI改善 IMANAKA, Kouta 2017/10/02 CA.apk #4
2. 俺氏、所属プロジェクトのCIの 「地位」が低いことに気がつく • 結果が尊重されていない ◦ しばしばタイムアウトする、謎の CI Error • 結果を無視しがちである ◦ 「ステータス帰ってきてないけど実は通ってます」がかなり多い CIが何かしらの手間であると捉えられているなら、 そのプロジェクトにおけるCIの「地位」は低いと考えられる → 「CI改善」をテーマに設定し、改善することにした。
3. README.mdをいじってCIがコケる図
4. 今日お話しすること • 分析（なぜCIの地位が低いのか） • どのような問題を抱えているか • どのように解決したか • 更なるCI改善へ ※ 本発表では「Android版AmebaアプリにおけるCI環境改善」を説明します。 CircleCI Enterpriseを採用しているため、通常と異なることがあるかも知れません。 また、プロジェクト毎にシステムの採用基準が違うので、他部署では Bitrise使ってます、とい う話も聞いています。
5. 改善、まずは分析から
6. (1)android update sdk --no-ui --all --filter tools (5:48) (2)sdkmanager “platform-tools” “extras;android;m2repository” “extras;google;m2repository” (4:24) (3)./gradlew dependencies (1.59) (4)./gradlew testProductReleaseUnitTest (3:52) (5)./gradlew testStagingDebugUnitTest (2:25) 1 2 3 4 5
7. (1)android update sdk --no-ui --all --filter tools (5:48) (2)sdkmanager “platform-tools” “extras;android;m2repository” “extras;google;m2repository” (4:24) (3)./gradlew dependencies (1.59) (4)./gradlew testProductReleaseUnitTest (3:52) (5)./gradlew testStagingDebugUnitTest (2:25) 1 2 3 4 5
8. テストより準備のほうに 時間かかっとるやないか
9. CI改善点 • 全体的に時間かけすぎ、特に準備に時間がかかりすぎている ◦ それゆえにCIが完遂しないことも ◦ → SDKを別ディレクトリに構築してキャッシュに入れる • 並列数1で効率が悪い ◦ → 並列数++ • 古いテストケース（InstrumentTest）があるのに エミュレータ環境でのテストが無効化されている ◦ → UnitTest化, Firebase Test Labの導入
10. 1. なぜ準備に時間がかかりすぎるのか？ • CircleCI標準のSDKは古すぎるのでアップデートが必要 ◦ SDKのアップデートをする ◦ Platform Toolsのアップデートもする ◦ Build Toolsも取得する • CIインスタンスでの作業が完遂したときに全てを破棄する ◦ CircleCIデフォルトのSDKのあるディレクトリは キャッシュ指定していない • 次のビルドでまたすべて取得。。。 SDKを別に用意した上でキャッシュ指定すれば速くなるのでは？
11. SDKディレクトリを別に用意する仕組み • zipファイルをダウンロードして展開する ◦ ANDROID_HOME = ~/android-sdk-linux ◦ ↑はキャッシュするように設定 • キャッシュを効かせる為、毎回ダウンロードしてほしくない ◦ ただの存在チェックだと SDK更新されたときに上書きされない ◦ zipファイルのURLを保持したファイルを書き出し、 URLに変化があれば再取得する そういう処理をするシェルスクリプトを書きました。
12. 2. 並列数を増やすには • CircleCIのProject SettingsからAdjust Parallelismを設定 • なんでも並列に出来るわけじゃない ◦ testセクションのみ ◦ deploymentセクションで出来たらアツかったんですがね。。。 ◦ 実行順に依存しないコマンドだけを並列にできる （とはいえテスト系はだいたいそんなもんだという認識） • 一部テストは自動で並列処理をしてくれることもあるが Androidのテストは手動で割り当てをする必要がある
13. circle.yml (抜粋) test: override: - ./scripts/run-test.sh: timeout: 3600 parallel: true
14. run-test.sh (抜粋) #!/usr/bin/env bash # テスト結果をストアして最終的に返す（テスト終了後もいろいろ作業するため） RESULT=0 case $CIRCLE_NODE_INDEX in 0) mkdir -p $CIRCLE_TEST_REPORTS /junit/productDebug/ ./gradlew clean testProductDebugUnitTest RESULT= $? find . -type f -regex ".*/build/test-results/.*xml" -exec \ cp {} $CIRCLE_TEST_REPORTS /junit/productDebug/ \; ;; 1) mkdir -p $CIRCLE_TEST_REPORTS /junit/stagingDebug/ ./gradlew clean testStagingDebugUnitTest RESULT= $? find . -type f -regex ".*/build/test-results/.*xml" -exec \ cp {} $CIRCLE_TEST_REPORTS /junit/stagingDebug/ \; ;; esac exit ${RESULT}
15. • 弊社CiecleCI Enterprise環境のemulatorは残念ながら壊れている ◦ 我々のプロジェクトだけが壊れているということも考えられる • 極力UnitTest(with Robolectric)を使うように書き直し ◦ （ついでにテストのKotlin化もしてKotlin力を身につけた） ◦ とはいえ何が何でも UnitTestはしんどいのでそこまで執着しない （もともとコメントアウトされていたのだから） InstrumentTest -> UnitTestにしたことで テストケースが増えたのだとポジティブに考える 3. UnitTest化で爆速テスト回し
16. Firebase Test LabにEmulatorの代わりをさせる [検証中] • どうしてもInstrumentTestを使う必要が出てくる • Firebase Test Labを使うことでネットワーク越しに実機テストが出来 る ◦ 無料枠だとEmulator10台 (or 回) / 日, 実機 5台 (or 回) / 日 • テスト実行中の画面をキャプチャしてくれたりと便利 ※検証中の為、まだ本流にマージしていないがよく機能している
17. circle.yml (抜粋) dependencies: post: - sudo /opt/google-cloud-sdk/bin/gcloud config set project ${GCLOUD_PROJECT_ID} - sudo /opt/google-cloud-sdk/bin/gcloud --quiet components update - sudo /opt/google-cloud-sdk/bin/gcloud auth activate-service-account \ --key-file ./scripts/gcloud_credentials.json
18. run-test.sh (抜粋) 1) mkdir -p $CIRCLE_TEST_REPORTS /junit/connected/ ./gradlew clean assembleProductDebug assembleProductDebugAndroidTest -PdisablePreDex echo "y" | sudo /opt/google-cloud-sdk/bin/gcloud \ firebase test android run ./scripts/commands.yaml:instrumentation RESULT= $? sudo /opt/google-cloud-sdk/bin/gsutil -m cp -r -U \ `sudo /opt/google-cloud-sdk/bin/gsutil ls gs:// ${GCLOUD_STORAGE_BUCKET_NAME} | tail -1`\ $CIRCLE_TEST_REPORTS /junit/connected/ ;;
19. commands.yml (see also: link) instrumentation: app: ./ameba-app/build/outputs/apk/ameba-app-product-debug.apk test: ./ameba-app/build/outputs/apk/ameba-app-product-debug-androidTest.apk device: # Pixel; O Preview; Japanese - { model: sailfish, version: 26, locale: ja }
20. 結果
21. Before: 21:56 → After: 12:12
22. まとめ • 全体的に時間かけすぎ、特に準備に時間がかかりすぎている ◦ Before: 20分付近 → After 10-15分台 ◦ CIの本質に時間をかけられるようになった • 並列数1で効率が悪い ◦ 並列実行できるようにして効率よくなった • 古いテストケース（InstrumentTest）があるのに エミュレータ環境でのテストが無効化されている ◦ UnitTestへの移行 ◦ InstrumentTestはFirebase Test Labを導入 もうちょっとだけ続きます
23. 更なるCI改善へ • [done] Lintチェック ◦ 新しすぎるAPIの使用を指摘 ◦ errorの時にCI Errorにする ◦ warningは多すぎて今は無視 • danger/danger を用いた レビュー前のチェック • 夢の自動リリースも • CircleCI 2.0で10分切りを 狙いたい 引き続き改善を進めていきたい
24. CIをよりよくする案を募るIssue
25. 最後に雑感 • 個人的にこれまでCIに関心が無かった ◦ Android開発者俺だけ、とか普通だった ◦ CI環境構築のメリットが、構築コストを上回る環境でなかった • 今のチームは大所帯。開発基盤の整備で得られるものが多い ◦ ひとつ日常業務を削減できればチームメンバー全員が効率よくなる ◦ 若干開発現場に活気が出てきた気が（※個人の感想によるものです） ◦ → 道半ばだがCI環境の地位はよくなっている • 置かれる環境によって人のロールは変わるのだなと感じた
26. ここまでのお相手は... 今中 幸太 Android Application Engineer at CyberAgent, Inc. DroidKaigi Staff (アツいプロポーザルお待ちしております ) • GitHub: keima