CircleCIの実行時間を３分の２くらいにした / CircleCI meetup LT 2019-08-23

Transcript

1. CircleCIの実行時間を ３分の２くらいにした mstssk

2. 自己紹介 • りんご @mstssk
 • 株式会社Viibar所属
 • フロントエンドエンジニア
 • CIとか細かい環境改善とか大好き


   今日は半分くらいはCircleCIと直接は関係ない話です　　


3. CircleCIの実行時間が遅かった！！ • システム構成：Rails+Webpack(TypeScript+Vue)
 ◦ Sprocketsの画面もかなりある
 • コミット毎のWorkflowの実行時間が15〜20分強
 
 • 積極的にはメンテされておらず、流石に遅かった


   • およそ半年の間に、機能追加などもしつつ色々メンテしていき
 現在は 10分程度 まで高速化！


4. Performanceプランにしよう（ダイレクトマーケティング • 旧プラン: $350/month
 ◦ 1 Free + 7 Paid

   Containers
 ◦ 4並列ジョブ×2を動かせるように
 • Performance プラン: $180/month
 ◦ $120(8 Users) + $60 Credit
 ◦ (実質)無限コンテナ。コストを気にせず並列化できる


5. Amazon ECRのリージョンを気をつけよう • CIで使うDockerイメージを自前でビルドしてECRに置いてる
 • Spin up Environment だけで1分半くらいかかってた
 ◦

   というかECRの転送コストが妙にかかってる
 ◦ 東京リージョン(ap-northeast-1)に置いていたので
 CircleCIが海を越えてイメージを取りに来ていた
 • リージョンを us-east-1 にしたら30秒に高速化＆省コスト化


6. TypeScriptのビルド高速化 • ECR早くなったが、別途やってた機能追加で画面数が増えて
 Webpackビルドだけで5分くらいかかるようになってた
 • speed-measure-webpack-plugin でボトルネックを計測
 ◦ ほとんどが ts-loader

   + vue-loader の実行時間
 • fork-ts-checker-webpack-plugin でTSビルドを並列化
 ◦ node_modulesディレクトリのexcludeも忘れてた
 ◦ 5分強が → 30秒に 


7. Railsのassetsをキャッシュしよう • コントローラのテスト毎にassetsビルドが走って遅い＆高負荷
 • ビルド済みassetsフォルダをキャッシュしよう
 • public/assets と tmp/cache/assets をキャッシュ


   - save_cache: key: public-assets-{{ .Environment.CACHE_KEY }}-{{ .Branch }}-{{ .BuildNum }} paths: - public/assets - tmp/cache/assets - ~/.webdrivers # ついでにChromeDriverもキャッシュ

8. テストの並列実行の速度に一喜一憂しない • circleci tests split でRSpecを4分割し並列実行している
 ◦ タイミングデータに基づいた分割をしている
 ◦ テストを変えるとタイミングデータも変わってしまうので


   実行時間も2〜3分くらい変わったりする⏰
 ◦ 頑張ってチューニングべきところではなさそう
 • 他の恒常的に改善できる場所に目を向けよう


9. その他に気を使ったところ • Chromeは最新に。v71あたりはテストが不安定だった
 • サーバとフロントのビルド・テストは別ジョブにして並列化
 • キャッシュをたまにクリアする/キャッシュ対象自体の整理
 ◦ 地味に少しずつキャッシュにゴミが溜まっていったりする
 ◦

   数百MBくらいになってくるとレストアが遅い
 • 依存関係を時々整理しよう
 ◦ 機能を落とした時に不要になったものを消し忘れてたり


10. CIはメンテナンスするもの • 最近は実行時間の最頻値が10分20秒くらいに落ち着いている
 
 
 
 • しかし、プロダクトの成長と共にコードベースも変わっていくので
 CIの実行時間は劣化していく
 •

    コードをメンテするように、 CIもメンテナンスしましょう