Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
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 ● 私は入社2カ月目 ● プロダクトについて右が分かり始めた程度 ● 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 なぜか? そう、ここです。 入社2カ月目だったのでそんなにプロダクトのに詳しくなく 情報収集した内容だけで大まかなスケジュールを立ててしまったので す。 その結果、大幅なスケジュール変更が必要になりました。
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. 1~2を繰り返す 4. アップグレードする 5. 1の設定を削除する このようにして一見、全てを同時に対応しないといけないように考えられ るアップグレードを分割することができる
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