こんにちは、YOUTRUST SREの寺井(YOUTRUST/X)です。

私はYOUTRUSTで使用しているライブラリやプログラミング言語のアップグレードを率先して進めており、ちょうど年の節目だったので数えてみたところ、2024年の一年間で500回のバージョンアップを行っていました。

今回は、私がどのようにして2024年の一年間ライブラリのバージョンアップに取り組んできたかを紹介したいと思います。

どうやってバージョンアップを継続してきたか

私がバージョンアップを進めているライブラリは、Webフロントエンド(React / TypeScript)とWebバックエンド(Rails)で使われているライブラリで、ネイティブアプリ(Flutter)で使われているライブラリは担当していません。(※こちらはいつも朝日さんが上げてくれています！)

私がSREに異動したのは2024年8月からですが、もともと技術的負債の解消やライブラリのアップグレードには強く関心があったので、SREに異動する前のプロダクト開発エンジニアの頃から各種ライブラリのバージョンアップに取り組んでいました。

Dependabot編

まず、毎朝出勤してから10分から30分ほどライブラリのバージョンアップに時間を使って、Dependabotによって作成されたPRをmergeしてから業務を開始しています。

入念な検証やアプリケーション全体のコード修正が必要なアップグレードの場合は、朝の時間にこだわらず日中に時間を作って対応しています。

バージョンアップを進める際に特別なことは何もしておらず、まずリリースノートを読んで変更差分を確認して、挙動に影響がないと確信できるとき以外は動作確認を行っています。

パッチバージョンアップの場合や、開発環境やテスト環境でしか使われていないライブラリの場合は、リリースノートだけ読んでmergeすることも多いです。

ライブラリに破壊的な変更が含まれていてアプリケーションコードの修正が必要な場合は、そのコード修正を先にリリースしてから再び動作確認を行ってバージョンアップを実施しました。

手動バージョンアップ編

ほとんど最新に追従できているライブラリの場合はDependabotによるPRで比較的容易にバージョンアップができますが、メジャーバージョンが遅れているライブラリや認証系のライブラリ、プログラミング言語やフレームワークなどは入念な検証やアプリケーションコード全体の洗い出しが必要なことが多いです。

私が2024年に対応したライブラリだと、例えばrubyやtypescript、sidekiq、axios、devise系のライブラリ、omniauth系のライブラリなどです。(※ライブラリ名なのですべて小文字で記載しています)

そのような場合は、以下のような手順で進めました。

リリースノートを読んでライブラリの変更差分を把握
バージョンアップの方針策定とレビュー
アプリケーションコードに修正の必要があれば先にリリース
ライブラリをバージョンアップしたbranchでsandbox検証
最悪の場合生じるリスクの評価と社内への周知
あらかじめrevert PRを作成してすぐに切り戻せるように準備
万が一の際に影響範囲を抑えられる時間帯にリリース
本番環境で動作確認

また、どのライブラリのバージョンを優先的に上げていくかの判断は、バックエンドはbundle outdated、フロントエンドはyarn outdatedコマンドを実行して最新でないライブラリ一覧を出力し、このままバージョンを上げなかったときに発生する問題の大きさやサポートが切れるまでの期間などを考慮して行いました。

バージョンアップの優先度が高いフロントエンドのライブラリ(2024/10/31時点)

※画像は2024/10/31時点の状態で、2025/1/6現在は多くのライブラリのバージョンアップがすでに完了済みです

2024年一番記憶に残っているライブラリバージョンアップ

ここまでほとんど一般的なことばかりになってしまったので、2024年にバージョンアップしたライブラリの中で特に大変だったsidekiqのメジャーバージョンアップの話を少しだけしたいと思います。

YOUTRUSTでは当時sidekiqのバージョンが5系で、最新である7系に上げるためにまずは6系に上げようとしていました。

いつも通りリリースノートを確認して、特にYOUTRUSTで対応が必要な変更は見当たらなかったので、アップグレードガイドに従って5系の最新系から6系の最新系にバージョンアップするPRを作成しました。

すると、なぜかsandbox環境でのデプロイにだけ失敗してしまっていました。

改めてリリースノートを詳しく読み込んでも原因の見当がつかなかったので、何度かバージョンを変更しながら二分探索のように範囲を絞っていくと、デプロイ失敗の原因はバージョン6.0.5に含まれていることを特定できました。

リリースノートではなくcommitを1つ1つ読み進めていくと、こちらのcommitで環境変数RAILS_ENVよりも先に環境変数APP_ENVを見にいくように変更されていました。

YOUTRUSTでは環境変数RAILS_ENVでrailsの環境(development/test/production)を管理しているのですが、合わせて環境変数APP_ENVも使用してWebアプリケーションの環境(development/sandbox/production)を管理していたため、こちらが先に参照されるようになり、その結果sidekiq側で想定していない環境名であるsandboxが指定されたことでデプロイが失敗していました。

原因が分かってからは環境変数APP_ENVを別の環境変数にリネームして簡単に対応することができましたが、今回のようにリリースノートを読むだけでは予測することができないプロダクト特有の問題もあるんだなととても勉強になりました。