Tweet
Tweet

Slide 1

Slide 1 text

Spring Boot 2.7 から 3.1 への アップグレードに苦労したことと学んだこと JJUG CCC 2024 Spring 2024.06.16 BABY JOB 株式会社 米岡 毅 @kometsubu_bj

Slide 2

Slide 2 text

自己紹介 所属 BABY JOB 株式会社 開発部 手ぶら登園開発課 🍙チーム (2023年9月入社) 最近 2歳の娘の食育も兼ね色々な野菜を 家庭菜園しています 私から皆様へ イベント登壇初めてなので 暖かく見守ってください 米岡　毅 よねおか たけし こめつぶ🍙 | 2歳児のパパエンジニア@BABY JOB @kometsubu_bj

Slide 3

Slide 3 text

Ajenda 1. 前提
 2. 苦労したこと
 3. 学んだことを生かして
 4. まとめ

Slide 4

Slide 4 text

前提 まずは 今日取り上げる内容と 私が苦労するきっかけとなった プロダクトの状態について ご説明します。

Slide 5

Slide 5 text

今日取り上げる内容 ● アップグレードでの理想とギャップ ● アップグレードでのつまづきポイント ● 上記のつまづきポイントに対して工夫したこと ● アップグレードの影響を小さくする為の段階的なリリースの概要

Slide 6

Slide 6 text

今日取り上げないこと ● コードレベルでの詳細な説明

Slide 7

Slide 7 text

プロダクト プロダクトは以下の環境で動作しています。 ● Java 21(Amazon Corretto) ● Spring Boot 2.7

Slide 8

Slide 8 text

プロジェクトと私の状況 背景としては以下のような状態でした。 ● アップグレードを見据えて動き始めたのは 2023/10 ● 私は入社２カ月目 ● プロダクトについて右が分かり始めた程度 ● Spring Boot のアップグレードはやったことない ● Spring Boot 3.1用のブランチを作成し、そこに全てを詰め込む方針 で進めた

Slide 9

Slide 9 text

苦労したこと ここからが本題です。 まずは、私が苦労したことを 紹介します。

Slide 10

Slide 10 text

予め情報収集したものと違う Case 1

Slide 11

Slide 11 text

予め情報収集したものと違う 1 実際に適用する前に、リリースノートからどの辺りが変更になったのか を大まかに調べました。 キーワードやライブラリ、Spring Boot が依存するパッケージを検索し、 「そんなに影響範囲がない」と判断。

Slide 12

Slide 12 text

予め情報収集したものと違う 2 なにが起きた？ ローカルでバージョンを上げると想定していないエラーが続出。 コード上のエラーを解消しても動作させて初めて出てくるエラーや画面 が表示できないなどのエラーが発生。 それらの対応を地道に潰すこととなり、想定以上にリリースまでの時 間がかかった

Slide 13

Slide 13 text

予め情報収集したものと違う 3 なぜか？

Slide 14

Slide 14 text

予め情報収集したものと違う 3 なぜか？ そう、ここです。

Slide 15

Slide 15 text

予め情報収集したものと違う 3 なぜか？ そう、ここです。 入社２カ月目だったのでそんなにプロダクトのに詳しくなく 情報収集した内容だけで大まかなスケジュールを立ててしまったので す。 その結果、大幅なスケジュール変更が必要になりました。

Slide 16

Slide 16 text

パスの厳密化による確認・メンテに追われる Case 2

Slide 17

Slide 17 text

パスの厳密化による確認・メンテに追われる 1 どんな変更？ Spring Framework 6.0 からリクエストURIの厳密化が行われ、 トレイリングスラッシュ（URLの末尾のスラッシュ）の有無が 識別されるようになった。 そのため、/hoge/ と /hoge は別のURIとして扱われるようになった。 つまり、アプリ上でこれらの定義が混在しないように整理しないといけな い

Slide 18

Slide 18 text

パスの厳密化による確認・メンテに追われる 2 どう対応しようとした？ トレイリングスラッシュ無に統一。 トレイリングスラッシュ有でリクエストされた場合は、トレイリングスラッ シュ無のエンドポイントに処理を流すFilterクラスを作成。

Slide 19

Slide 19 text

パスの厳密化による確認・メンテに追われる 3 なにが起きた？ エンドポイントが 400 以上。 それらの定義が統一され、正しく呼び出されるのか。 アップグレード後に定義間違いでエンドポイントに到達できなくならない かの確認が必要でした。 画面から全てのエンドポイントを叩き、確認を行いました。

Slide 20

Slide 20 text

認証パスの追加、慣れるまで忘れがち Case 3

Slide 21

Slide 21 text

認証パスの追加、慣れるまで忘れがち 1 どんな変更？ Spring Security 6.0 から SecurityConfig で許可や認証の要否の定義 が、ブラックリスト型からホワイトリスト型に変更。 そのため、今まで定義していなかったパスを漏れなく定義する必要が あった。

Slide 22

Slide 22 text

認証パスの追加、慣れるまで忘れがち 2 どう対応しようとした？ ローカルをSpring Boot 3.1にアップグレードし、認証不要なパスを洗い 出し、一つずつ定義を追加。 画面上から動作を確認。 エンドポイントの追加や変更があれば、都度取り込み、再度確認するを 繰り返す。

Slide 23

Slide 23 text

認証パスの追加、慣れるまで忘れがち 3 なにが起きた？ 都度、本線の差分を取り込みメンテし続けなければならなかった。 自身でも慣れるまでは「認証パスに追加されてる？」とならず、はまるこ ともあった。 これが、地味だが面倒だった。

Slide 24

Slide 24 text

学んだことを生かして 続いて、苦労したことから 学んだことを生かして 今後どうすればいいか 考えたことを紹介します。

Slide 25

Slide 25 text

学んだことを生かして 1 調べるのも大切だけど、アップグレードしてみる。 リリースノートが全てではない。 Spring Boot 以外の部分も影響する可能性は大いにある！

Slide 26

Slide 26 text

学んだことを生かして 2 パスの厳密化 → Configurer.setUseTrailingSlashMatch(false); 認証パスのホワイトリスト化 → denyAll() 何かしら次のバージョンを模す設定があり、それらを設定することで、 アップグレード前であっても同様の状態を再現することができる。

Slide 27

Slide 27 text

学んだことを生かして 3 1. アップグレード後を模す設定を入れる 2. 対応する 3. １～２を繰り返す 4. アップグレードする 5. １の設定を削除する このようにして一見、全てを同時に対応しないといけないように考えられ るアップグレードを分割することができる

Slide 28

Slide 28 text

まとめ 最後にまとめましょう。

Slide 29

Slide 29 text

まとめ ● 情報収集も良いけど、手を動かして現状を確認！ ○ リリースノートも人が作っているので、漏れもある ○ プロダクトも様々だし、合わないことだってある

Slide 30

Slide 30 text

まとめ ● 一見大きなタスクに見えても、分割する方法はある！ ○ そのヒントは実はマイグレーションマニュアルなどにある ○ 柔軟な発想でタスクを分割

Slide 31

Slide 31 text

まとめ ● けど ○ プロダクト全体を見ることができた ○ イベント登壇できる機会が得られたのはプラス

Slide 32

Slide 32 text

ご清聴ありがとうございました 良ければ、Xフォローお願いします。 こめつぶ🍙 | 2歳児のパパエンジニア@BABY JOB @kometsubu_bj