Upgrading to Rails 5 Beta - The Hard Way

Heroku walks through upgrading a production Rails app to Rails 5 beta using CodeTriage as the example. The post stresses that beta APIs are still unstable, so the work depends on a current Ruby, compatible gems, and repeated manual checks in console, server, and tests before deployment.

Reading notes

#

• A beta still has API changes coming, while an RC is treated as stable apart from bug fixes.
• Running a production app on a beta can help prepare for the release, but it requires confidence in the app, a strong test suite, and thorough manual QC.
• The first upgrade step is changing the Rails dependency, then running bundle install and updating incompatible dependencies.
• For Heroku, the post recommends avoiding the rubygems beta1 release and using a Rails master SHA because it includes a stdout logging fix.
• Rails now requires Ruby 2.2.2 or newer; the example app uses Ruby 2.3.0.
• Many gems do not declare an upper Rails bound, so compatibility has to be checked manually.
• The suggested workflow is to boot rails console first, inspect backtraces, update gems to newer releases or master branches, and open issues when a reproducible bug remains.
• Some missing Rails functionality can be replaced by shim gems such as record_tag_helper and rails-controller-testing.
• After console works, the server should boot and be exercised through real requests to catch exceptions and middleware problems.
• The article uses middleware inspection and logging to isolate an error in WebConsole::Middleware, which was fixed by moving to the gem master branch.
• Test failures should be reduced to one problem at a time; in the example, updating capybara fixed a Rack::Utils normalize_params error.
• The post notes Rails 5 changes to Strong Params and image_tag, both of which required attention in the example app.
• After the upgrade, deprecation warnings should be reviewed and fixed so the app is easier to move to Rails 5.1 later.
• Rails regressions should be reported in the Rails issue tracker, while general application problems belong on Stack Overflow.
• Once local code and tests pass, deploy to staging or a review app, watch logs for exceptions, and roll back if needed.