どれも、放っておいて良くなることはありません。時間が経つほど、選択肢が減り解決が困難になっていきます。
Rails が修正を出すのは最新の数系列だけです。そこから外れた瞬間、脆弱性が見つかっても公式の修正は届きません。自分たちで独自の修正を行うか、無視するかの二択になります。
入れたい gem が Rails のバージョンを要求して入らない。決済や SDK の更新に追従できない。新しい開発ツールも、AI の支援ツールも、古い環境では前提が合いません。
どこに影響が出るか読めないから、手を出せない。詳しい人ほど、その怖さを知っています。結果として「動いているうちは触らない」が既定路線になります。
上げた結果あちこち壊れても、気づけるのはユーザーからの問い合わせが来たときです。テストが無い状態でのアップグレードは、実質ぶっつけ本番になります。
線路は、ある日突然使えなくなるわけではありません。レールは少しずつ摩耗し、道床は沈む。すると、速く走ろうとしても線路がそれを許さなくなります。列車は走り続けます。ただ、少しずつ、確実に遅くなる。そしてその速度がいつの間にか普通になり、乗っている人はもう、遅いことに気づきません。
古いままの Rails に起きるのも、これと同じことです。
サポートの外に出れば、脆弱性が見つかっても公式の修正は届きません。危険だと分かった状態のまま、走り続けることになります。
開発を加速させる仕組みは、新しいバージョンにしか入りません。古いままでいる限り、その恩恵だけが素通りしていきます。
新しいライブラリは新しい Rails を前提にします。使える道具が少しずつ減り、車輪の再発明に時間を使うようになります。
ひとつひとつは、些細な遅れです。ただ積み重なると、事業のアイデアをプロダクトに落とし込む速度そのものが落ちていきます。しかもそれは徐々に進むので、社内からは見えません。気づくのは、競合と比べたときか、新しく入った人に指摘されたときです。
Ruby on Rails は、まさに電車のレールです。きちんと保線されてさえいれば、事業の構想を驚くほど速く形にして運んでくれる。それは、このフレームワークがもともと持っている力です。遅いのは、レールのせいではありません。手入れをする時間が、取れていないだけです。
だから、走らせながら保線する。
アップグレードで痛いのは、作業そのものではありません。誰がやるか、です。
アップグレードは、技術力のある人にしか任せられない。
そして社内でそれができる人は、たいてい開発の中心にいる。
影響範囲を読み、壊れた原因を切り分け、直すか回避するかを決める。どれも、フレームワークの挙動とアプリの構造を同時に追えないとできない仕事です。片手間の人には振れません。だから社内で探すと、自然と一番腕の立つ人に行き着きます。
その人が抜けた穴は、そのまま機能開発の空白になります。多くの現場で、二ヶ月。事業側から見れば、それは技術的な作業ではなく二ヶ月、事業の成長を止めるという判断です。
※ 二ヶ月は、バージョンの開き・アプリの規模・テストの有無で大きく変わります。実際の見立ては現状調査でお出しします。
「とりあえず上げる」ではなく、上げたあとに続く状態を作るところまでを範囲にしています。
まず、どこにいるのかを確かめる。
バージョン、gem の依存、テストの網羅、CI、デプロイ環境。どこがボトルネックになるかを洗い出し、経路と見立てをお出しします。
どこを経由して、どこまで上げるか。
最新が常に正解とは限りません。事業の予定と天秤にかけて、今回どこまで進めるかを決めます。分割してリリースできる形に落とします。
一段ずつ、テストを通しながら。
足場になるテストを先に用意し、一バージョンずつ上げていきます。各段で通ることを確認してから次へ進むので、原因の切り分けが効きます。
上げて終わり、にしない。
アップグレードは一度きりの作業ではありません。放っておけば、また少しずつ遅くなっていきます。継続的に見る形にすれば、次からは今回ほど大きな作業になりません。
事業を止めないことを最優先に組み立てます。
アプリの規模、バージョン、テストの有無、リリースの頻度を伺います。リポジトリを見せていただければ、より具体的な見立てが出せます。
どのバージョンを経由し、今回どこまで上げるか。並行して走る機能開発とどう衝突を避けるか。ここを決めてから着手します。
調査で出てきた修正を、ひとつ残らずチケットに起こします。着手前に作業の総量が見え、そこから期間の見積もりが出ます。終わりが見えないまま走り出す、ということをしません。
テストが薄い場合は、まず壊れたことに気づける状態を作ります。全部を網羅するのではなく、事業上落とせない経路から押さえます。
チケットのうち、今のバージョンのままでも入れられるものを先に片づけます。ひとつずつ小さな PR にして、普段のリリースに混ぜて本番へ出していく。一本ずつが小さいので、何かあってもすぐ戻せます。バージョンを上げる日に出る差分は、それだけ小さくなります。
一バージョンずつ上げ、各段でテストを通します。このとき設定は古いバージョンのまま据え置き、フレームワークの挙動は変えません。バージョンと挙動を同時に動かすと、壊れたときにどちらが原因か分からなくなるからです。
据え置いた設定を、ここでひとつずつ新しい既定値へ切り替えます。ひとつ変えるたびに確かめるので、何か起きてもどれが原因かは即座に分かります。まとめて入れれば早い、ということはありません。
本番に出すところまで伴走します。出して終わりではなく、残った課題と次に来るバージョンをお伝えします。そのまま継続して見る形にもできます。
Rails 本体だけを上げても動きません。周辺ごと引き受けます。
非推奨の置き換え、破壊的変更への追従、新しい既定値の適用
Rails が要求する Ruby への追従。最新の Rails は Ruby 3.2以上が前提です
依存の解決、メンテが止まった gem の乗り換え、bundler 自体の更新
足場としてのテスト追加。壊れたことに気づける状態づくり
アップグレードを支える CI の整備。次回以降の安全網になります
AWS 等の実行環境やビルド設定の追従。出せなければ意味がありません
Rails を長く見てきたことと、事業の言葉で話せること。その両方が要る仕事だからです。
フレームワークが何をどう変えてきたかを、リアルタイムで通ってきました。どのバージョンで何が壊れやすいかは、資料ではなく経験として持っています。
アップグレードで問題が出るのは、たいていフレームワークの外側です。周辺の事情ごと切り分けられることが、詰まらずに進めるための条件になります。
差分の調査や置き換えのような、量で殴る作業は AI ツールを組み込んで進めます。人手を増やさずに速度を出せるので、小さく始められます。
「なぜ今なのか」「今回どこまでやるのか」を、技術の言葉のままにしません。事業側が判断できる材料に翻訳するのが、私たちの本業です。
バージョンの開き、アプリの規模、テストの有無で大きく変わるため、調査なしで期間をお約束することはしていません。まず現状調査で見立てをお出しし、そこから判断していただく形をとっています。
同じ理由で、定額の料金表は用意していません。現状調査のうえで、範囲と一緒にお見積りをお出しします。「どこまでやるか」を決めれば費用も決まるので、まずは現状を教えてください。
止めない前提で組み立てます。一度に全部を切り替えるのではなく、分割してリリースできる形に落とすためです。どうしても停止が必要な場合は、事前に理由と時間をお伝えして判断を仰ぎます。
むしろ、その状態からのご相談が多いです。その場合はテストを足すところから始めます。全部を網羅するのではなく、事業上落とせない経路から押さえて、壊れたら気づける状態を先に作ります。
一気に飛ばすことは勧めていません。壊れたときに、どの変更が原因なのか分からなくなるためです。遠回りに見えても、一段ずつ上げて各段でテストを通すほうが、結果的に早く着きます。
その状態からでも引き受けます。どこまで進んでいて、どこで止まったのかが分かると、調査が早く済みます。途中の変更は、活かせるものは活かします。
できますが、基本的には分けることをお勧めしています。アップグレードと機能変更を同時に入れると、壊れたときの切り分けが難しくなるためです。まず上げきってから、別のリリースとして進めるほうが安全です。
バージョンがいくつで、いつから止まっているか。それだけでも、見立てをお返しできます。
「上げるべきか」を決める段階からのご相談で構いません。