Github Actions で実現するCI高速化

ツール導入前の課題

以前利用していたCircleCIのPerformanceプランでは、並列で実行できるジョブ数が80に制限されていました。1回のCI実行で40の並列ジョブを使用していたため、同時にCIを実行できる開発者は2名までに限られていました。このまま開発者が増えると、CIの待ち時間が長くなり、開発効率に悪影響を与えるリスクがありました。

どのような状態を目指していたか

弊社では基本的にGitHub Actionsを使用していますが、RSpecテストと静的解析のみCircleCIを利用していました。これをGitHub Actionsに統合することで、CircleCIとGitHub Actionsの両方を学習する必要がなくなり、開発者の学習コストを削減することが目的でした。また、GitHub Actionsへの移行によって、CIの実行速度を向上させることも狙っていました。

• CircleCI

弊社では、自動テスト以外の多くのワークフローにおいてすでにGitHub Actionsを使用していたため、統一することでメンテナンス性や運用面での効率化が期待できると判断しました。

改善したかった課題はどれくらい解決されたか

GitHub Actionsへの移行により、p95でのテスト実行時間が9分短縮されました。これにより、従来の並列実行の制限が解消され、CI/CDのパフォーマンスが大幅に向上しました。移行前に抱えていたCIの待ち時間やパフォーマンスの問題が、ほぼ解決されました。

どのような成果が得られたか

並列実行の制限がなくなったことで、CI/CDのパフォーマンスが向上し、開発者が素早くフィードバックを得られる環境が整いました。この改善により、開発者の作業効率が上がり、プロジェクト全体のスピードアップが実現しました。また、GitHub Actionsへの統一によって、管理の手間が減少し、運用効率も向上しました。

• テスト分割の仕組みがない GitHub Actionsには、テストの実行時間に基づいて自動でテストを分割する機能が標準で備わっていません。そのため、自社でテスト分割の仕組みを作成する必要がありました。

• UIの課題 テストが失敗した際に、その情報を直感的に把握できるUIが用意されていないため、エラー情報を見やすくする独自の仕組みを構築する必要がありました。

• 結果の引き継ぎの難しさ matrix strategyを使用して並列実行を行う場合、後続のジョブにテスト結果を引き継ぐのが難しく、自前でS3などを利用した結果の保存と引き継ぎの仕組みを構築する必要がありました。

• Flakyテストの管理 Flakyテストを一覧で表示する機能がないため、不安定なテストを把握し、管理することが課題でした。