It’s time for another Rails upgrade! We all have our share of bad experiences and frustrations every time we upgrade a piece of software. Even for technical people who live and breath on the edge, upgrades are one of these things we try to avoid as much as possible. Still, there is always a sense of excitement in trying something new even if it adds problems to an already stable piece of code.
For a little background, I am upgrading a Rails app several of friends and I have written last year. The code is available at github.
In this post, I share the steps I did to boot the application. This doesn’t mean the upgrade went fine neither the app is ready to go. It only means all the required initialization are OK. In succeeding posts, I share my experiences in upgrading the app to a green state.
First, my environment.
greg@piccolo:~/dev/projects/propsify3$ rvm info ruby-1.8.7-p299@propsify: system: uname: "Linux piccolo 2.6.31-22-generic #61-Ubuntu SMP Wed Jul 28 01:57:06 UTC 2010 i686 GNU/Linux" shell: "bash" version: "4.0.33(1)-release" rvm: version: "rvm 0.1.44 by Wayne E. Seguin (firstname.lastname@example.org) [http://rvm.beginrescueend.com/]" ruby: interpreter: "ruby" version: "1.8.7" date: "2010-06-23" platform: "i686-linux" patchlevel: "2010-06-23 patchlevel 299" full_version: "ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-linux]" greg@piccolo:~/dev/projects/propsify3$ script/about About your application's environment Ruby version 1.8.7 (i686-linux) RubyGems version 1.3.7 Rack version 1.0 bundled Rails version 2.3.2 Active Record version 2.3.2 Action Pack version 2.3.2 Active Resource version 2.3.2 Action Mailer version 2.3.2 Active Support version 2.3.2 Application root /mnt/hgfs/greg-mini/dev/projects/propsify Environment development Database adapter postgresql Database schema version 20100113032723 greg@piccolo:~/dev/projects/propsify3$ gem list *** LOCAL GEMS *** actionmailer (2.3.2) actionpack (2.3.2) activerecord (2.3.2) activeresource (2.3.2) activesupport (2.3.2) geokit (1.5.0) json (1.4.5) mime-types (1.16) oauth (0.4.1) pg (0.9.0) rails (2.3.2) rake (0.8.7) RedCloth (4.2.2) twitter_oauth (0.3.2) greg@piccolo:~/dev/projects/propsify3$ ls vendor/gems/ authlogic-2.1.3 geokit-1.5.0 haml-2.2.16 macaddr-1.0.0 twitter_oauth-0.3.2 uuid-2.1.0 greg@piccolo:~/dev/projects/propsify3$ ls vendor/plugins/ acts_as_commentable geokit-rails is_taggable thinking-sphinx will_paginate declarative_authorization gravatar-plugin jrails validates_date_time exception_notification haml subdomain-fu vote_fu
Step 1: Install rails 3
gem install rails –pre
Step 2: Install the plugin tool
script/plugin install git://github.com/rails/rails_upgrade.git
Step 3: Show upgrade checklist
This task lists the items you should watch out for when doing the upgrade. You don’t need to fix everything right away (some are deprecation notice) but review the checklist nevertheless.
Step 4: Generate the new routes
This task reads the current config/routes.rb and outputs a Rails 3 version.
Don’t worry, it doesn’t override your routes file. Keep this in a safe place for later use.
IMPORTANT: I actually didn’t realize I did the right thing until after the actual code upgrade. When I tried generating the new routes after the code change, it outputted an empty block. I have no idea if this is unique to my case but just to be sure, generate the routes beforehand and keep a copy.
Step 5: Create Gemfiles
Next is to generate the file ‘Gemfile’. In Rails 2, the gems you need are listed in config/environment.rb while in Rails 3 the gems are listed in the Gemfile. Gemfile is used by the program ‘bundler’ to manage the gems required by your application. Unfortunately, this task didn’t include the gems I listed in environment.rb so I have to add it later.
Step 6: Backup your files
I hope you are working on another branch (or a copy) but just in case you are not, run this task to make copies of the files that will be affected during the upgrade.
Now comes the juicy part.
Step 7: Generate the Rails 3 app on top of your Rails 2 app
rails new propsify3 -d postgresql
Run this command in your app’s parent folder. In my case, my app’s name and pathname is ‘propsify3’ and I am using postgresql as my database. This command created and replaced a bunch of files. Since you’ve backed-up everything, there’s nothing to worry.
Step 8: Move code from environment.rb to application.rb
Your new config/environment.rb file looks like it went through a rigorous diet. You can leave this file for now. What is important now is you move the initializer code from your config/environment.rb.rails2 to config/application.rb. These are the config.* lines except the config.gem which goes to Gemfile.
Step 9: Convert the new routes
You can still use the existing routes until 3.1 but since there’s a tool to help you migrate, I suggest doing it. At this point, when I tried the rails:upgrade:routes, no routes were generated. So make sure you generate the routes before Step 7.
Step 10: Delete new_rails_defaults.rb
Step 11: Upgrade the plugins and gems
Many plugins are now available as gems. Check your plugins and gems at http://railsplugins.org. In my case, the following plugins were converted to gems:
Unfortunately, the plugins below are not yet ready for Rails 3. I removed them for now and all code that references them.
IMPORTANT: In your Gemfile, make sure you check specify the right version that is compatible with Rails 3. Some gems are still in the pre-release version and will not be downloaded if you don’t specify a version in your Gemfile. For example, this is a snippet from my Gemfile:
gem 'pg' gem 'acts_as_commentable' gem 'declarative_authorization' gem 'haml' gem 'thinking-sphinx', '2.0.0.rc1', :require => 'thinking_sphinx' gem 'will_paginate', '3.0.pre2' gem 'uuid' gem 'geokit'
Step 12: Update initialization code
After step 10 you are good to go, if you’re lucky. In my case, I had to remove some patches and change code to boot the application.
This fails in Rails 3 because core extensions have been moved out of their modules and are now included in classes they extend. For example, to fix the date format problem do:
Step 13: Boot the app
Yay! If you are wondering what happened to
script/server command, Rails went the “Merb way” and consolidated the
script/* commands into the
By now, you should see the famous Rails’ “Welcome aboard” message in your browser.
Step 14: Remove public/index.html
Now, you can try if your application is working.
There are still more work to do like moving to the ActiveRecord/ActiveRelation API and removing the deprecation notices. Before moving on, I still need to fix the problems in my routes and unsupported gems which I will tackle in my next post.