Rails 3.1: Upgrading a Simple App — Part 1
September 21, 2011
Here at End Point, I’ve worked with a few Rails 3 applications in production and a couple of Rails 3.1 apps in development, so I’ve become familiar with the new features and functionality including the Rails 3.1 Asset Pipeline that I mentioned earlier this year. I thought it was a good time to upgrade our website to Rails 3.1 and share the experience.
To start, here’s a quick summary of our website:
- Simple Rails application running on Rails 2.1.2 with no database
- Static pages throughout the site, fully cached
- Rake tasks to generate partials throughout the site to display dynamic blog content
- Site uses a moderate amount of jQuery and jQuery plugins.
- Site is optimized in terms of asset serving (ETags, Expires headers, CSS sprites, etc.)
While I’ve worked with a few Rails 3 apps, I haven’t been involved in the actual upgrade process myself. There are plenty of resources out there with upgrade advice, including a few RailsCasts (one, two, and three). My favorite resource was the rails_upgrade gem, a gem that is now officially supported by Rails to help with the upgrade process. I followed the instructions to install the gem (script/plugin install git://github.com/rails/rails_upgrade.git) to install it as a plugin in our site’s application in a fresh git branch (on a camp, of course!).
The rails_upgrade provides a few new rake tasks for checking compatibility, upgrading the routes, creating a Gemfile, and upgrading configuration. For me, the most valuable task was the rake rails:upgrade:check task. Here’s what the output looked like for this app:
As you can see, the upgrade check spits out a list of necessary and recommended upgrades and the corresponding culprits. It’s also nice that the task provides documentation in the form of a link for each message. Studying the source of the plugin, I found additional examples of upgrade messages: named_scope updates, validate_on_* syntax, test_help path updates, gem bundling configuration, Rails generator API syntax updates, messaging on known broken plugins (e.g. searchlogic, cucumber, nifty-generators), and depracation on ERb helper and AJAX calls.
I went through and applied my updates, according to the checklist. Notable updates were:
ActionController::Routing::Routes.draw do |map| map.root :controller => 'home', :action => 'index' map.connect 'contact/submit', :controller => 'contact', :action => 'submit' map.connect ':controller/:id' map.connect '*path', :controller => 'redirect' end
Endpoint::Application.routes.draw do root :to => 'home#index' match 'contact/submit' => 'contact#submit' match ':controller(/:id)', :action => :index match '*path' => 'redirect#index' end
Introduction of a Gemfile
source 'http://rubygems.org' gem 'rails', '3.1.0' gem 'json' # Gems used only for assets and not required # in production environments by default. group :assets do gem 'sass-rails', " ~> 3.1.0" gem 'coffee-rails', "~> 3.1.0" gem 'uglifier' end gem 'jquery-rails' gem 'fastercsv' gem 'execjs' gem 'therubyracer' gem 'rake', '0.8.7'
Renaming rhtml files
Something that didn’t come up in the rails upgrade check that is required to have a working app is renaming all rhtml files to html.erb, briefly described here.
Basic Asset Management
I followed the directions here combined with a bit of troubleshooting to configure a Rails 3.1 app that does not require a database.
The upgrade was a relatively painless process, although it still took a few hours for even the most basic application with only a handful of controllers, routes, and one mailer. My experience suggests that with a more complex application, the upgrade will take at least a few hours, if not much more. This simple app doesn’t do much with remote forms and links, so I didn’t spend any time upgrading the app to work with the jquery-ujs gem. Also, I obviously didn’t mess around with Rails 3.1 ActiveRecord issues since the application is database-less. Both of these items may add significant overhead to the upgrade process.
I spent a significant amount of time working with the new asset pipeline and restructuring the assets, which I plan to describe in Part 2 of the upgrade. Stay tuned!