Spring Tools 4のSpring Bootアップグレードサポート機能を試してみる

こんにちは、情報システム部の小坂です。

Spring Bootは半年に1回のサイクルでリリースされており、定期的にアップグレード(バージョンアップ)を行う必要があります。
ただ、プロパティ名の変更やメソッドの非推奨化など、アプリケーションのコード修正が必要になる破壊的な変更が入ることも珍しくありません。

アップグレード時にはSpring公式のマイグレーションガイドなどを参考にして修正を行うと思いますが、一つ一つの修正を手作業で実施していくのは骨が折れる対応ですよね。

そんな毎回のアップグレード対応に役立つサポート機能(upgrade support)がSpring Tools4で追加されており、なんとアップグレードに必要なコード修正を自動的に行ってくれます。
アップグレード対応の効率化に役立ちそうでしたので、ご紹介します。

Spring Tools 4のアップグレードサポート機能の使い方

アップグレードサポート機能が使えるのは下記のIDE環境になります。

  • Spring Tools 4.17.0 以降
  • VSCode 1.41.0 以降(拡張機能が必要)

この記事では、STSの4.17.2を使って確認をしました。

アップグレードサポート機能を使うには、プロジェクトのコンテキストメニューから Spring > Upgrade Spring Boot Version を選択します。

その後、どのバージョンにアップグレードするのかを選択します。

ここでは、Spring Boot 3.0へのアップグレードを選択しました。
自動的に修正する内容を詳細に選択することもできます。 これでアップグレードに対応するコードの修正ができます。

といっても分かりにくいので、アップグレードにより破壊的な変更が必要になるコードを実際に仕込んで検証してみました。

アップグレードをしてみた

早速アップグレードを試してみます。 今回、破壊的な変更が自動的に反映されるかをテストするために、破壊的な変更が必要な要素をいくつか仕込んだ下記のプロジェクトをアップグレードしてみます。 プロジェクトはMavenで作成しました。

  • Spring Boot V2.6→V3.0にアップグレード

  • 仕込んだコード

項目 V2.6時コード V3.0変更後
SecurityConfig WebSecurityConfigurerAdapter SecurityFilterChainをBean定義する
※SpringSecurityのConfigで長らくWebSecurityConfigurerAdapterが使われていたが、V2.7で非推奨化、V3.0で削除された。
Jakarta EEのパッケージ名 javax javax.~のパッケージ名をjakarta.~に変更
Javaバージョン Java 11 Javaバージョンを17に変更
※V3.0からベースラインが17となっている。
プロパティ名 server.max-http-header-size プロパティ名を
server.max-http-request-header-sizeへ変更

では、先ほどと同様の下記画面からOKを押下して結果を見てみます。
今回は2.6→3.0なので、2.7へのアップグレードも同時に行います。

しばらくは処理中の画面が表示されます。

処理中の画面が閉じられるとアップグレードが完了します。

修正結果を見てみましょう。

  • SecurityConfig

    SecurityFilterChainをBean定義する方法に修正されました。

  • Java EEのパッケージ名

    パッケージ名がjakarta.~に変わりました。

  • Javaバージョン

    pom.xmlを見ると、Java17にバージョンが変わっていました。また、一番重要なポイントですが、Spring Bootのバージョンも上がっていますね。

  • プロパティ名

    プロパティ名も想定通りに修正されています。

ということで、仕込んだコードについては自動的に適切なコードへ修正されたようです。

ただし、全てのコードが修正されるわけではなく、一部手作業での修正を促されるケースもあります。
SecurityConfigについていくつかのコードで試していたところ、アップグレード時に下記のようなコメント文が表示され、コード修正されないケースがありました。

こういったコメント文が表示されるケースについては自動的には修正されないので、手作業で修正が必要なようです。

とはいえ、アップグレードに必要な修正が自動で一気にでき、大幅な効率化ができそうですね。
※今回の記事では深く取り上げませんが、アップグレード後のテストももちろん必要です。

アップグレードサポートの仕組み

アップグレードサポート機能は裏側ではOpenRewriteというプロジェクトが使われています。
OpenRewriteは簡単にいうと、リファクタリングやコード修正などのレシピ(修正ルール)が登録されており、そのレシピを元に各種コードを自動で修正するプロジェクトです。
OpenRewiteにSpringBootのアップグレードに関するレシピ群も登録されており、Spring Tools 4のアップグレードサポート機能ではOpenRewiteで自動コード修正ができるようになっています。

例えば、先ほど修正した例ではプロパティ名のserver.max-http-header-sizeをserver.max-http-request-header-sizeに修正しました。
この修正に関するレシピがOpenRewriteで定義されており、このレシピに従って修正がされたわけですね。

Gradleプロジェクトのアップグレードは・・・

Mavenのプロジェクトのアップグレードができたところで、Gradleプロジェクトのアップグレードもやってみます。
同じように、Spring Boot 2.6.8のプロジェクトを準備してアップグレードをしてみます。。。。と思ったら

おかしいです。コンテキストメニューにアップグレードの項目が出てきません。 STSを再起動してもプロジェクトを作りなおしても出てきません。 Mavenのプロジェクトではアップグレードができるのですが。。。

もしや、と思い調べてみると、、、Spring公式のブログ に下記記載がありました。

Limitations
Gradle build files are not yet supported when applying the upgrade recipes for projects. While the version validation works for Gradle-based projects as well as many parts of the automated upgrade recipes, modifying the build.gradle file itself is not yet supported, but on the roadmap for future releases.

(訳)Gradle ビルドファイルのプロジェクトへのアップグレードレシピの適用はまだサポートされていません。「version validation」は Gradle ベースのプロジェクトや自動アップグレードレシピの多くで機能しますが、build.gradle ファイル自体の変更はまだサポートされていません。将来のリリースのロードマップ上にあります。

Gradleは非対応だったようです。。 私のプロジェクトではGradleを利用しているので、次のアップグレードで活用できそうだと期待していたのですが、残念です。 ちなみに、Gradleプロジェクトへの対応もロードマップ上にはあるそうなので、今後の対応を待ちたいところです。

まとめ

Gradleプロジェクトで利用できない点は残念でしたが、Mavenプロジェクトでは

  • アップグレードに必要な修正が自動的に反映される

点が確認できました。 アップグレード時の補助ツールとして役立ちそうですね。

一緒に働く仲間を募集しています!

弥生では一緒に働く仲間を募集しています!
弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers