概要
ライブラリのアップデート時の確認としては、基本的にこちらに書いてあることを実践すれば良いと思います。
以下では上の記事に記載されていることの具体的な実施方法や、追加で個人的にやったほうがいいと思うことを記載します。
Breaking Change有無の確認方法
対象のライブラリのGitHubのChange Logやリリースノートを確認することで、Breaking Changeの有無を確認可能です。
New FeaturesやBug Fixに関しても同様に行えば良いので、これらに関する説明は省きます。
Change Logの確認方法
きちんとしたライブラリであれば、リポジトリにCHANGELOG.mdのようなファイルがあります。
↓rmagickの例
Change Logには名前の通り、各バージョンにおける変更内容の一覧が表示されているので、現在のバージョンとアップデートしたいバージョンまでのバージョンまでに、Breaking Changeがないかを確認すればよいです。
Breakingで検索すれば、簡単に確認可能です。
リリースノートの確認方法
対象のライブラリのGitHubのReleasesの箇所を確認すればよいです。
Breaking Changeなどの探し方に関しては上と同様です。
その他やるべきこと
Breaking Changeがない場合でも、動作確認はしたほうがいいです。
まれにBreaking Changeがサイレントリリースされていることがあったり、見落としがあったりする可能性があるからです。
影響を受ける可能性がある、サービスの主要機能をざっと動作確認すれば良いと思います。
ToDoリスト
- [ ] アップデートの目的確認
- [ ] production用かdevelopment用かtest用か確認
- [ ] メジャー・マイナー・パッチのどれがどれくらい上がったかを確認
- [ ] 該当バージョンがリリースされてからあまりにも短くないか確認
- [ ] リリースされてから数日程度しか経っていない場合は、新しいバグが発見される場合があるため様子を見る or バグを発見したら切り戻してバグ報告をする
- [ ] ライブラリについて理解
- [ ] ライブラリがプロダクションコードでどのように使われているか理解
- [ ] Change Logの確認
- [ ] Breaking Change, Feature, BugFixがきちんと書かれている場合、Breaking ChangeとBug Fixを重点的に確認すればよいと判断
- [ ] そうでない場合はcommit/diffを丁寧に確認する必要があると判断
- [ ] Breaking Changeの確認
- [ ] ある場合は、その機能について理解
- [ ] アプリケーションコードへの影響範囲の確認
- [ ] 対処法を考える
- [ ] テストでカバーできてる範囲の変更であれば、テストが通っていれば十分
- [ ] 対処法実施
- [ ] New Featureの確認: アプリケーションに影響を与える変更ではないが、新機能がアプリケーションのコードをより良くする可能性があるので、情報収集として行う
- [ ] Bug Fixの確認: (Bug Fixによりバグが発生する可能性は低いため、この段階では詳しく確認しなくてもよい)
- [ ] 動作確認ケース洗い出し
- [ ] 動作確認実施
- [ ] リリース
- [ ] リリース後に問題が起きた場合
- [ ] バグ発生箇所の特定
- [ ] 原因の特定
- [ ] Change Log & それに関連するPR/issue/commit/diffを読み、どの変更が原因かを明確にする
- [ ] ライブラリ自体の問題の場合
- [ ] 同様の問題報告などがないかをissue/PRをもとに探す
- [ ] 誰もissue/PRを上げてないのであれば、issue/PRを上げる****
- [ ] アップデートを見送る or パッチをあてる