Railsのメジャーバージョンは3年ほどでEOL(保守終了)となります。なのでリリースしたアプリも1〜2年くらいのスパンでのバージョンアップを考えなければなりません。また、Railsだけでなく利用しているGem一式、及びgemで管理していないJavaScriptもバージョンアップも対象となります。
バージョンアップさせないまま放置した場合の問題点
- 開発者が最新のRubyやRailsを使えず機能改善の恩恵を受けれない。
- 優秀なエンジニアを集めにくくなる。
- 最新版から離れれば離れるほどバージョンアップのハードルは上がる。
- 改修が入るたびにバージョン固有のコードが内部に増えてバージョンアップへのハードルが上がる。
- 利用gemに制約が入る。
- セキュリティリスクが高まる。
バージョンアップの種類
日常的に行う小さなバージョンアップ
下記コマンドを実施するのが早いでしょう。
1 |
bundle update |
bundle update後は下記のステップでチェックを行いましょう。
どのgemのバージョンがどう上がったのかを確認する。
bundle updateのログや、更新されたGemfile.lockをgit diffすれば確認できます。
バージョンアップ内容が妥当かを調査する。
変更内容はGitHubにある各gemのリポジトリの変更履歴やリリースノート等から理解します。特にメジャーバージョンが上がっていて本番環境に影響あるgemについては念入りに変更内容を確認するようにしましょう。
バージョンアップ内容に誤りがあるgemがあればバージョンを戻す。
もしバージョンアップに問題のあるgemは該当gemだけバージョンを固定し今後のバージョンアップを抑制します。固定するりゆに関してはGemfile内にコメントとして残しておきましょう。また、gemの最新版で問題が解決されていないかは定期的にリリース情報をチェックするようにしましょう。下記のコマンドを使えばgemに更新があるかどうかを簡単にチェックすることが可能です。
1 |
bundle outdated |
gemの変更に伴うコードの修正を行いリポジトリに取り込む
バージョンアップによるコードを修正し終えたらプルリクエストを出してCIツール(DependabotやDeppbot等)によって自動テストを実施しリポジトリにマージします。
しっかりと準備して行う大きめのバージョンアップ
具体的には下記のバージョンアップ作業が該当します。
- Railsのバージョンアップ
- Rubyのバージョンアップ
- 影響が大きいgem(Bootstrap、Solidus、Devise等)のバージョンアップ
- 全然バージョンアップしていないシステムでgemの上げ幅が大きい場合
入念な準備が必要になるので下記のことはしっかり検討するようにしましょう。
自動テスト
自動テストで補完できない部分は手動テストで行う。
動作確認方法
時には開発担当ではなく仕様に詳しい方に動作確認を依頼する必要があります。
リリース方法
一度にリリースするか、段階的にリリースするかを判断する。段階リリースの場合はリバースプロキシやロードバランサ等でリクエストを振り分けて観察しても良いです。(その場合はCookieやDBアダプタ等の非互換性には注意する必要があります。)
ロールバック方法
ロールバックの手順は明確にしておきます。
監視方法
下記の監視項目に基づいて監視を行います。
- レスポンスタイムに問題ないか。
- エラーは発生していないか。
- バージョンアップ前には発生していなかったエラーは出ていないか。
この記事へのコメントはありません。