Upgrade Rails from 5.1 to 5.2
This article is part of our Upgrade Rails series. To see more of them, click here.
Before beginning with the upgrade process, we have some recommended preparations:
- Your Rails app should have the latest patch version before you move to the next major/minor version.
- You should have at least 80% test coverage unless you have a dedicated QA team.
- Follow a Git flow workflow to actively manage at least two environments: staging and production.
- Check your Gemfile.lock for incompatibilities by using RailsBump.
- Create a dual boot mechanism, the fastest way to do this is installing the handy gem next_rails.
For full details check out our article on How to Prepare Your App for a Rails Upgrade.
2. Ruby version
At the time of writing, the Rails 5.2 release is relatively recent, which means that some gems may still not be fully compatible, or contain deprecation warnings if you’re not using their latest version. RailsBump can help you check if the gem is compatible with Rails 5.0, but it may have annoying bugs/deprecation warnings on 5.2. Some (popular) gem examples are:
- friendly_id supports Rails 5.2 without deprecation warnings on the latest release, 5.2.4. [PR]
- activeadmin supports Rails 5.2 without deprecation warnings on the latest release, 1.3.0. [PR]
- acts-as-taggable-on added deprecation-free Rails 5.2 without warnings on the latest release, 6.0.0. [PR]
- awesome_nested_set supports Rails 5.2 without deprecation warnings on the latest release, 3.1.4. [PR]
- jbuilder supports Rails 5.2 with deprecation warnings on the latest release, 2.7.0. [PR] (not yet in a release)
4. Config files
As an alternative, check out RailsDiff, which provides an overview of the changes in a basic Rails app between 5.1.x and 5.2.x (or any other source/target versions).
5. Application code
There were not too many deprecations between 5.1 and 5.2 compared to past releases (see the full changelog here).
However, one major feature is the introduction of ActiveStorage.
a. Active Storage
Active Storage is a replacement for Paperclip and other gems, like Shrine. Paperclip in particular has been deprecated. If you’re using Paperclip, the maintainers wrote an in-depth migration guide which you can follow here.
Another major feature is the introduction of Credentials. It will eventually
replace the current
config/secrets.yml. Since there are also encrypted
config/secrets.yml.enc), its intention is to clear up the confusion.
Your private credentials will reside in
config/credentials.yml.enc, a file
that can be safely committed into your repository (its contents are encrypted).
To un-encrypt them, there’s a master key (
config/master.key) which should
NOT be in your repository (it’s git-ignored by default if you start a new
Rails 5.2 app). To edit the credentials, you don’t directly access
credentials.yml.enc, instead, there’s a
bin/rails credentials:edit task
which opens an unencrypted version of the file (as long as you have the master
One controversial aspect of it is the cross-environment credential sharing,
the credentials file will keep all of your development, test and production keys.
For more information on Credentials and a work-around to this last issue, check
out this post, where
Hash#dig to configure per-environment credentials.
6. Next steps
If you successfully followed all of these steps, you should now be running Rails 5.2! Do you have any other useful tips or recommendations? Did we miss anything? Share them with us in the comments section.
If you’re not on Rails 5.2 yet, we can help! Download our free eBook: The Complete Guide to Upgrade Rails.