1. Upgrading to Rails 5
This chapter covers the process of upgrading an existing Rails 4.2 application to Rails 5. While I obviously cannot cover every situation and mixture of gems and configurations, I describe the general upgrade procedure and point out the required changes to your application.
Moving a complex existing application to a major new version of Rails can be stressful, but with good test coverage and a methodical approach, it should be a straightforward process.
Test Coverage
Before you begin the upgrade process, you should take a look at your applications test coverage . Having a solid suite of tests for your application, including end-to-end integration tests, is an important way to help you ensure that the upgrade to a new version of Rails hasnt broken any existing functionality.
If you find there are areas of your application that are lacking in test coverage, please consider spending some time addressing this before you start moving your application to Rails 5.
Once you are happy with the state of your test suite, then its time to continue.
Upgrading Ruby
Before you touch your Rails application, you must ensure that the version of Ruby you are using is 2.2.2 or above. At the time of writing, the latest version of Ruby is 2.3.0. Since Ruby 2.3 features a number of performance and memory management improvements, you should use it, if possible.
How you upgrade your Ruby installation depends entirely on the setup of your development environment on your local machine.
If you are using OS X or Linux, then you are likely to be using rbenv, RVM, or chruby, so upgrading should be a simple matter of building and switching to the necessary version.
If you are running Windows, rubyinstaller.org has installers available for up-to-date versions of Ruby.
Of course, if you intend to upgrade any production applications to Rails 5, you must ensure that your production servers are upgraded to a suitable version of Rails before you deploy your application. Depending on the version of Rails that your application is currently using, it may not be compatible with Ruby 2.3.0, so you must take that into account when upgrading and planning your deployment.
You should specify the Ruby version in your applications Gemfile. Do this by placing the ruby directive in your Gemfile. For example:
ruby '2.3.0'
While this is not a requirement, it is good practice because it ensures that all the developers working on your project and your test and deployed versions are running on the same release of Ruby.
Upgrading the Rails Gem
Once youre happy with your applications test coverage and you have ensured that you have the up-to-date version of Ruby, its time to switch your application to Rails 5.
Before you move to Rails 5, you should ensure that your application works fine on the most recent version of Rails 4.2 (at the time of writing, it is version 4.2.5.1) in order to ensure that you spot any deprecation warnings or have other issues with your application that arent a result of the move to Rails 5.
Now change the specified version of Rails in your Gemfile to 5.0.0:
gem 'rails', '5.0.0'
Then run the bundle update command, specifying to update the Rails gem .
$ bundle update rails
This installs the latest Rails gem, along with all the necessary dependencies. If you look at the differences in your Gemfile.lock before and after the bundle update, you see that all of the Rails-related gems (such as activerecord, actionpack, and actionview) have been upgraded. You also notice a new addition, actioncable.
The rack gem has been updated to the latest version of the Rack 2 gem. Rails 5 is not compatible with older versions of Rack.
Rails Update
You should now run the Rails update command to update the Rails support files, such as the default configuration files and initializers.
To initiate this, enter the following command:
$ rails rails:update
This command checks all the relevant files; it skips identical ones, creates new files, and asks for permission to update any conflicting ones.
You should be very careful and examine each file when a conflict prompt is shown. For example:
conflict config/environments/production.rb
Overwrite /Users/alan/Projects/Sensors/config/environments/production.rb? (enter "h" for help) [Ynaqdh]
Pressing the D key shows the difference between the current version and the version that would replace it. Either use this to update your local file manually, or overwrite your file and then add your edits.
Be sure to take a look at all the files there were added or changed by this process to understand if there are any implications for your application.
ApplicationRecord As the Base Class for ActiveRecord Models
By default in Rails 5, when you generate a new model, it is created to inherit from a model called ApplicationRecord.
This is similar to how Rails controllers inherit from ApplicationController. It gives you a place to keep common methods and behaviors for your models.
The model generator checks in your app/models directory; if a file application_record.rb exists, it uses that as the superclass for the model being generated, rather than ActiveRecord::Base .
Since this is the preferred new behavior for Rails 5, you should create the app/models/application_record.rb file and enter the class, as shown in Listing .
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
end
Listing 1-1.
The New Default ApplicationRecord Base Class
You should then update your existing model files to inherit from this. For example, change
class Product < ActiveRecord::Base
to
class Product < ApplicationRecord
While doing this isnt mandatory, it is the expected and preferred behavior for Rails 5 applications, so it makes sense to bring your application up to date.
ApplicationJob As the Base Class for ActiveJob Jobs
Similar to ActiveModel classes now having the ApplicationRecord superclass, newly generated ActiveJob jobs inherits from ApplicationJob if the app/jobs/application_job.rb file exists.
To keep in line with this behavior, you should create the app/jobs/application_job.rb file with the class definition in Listing .
class ApplicationJob < ActiveJob::Base
end
Listing 1-2.
The New Default ApplicationJob Base Class
Then update any existing job classes to inherit from this by changing the superclass. For example, change
class CalculateRatingsJob < ActiveJob::Base
to
class CalculateRatingsJob < ApplicationJob
While the default ApplicationJob class is empty, you should look at moving any methods or configurations shared by all of your jobs to the superclass.
Upgrade to PostgreSQL 9.1 or Later
If you are using PostgreSQL as the database for your application, you must ensure that you are using PostgreSQL version 9.1 or higher. Previous versions are past their end-of-life date and support for them has been dropped from Rails 5.