Upgrade from Rails 3.2.x
I recently upgraded a Rails app from 3.2.x to 4.0.x, and this guide contains the general guidelines to follow for making the upgrade easier. If your Rails app version is <= 3.2, it’s very important that you upgrade immediately, since they no longer receives security updates.(http://guides.rubyonrails.org/maintenance_policy.html)
Upgrade Ruby ( 2.0/2.1/2.2)
Make incremental upgrades (Refer edge documentation)As per the edge documentation, If a rails app is on version 3.2, we should avoid upgrading to 4.2.x version directly. Instead, upgrade first to 4.0.x, then 4.1.x, and finally 4.2.x.
Gem-file and upgrade gems
Update the Gemfile with the version of Rails.
- gem ‘rails’, ‘3.2.18’ → + gem ‘rails’, ‘4.0.13’
Now, update the gem using bundler: bundle update railsRun a gem_file_check on your current rails version of Gemfile. Services below will give necessary inputs to update Rails app gems.
b) bundle outdated command
Note: Validate if any gems which are being used with git references in the Gemfile are merged onto a main version, and make sure the version number is referenced in the gem file.
Run the rails:update task
Rails provides a very helpful rake task to help with updating your config files. Before doing this, remember that this will replace many of the files in your config directory.You will be asked for confirmation about overwriting some of the files. You might want to keep your existing config/routes.rb file.
Run the rake task: rake rails:update
Note: rails:update task didn’t help me much as the app was configured heavily due to which i had to manually look at the configuration and edit as per my app needs.
The edge guide documentation
Rails 4.0 →
- has removed the assets group from Gemfile
- has removed attr_accessible and attr_protected feature in favor of Strong Parameters. You can use the Protected Attributes gem for a smooth upgrade path. Note: This plugin will be officially supported until the release of Rails 5.0
- requires scopes to use a callable object such as a Proc or lambda.
- deprecates dynamic methods except for find_by_… and find_by_…!. Here’s how you can handle the changes. To re-enable the old-finders we can add activerecord-deprecated_finders gem.
- deprecates asset-url with two arguments. For example: asset-url(“rails.png”, image) becomes asset-url(“rails.png”).
- has extracted ‘Active Resource’ to its own gem. If you still need the feature, you can add the Active Resource gem in your Gemfile.
- requires that routes using match must specify the request method(e.g get, post).
and most of the resources i referred, stress on extracting the plugins used in the application to separate gems.
Make your your test cases ready
Having a decent test cases is good, also make sure they are all green before you start with the upgrade. Unless application test cases were kept up-to date, this step would end up taking more time. if Rspec version is upgraded from 2 to 3, its time that you upgrade the syntax as well. Just FYI, gem https://github.com/yujinakayama/transpec could help save time in upgrading to Rspec 3 syntax .
Note: App i upgraded from Rails 3 to Rails 4 is a SPA and the front-end framework is Angular. In such cases, make sure key js files are spec’ed out during the upgrade.
Check what has changed
The official Rails Upgrade Guide has details about the major changes that might cause problems during the upgrade. It’s very important that you take a close look at the relevant section of this guide.Apart from that, Railsdiff.org lets you see the diffs between the files generated by various versions of Rails. That’s another way to understand what has changed between the versions.
Validate the diffs and remove monkey patches if any
Before you commit any changes, take a closer look at the diffs and find out what has changed. Your changes to the config files may get overwritten by rake rails:update. Hence, ensure that configurations for production don’t get updated to the Rails defaults.
Also, get rid of any Monkey patches.
Note: Monkey patches, i believe, depends on app. The App i upgraded had few angular built-in directives monkey patched ☺.
Fix the deprecated warnings
At this point, you’ll most probably run into some failing tests. Make sure you’re back to green before continuing. Also pay attention to the deprecation warnings that you might come across while running the tests. Your app may run all right despite these warnings, but fixing them now would save you a lot of time during the next upgrade.
- Generally, it’s a good idea to destroy the existing database and run db:create and db:migrate rake tasks with finalised rails 4 code. My app ran into issues the very first time when the tasks were run(Rails 4 code). The main issue figured was, that in Rails 4.0 when a column or a table is renamed the related indexes get renamed as well. If you have migrations which rename the indexes or which are working with indexes, it’s better to have a look at them and edit as per your app needs.If your app is SPA (angular), make sure you keep an eye on CSRF token generation (I ran into an issue with few api calls that involved User authentication. Adding gem ‘angular-rails-csrf’ solved the problem.)compass-rails, sass-rails, sass, sprockets, sprockets-rails gems version should be properly managed. http://stackoverflow.com/questions/22288951/actionviewtemplateerror-missing-host-to-link-to-please-provide-the-host-p
- Rails.application.routes.default_url_options[:host] = ‘*****.*****.com.au’
- If few parts of your app are on http and few on https, i recommend you look into the below stack overflow problem and solution.
- If your application is using devise, make sure authentication flow is well tested. There are many changes from devise 3.0.1 -> 3.4.0(e.g.. Token generation, accessibility of tokens in the views, method names etc..)