AmebaアプリでのCI改善

 AmebaアプリでのCI改善

12dcaf53d9c2b7b3cd8c62a16f364ed3?s=128

Kouta Imanaka

October 02, 2017
Tweet

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