Gradleの --parallel
やJUnit並列実行、Configuration Cacheなどがどの程度ビルド性能を改善するのか、いくつかのOSSで実測してみた。利用した機能の概要は以下オフィシャルサイトを参照のこと。
SonarQubeの事例
バージョン 9.0.1.46107
リリース後の master
ブランチで実践。進捗などは以下のIssueで管理している:
もともとGradle 6.8.2を使っていたが、1,092ものbuild deprecationsが報告されておりGradle 7に直接アップグレードすることができない状態。Gradle 7ではいくつかのTaskのaccessorがLazy ConfigurationのためのAPIで置き換えられており、移行が必要。また依存管理に非推奨となっているcompile
やdefault
を使っており、implementation
やruntimeClasspath
やJava Library Pluginが提供するapi
などへの移行が必要。
最大の難関は com.github.hierynomus.license
プラグインと com.github.johnrengelman.shadow
プラグインが古く、数多くの警告が出ているというもの。タスクの入出力が不明瞭なためキャッシュも効いていない。またプラグインの最新版がGradle 6をサポートしていないため、これらのアップグレードはGradleの7へのアップグレードと同時に実行する必要があった。
改善結果
21分半かかっていたフルビルドが16分弱(73.3%)で終わるようになった。
Parallel buildはビルド時間を1分程度短縮する効果があったが、GitHub ActionsのHosted Runnerは2コアしかないためデフォルトでは2並列にしかならない。サブプロジェクトが多いなら --max-workers
などの設定でワーカー数を増やす方が良い。
テストの並列実行は残念ながらビルド性能の改善に繋がらなかった。Parallel buildでCPUを使い切っており性能が出なかったためと思われる。実際サブプロジェクトひとつのテストを実施してみると、テストの並列実行を有効化したほうが性能が出る。サーバが必要なBuild Cacheは試していないが、これを有効化することでフルビルドの必要性が下がるため、テスト並列実行の重要性も上がると期待される。
SpotBugs
実験中。Antから無理やり移したタスクがEclipse plugin周辺で残っているので、まず buildSrc
にビルドロジックを移動させるところからやる必要がある。
Eclipse関連の依存をMaven Centralからダウンロードするようにしたいが、以下の課題が未解決。