Upgrading Rails Applications – Some things to keep in mind!

Karthik Muthupalaniappan, Wednesday, December 23, 2009 @ 2:06 pm

So we just went through this humongous (believe me!) effort of upgrading the technical platform for one of our existing Rails applications that was running Rails 2.1, Ruby 1.7 and Mongrel cluster. The goal was to upgrade to Rails 2.3, Enterprise Ruby 1.8.6 and Passenger. It all started out as well as you would think. Updating the Rails gem, Ruby version, installing/configuring Passenger and updating relevant gems was pretty quick and smooth. Some quick and dirty testing of the application did not reveal any major problems or issues. Great! You are thinking the upgrade is mostly done att this point before you move on to the tests in the application!

Tests

Tests can prove to be major hurdle in upgrading Rails applications.  In our specific case,  close to 70% of the tests were either broken or failing due to a number of reasons.  Actually, the number of broken tests was way way greater than failing tests which led us to think the changes in the Rails testing API caused most of these issues.  Some of the issues were also caused by a plugin or gem that was used to support the tests not being compatible with the new API. It took us quite a bit of effort to figure out the reasons for the issues and also find the fixes.

Plugins

I think this is other major pain point. If your application uses a bunch of plugins to support what it does, then be wary of the roadblocks they can pose when it is time to upgrade Rails or Ruby in your application.  The problem mostly arises because of the fact that the community or the user group that built the plugin dont continue to support it or doesnt bother to make it compatible with newer versions of Ruby or Rails. In situations like these, you get thrown into a state of dilemma thinking about whether to write a new plugin to replace the existing one or fix the existing one both of which could be time-consuming.  It makes sense to spend time finding about what exactly is the need for the plugin in the application and if it is indispensable etc before making a wise decision.

Deploying the upgraded application

Though this may not be as hairy as the first two, it could be still prove to be a challenge especially when your the application server is changing (Mongrel -> Passenger).  I think it is important to ensure the script is modified appropriately and is tested adequately in your staging environment before you deploy the upgraded application to the real-world.

Session handling issue with Rails 2.3

For the benefit of Rails community out there, I d like to briefly recount one of the problems that caused me a quite a bit of headache during the upgrade.  The application in question is a content management website with multiple subdomains. The issue that I saw after the upgrade was after user logged into the one of the subdomains in the site and navigated away to a different subdomain, the user got logged out. When the user returned to the subdomain where he logged in originally, he was logged in again.  After several hours of effort trying to debug the issue (at one point,  I was even thinking about stripping out Restful authentication and plugging in Authlogic), this post saved the day for me.  It boiled down to setting this in the <environment>.rb file for the different environments :

config.action_controller.session = {
  :domain => "<root-domain-name>"
}
 

This allowed the session information to be persisted across multiple subdomains of the site.

Some Advice

• Generally, the amount of effort to upgrade is going to be directly proportional to the time between the upgrades. So, upgrade your application often!
• When choosing plugins or gems to support your application, consider the upgradability of these before you decide to use them!
• Last but not the least, spend atleast 25% of the time necessary for the upgrade itself to estimate how long it might take to get it done

Related posts:

1. Testing various roles in ruby on rails
2. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 2: Displaying iPhone content to the client” Also up on IBM Developerworks
3. “Developing iPhone applications using Ruby on Rails and Eclipse, Part 3: Developing advanced views for iPhone” now available on IBM Developerworks
4. Rails Development on Windows: Native or Virtualize
5. Major Security Hole Found in Rails

Comments (3)

Software Development

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Ruby 1.7? As far as I know Rails can only run on Ruby 1.8.4 or higher, and all Rails apps that Pathfinder deployed that I worked on were 1.8.6 p111 or 1.8.6 p287

   Comment by Michael King, Monday, December 28, 2009 @ 11:07 pm

2. 

   Thanks for the correction @Micheal. It should have been 1.8.6 and not 1.7.

   Comment by Karthik, Monday, January 11, 2010 @ 9:51 am

3. 

   Looking at the changesets at guides.rubyonrails.org is really helpful pre-upgrade. I agree that upgrading minimizes the number of major problems in the upgrade, but given that, I think there is such a thing as upgrading too frequently and not getting any work done. I had an experience with that from Rails 2.2.2 to 2.3.2

   Comment by Jerry Cheung, Thursday, January 21, 2010 @ 6:24 am

Leave a comment