CircleCI その1 パフォーマンスチューニング

CI/CD 大切ですよね

iCARE では CircleCI を利用して日々の開発の助けにしているのですが、それが遅い事で業務効率だけではなくリリース作業にも影響が発生していました

ブレストしましょう

もちろん経験はあるのである程度あたりはつけられますが、こういうことは日々システムを触っているメンバーと話をしてイメージを膨らませるのが一番です

「そもそも FLAKY なテストが多くてそれが足を引っ張っているよね」「ラベルなどを活用して不要なテストの実行を抑制しよう」「そもそも重いテストは CircleCI とは別で実行すればいいのでは？」などたくさんのアイデアがでたのと同時に、現場のメンバーがどういった課題感を感じているのかを把握することができました

コンテナチューニング

最初期に設定してそのままだったようで、ほぼすべてのコンテナが small のままでした

時間がかかっていたいくつかの Job のコンテナサイズを大きくしつつ、一番時間がかかっていた rspec と feature-spec のコンテナ数のチューニングをおこないました

すでに並列実行されていたため、「並列数を倍にする」と「マシンスペックをあげる」の両面で検証。マシンスペックを上げるだけではほぼ改善せず、同時実行数とマシンスペックの両方を上げる必要がありました

またスペック起因によるテストの失敗も散見したため、ベースのスペックをあげつつ同時実行のコンテナ数のスケールアウトを検討しました

実行時間の削減も大事なのですが、同時に費用についても考えなければなりません。スペックが上がってもテスト時間が短縮されれば微増くらいで済むだろうという目論んでいたのですが、実際に理想的なスペックにすると 5〜10倍の費用増加になる事がわかり、日々の開発ではバランスの取れたスペックで妥協し、リリースに使う master ブランチの CI のみ最高のスペックで実行することになりました

FLAKY テストの改善

e2e テストでどうしても避けて通れない FLAKY テストですが、日々の機能追加に終われるスタートアップにありがちなテスト改善に時間が割けない状況が続いていました

ブレストでメンバーが課題感を共有して危機感を持ってくれた事もあり、テスト改善委員会が発足。専用の Slack チャネルで報告された FLAKY テストは日々の業務の一部を使って改善するという運用が始まりいまでも運用されています

そもそもテストをスキップする？

毎回、 e2e テストをするかどうかという観点もあります

実際、リリース用のブランチとそれにマージする最後のコミットだけで十分という事も検討したのですが、 toB の SaaS であり信頼性が重要という点と、検討した当時はエンジニアの数もそこまで多くなかったため、安全側に倒してスキップはしないことにしました

こまごま

とりあえず、謎に FlowType のジョブがあったので削除した他、 bootsnap の導入も検討したのですが、こちらはあまり効果が感じられずお蔵入りに

---

この記事は iCARE の技術顧問がどんな事をやっているか - 2021アドベントカレンダー の5日目の記事です