Rails・Rubyバージョンアップ支援

アップグレードが止まる理由

古いバージョンのまま動いているRailsアプリの多くは、誰も気にしていなかったわけではありません。アップグレードがスプリントに収まらなかっただけです。そのまま月日が経つと差は広がります。gemが古いバージョンのサポートをやめ、セキュリティ修正が届かなくなり、Rails 5のコードを触りたい開発者も減っていきます。

解決策は、たいてい作り直しではありません。普段の業務の中でマージできるくらい小さな段階に分けた計画です。

進め方

1. 調査・計画。 移行先のRailsとRubyで御社のテストを実行し、非推奨警告とGemfileを読み、障害になる箇所をすべて洗い出します。対応するバージョンがないgem、Rails内部へのモンキーパッチ、挙動が変わった機能に依存するコードなどです。作業順序と見積もりを含む計画書をお渡しします。
2. デュアルブート。 現行バージョンと次のバージョンの両方で起動できるようにします。御社が通常どおりリリースを続けながら、作業をメインブランチに取り込めます。
3. 小さなプルリクエスト。 一つの非推奨対応、一つのgemごとにプルリクエストを分け、御社のチームにレビューしていただきます。確認されていない変更はマージしません。
4. 切り替え。 新バージョンでテストがすべて通ったら、デフォルトを切り替えて旧バージョン用のコードを削除します。そして次の段階へ進みます。

私たちに頼む理由

私たちは多くのチームよりも先に、新しいRubyを本番環境で使っています。自社サービスのJapan Voyageは、Rubyの開発ブランチを毎晩ビルドした Ruby master で本番稼働しています。masterで何かが変われば、その週のうちに気づきます。自分たちのデプロイが先に壊れることもあります。

Ruby本体の開発にも関わっています。Sampo Kuokkanenはruby/ruby（Stringの高速化、テストの修正）、ruby/spec、JRubyに変更をマージしており、日本や台湾のRubyカンファレンスで登壇しています。Rubyの変更履歴を読むのは普段の仕事の一部で、御社の案件のために一から調べることではありません。

実際のアップグレードの記録もブログに書いています：Rails 8.1アプリをRuby 3.4から4.0にアップグレードした話

お渡しするもの

• 本契約の前に、障害箇所をすべて記した計画書
• 一つの巨大なブランチではなく、レビューしやすい小さなプルリクエスト
• どの段階でもデプロイできるアプリケーション
• 何をなぜ変えたかの記録。次のアップグレードは御社のチームだけで進められます