ライブラリのアップデート時に何をレビューするか

アプリケーションを継続的に開発する上で、依存ライブラリの更新は避けて通れません。この記事では、依存ライブラリの更新時に何をレビューするべきかをまとめます。

前提

• 筆者の Ruby での開発の経験を多分に元にしていますが、他の言語でも同様のことが言えるでしょう。
• dependabot や renovate と言った、依存ライブラリをアップデートする Pull Request を作るサービスを暗に仮定しています。

レビューするべき項目

Breaking Changes

Breaking change (破壊的変更)があるかは最優先で確認するべきでしょう。

Breaking change がある場合、該当する機能がアプリケーションから影響のある形で使われていないかを確認します。

New Features

追加された新機能も確認することに価値があります。

これらは一般的に既存のアプリケーションに影響を与える変更ではありません。一方で新機能がアプリケーションのコードをより良くする可能性があります。
そのため新しいバージョンでどのような新機能が追加されたのかを確認することで、有益な情報を得られる可能性があります。

Bug fixes

優先度は落ちますが、バグ修正を確認することも時として有効でしょう。

バグ修正と破壊的変更はどちらもプログラムの挙動を変えるという点で紙一重です。

とはいえコストパフォーマンスが良いわけではないため、重点的にレビューをするよりも、リリース後に問題が起きたときに原因を探すソースとして活用したほうが良いかも知れません。

レビューせずとも良い項目

CI など、開発環境の修正

CHANGELOG に、そのライブラリ自体の CI の改善やテストの修正、ドキュメントのタイポの修正などが含まれていることがあります。これは CHANGELOG を git のコミットから自動生成しているライブラリにありがちです。
そのような変更はライブラリを使用する側には基本的に影響しないため、無視すると良いでしょう。

その他気をつけること

テスト環境で使われるライブラリ

ライブラリをアップデートする PR をレビューする風景を眺めていると、時々「テスト向けなので ok」というコメントと共に PR が approve されているのを見かけます。
テスト環境のみで使われているものが本番に影響を与えないのは確かですが、テスト環境には影響を与えます。例えばライブラリのアップデートで意図せずテストがスキップされたり、テストの実行時間が急激に伸びたりするかも知れません。

そのような問題は稀ではあるものの、テストが正常に実行されないことはアプリケーションの品質に大きく影響を与えます。
私はテスト関係のライブラリの更新ではテストの実行時間をざっくりと見て大きく変化がないことなどを確認しています。

開発環境で使われるライブラリ

ライブラリをアップデートする PR をレビューする風景を眺めていると、時々「開発環境向けなので ok」というコメントと共に PR が approve されているのを見かけます。
開発環境のみで使われているライブラリが本番に影響を与えることは一般に少ないですが、これは必ずしもゼロではありません。

本番に影響を与える可能性があるライブラリとして、例えばコード生成系のライブラリが考えられます。コードの生成は本番環境で行われないため開発環境のみの依存として管理されることも多いですが、生成された結果のコードが本番環境で使われる場合、それは本番に影響を及ぼします。
そのようなケースでは開発環境向けだからといってレビューをおろそかにするのではなく、どのような変更があるのかレビューをすることが肝心でしょう。

また本番に直接影響しなくても、開発体験に大きく影響する変更があることもあります。レビューを行うことで開発体験の悪化を防げます。
とはいえ本番に影響がないならば切り戻しもしやすいため、本番に直接影響があるもののほうが優先度は高いです。