Katawara.*

railsが2.0系になって、しばらく経ちました。
レンタルサーバーでも、徐々にバージョンアップが行われているようです。

そうなると、個人的には旧バージョンとの互換性はいかほどか、と気になるわけなのですけれど、特に何も対策を打たないならば、見事に動かないようです。
先日作ったTokyo24もバージョンアップされたrailsの前ではあえなくエラーで動かず。。
ということで、今回やってみた対策をまとめてみます。

まずは、今回のエラーログから。ログを見てみると、

Status: 500 Internal Server Error
A secret is required to generate an integrity hash for cookie session data. Use config.action_controller.session = { :session_key => "_myapp_session", :secret => "some secret phrase of at least 30 characters" } in config/environment.rb

みたいな感じで出ます（注：ある程度いじってから、ログを取り忘れてたことに気づいて取ったので、もしかしたら違うかもしれません）。

ヘタレなことに、内容がいまいち理解できていないのですが、ほかに何かいじった覚えもない辺りから、旧バージョンと新バージョンの違いでこんなエラーが出ているように思います。

ならば、対策案としては、アプリ上で、railsの古いほうを見てもらうか、新しいのに合わせるかのどちらかになるでしょう。

なので、まずは、お手軽なので、後者のアイディアを採用して、以下の感じでenvironment.rbにrailsのバージョンを直で指定してみました（ちなみに、1.2.2から1.2.3に変えるときはこれで動いてましたｗ）。

が、これはダメ。

1.2.2で動いていたものを無理に2.0.2に指定してもダメよ、ってことですかね。
ううむ。メジャーアップデートの壁は厚い。。

そんなわけで、今度は前者の対策案。
そして、結果的に正しい解決策だったのが、rake rails:freezeという手法。

これは、プロジェクトのvendor直下で打つコマンドで。
vendor配下にrailsというディレクトリを作成し、その中に、activerecordやらactivesupportやらといった、現在インストールされているrailsのソースコードをコピーして配置する効果があります。

これのすばらしいところは、そのプロジェクト上では、このコピーしたソースコードがrailsとして優先されるというところ。

サーバー上のrailsが2.0.2になろうが、なんだろうが、古いけど動いてくれたもののほうを見てくれるってわけです。

早速、ローカルは1.2.2で動かしていたので、コマンドをぶっ叩いてrailsファイルを作成、サーバーに送り込みました。
したら、びっくりするくらいあっさりと復活。いやぁ、よかったよかった。

ちなみに、これは、今やったみたいに、バージョンさえきちんと合わせられていれば、別プロジェクトで作ったものをそのままコピペしても、特に問題にはならないようです。

それにしても、もたもたしてるとフレームワーク側にあっという間に置いていかれる、このスピード感たるや恐ろしいものですね。
ヘタにまごついて開発に何ヶ月かかけようものなら、フレームワークのアップデート対策に追われてしまいそうです。
そんなとき、これでrailsを固定しておいて、頃合を見計らって、アップデート対策に乗り出すといいのかもしれません。

Via：

• Ruby On Rails ピチカート街道 - rails のツールのアップデートを止めておきたい　rake rails:freeze:gem と rake rails:unfreeze -