メンテナンスのリソースを十分に割けていないアプリでは、依存するパッケージの更新が2バージョン以上のメジャーアップデートになることもしばしばです。 パッケージをアップデートすることで、ビルドが失敗するようになることもあります。一気にバージョンアップできると気楽ですが、そうではないことがほとんどです。 今回は、依存パッケージの更新をする時に考えていることを、まとめてみます。

※ 状況によって対応は変わりますが、普段考えていることをまとめてみます。

大まかな作戦を立てる #

何を最優先にするかにもよりますが、安全に対応することを考えていることが多いです。 テストが実装されていればそれを活用しますが、案件によっては無いことも少なくありません。 そのため、テストがない場合や、5バージョンのメジャーアップや5年分のバージョンアップのような場合、バージョンアップで変更する規模が大きい場合は、1バージョンずつリリースするなど、段階的な対応を行うようにします。

現状を把握する #

アプリで使用している依存パッケージの最新バージョンを確認します。 合わせて、今使用しているバージョンが何ヶ月、何年前のものなのか、何世代前のものなのかを、GitHubなどのリポジトリや公式ドキュメントで確認します。

このとき、リリースノートやマイグレーションガイドも見つけておくと、作業がスムーズです。

作業の進み方 #

ひとまず最新にしてビルドする #

思い切って最新のバージョンに変更してビルドしてみます。 ビルドの結果で、次のアクションが変わってきます。

エラーなくビルドできた場合 #

ユニットテストがあれば実行し、十分に動作を確認します。動作中のログをよく確認し、警告やエラーが出ていないか確認します。APIの設計が変化していなくても、実際には挙動が変わっていることがあるので、動作確認やログのチェックを注意して行います。 問題が発生したり、気になるログがある場合は、それについて調査します。 リリースノートやパッケージのコード差分を読む場合もあります。

エラーした場合 #

エラーの内容を読んで、すぐに修正できそうなら直します。 ただし、エラーの内容によっては、バージョンをひとつずつ変えながらビルドが失敗するバージョンを把握することを選択します（ほとんどの場合はこっち）。

ビルドの成功と失敗の境界を特定する #

最新にしてビルドが失敗することを確認できたら、つぎは、どのバージョンでビルドが失敗するようになるかを確認します。 バージョンが特定できれば良いので、状況に応じて臨機応変に行います。

• 現在のバージョンから一定のステップでバージョンを上げながら、エラーになるバージョンを確認する
• 最新のバージョンから一定のステップでバージョンを下げながら、ビルドが成功するバージョンを確認する
• 例えば
  • 例) 2.x.x <-> 3.x.x <-> 4.x.x …
  • 例) 1.5.x <-> 1.6.x <-> 1.7.x …
  • 例) 0.5.2 <-> 0.5.3 <-> 0.5.4 …
  • メジャーやマイナーを変化させる時は、X.0.0やX.X.0のようなファーストリリースではなく、ラストバージョンを使うようにしている

明らかに破壊的変更が入っていると思われる場合は、ビルドが成功することを確認しながら、段階的にバージョンを上げていくことを選択します。

修正する #

失敗するバージョンが特定できたら、エラーログ・リリースノート・マイグレーションガイドをもとに、変更内容を確認して対応します。 対応する時は、破壊的な変更が入ったバージョンの直前のバージョンで正しくビルドできることを確認した上で、変更が入ったバージョンに切り替えて本対応します。

(その他) SDKバージョンを上げる時 #

SDKバージョンを引き上げる時（AndroidのtargetSdkVersionや、iOSで言うXcodeのバージョンを引き上げる時）は、言語・SDK・依存パッケージのバージョンを、SDKのリリース日に近いバージョンに合わせながらSDKのバージョンを上げていくことがあります。SDKが想定する最新の開発環境に合わせる意図があります。

以上