12

Some more Rails upgrade tips

 4 years ago
source link: https://medium.flatstack.com/some-more-rails-upgrade-tips-9fbc4797760f
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Ensure you have good test coverage

First and most obvious tip. If you not started your project just couple of weeks ago it will be a nightmare to do Rails upgrade with no tests. So, if you are not sure your tests will tell you that some functionality has broken during the upgrade, increase test coverage first of all. While it can be not so obvious whether you have enough tests in you projects, it can be helpful to use some of test coverage tools like Simplecov.

Choose the appropriate upgrade strategy

Before the upgrade it worth to choose upgrade strategy: whether to introduce all changes that incompatible with previous Rails version in separate long-living branch or use dualboot technique.

Both ways have their pros and cons. Following first approach you will have to keep all incompatible changes in separate branch and sync it with the base branch until upgrade and regression testing are completed (get ready for lots of conflicts resolving if there is active development). But this way looks pretty straightforward, since upgrade branch contains only changes required to work with new Rails version.

Using dualboot it’s simple to switch Rails version and related gems as change corresponding environment variable and restart the app, but you will have to wrap all version-depended code into if-else statements and cleanup them later. I would suggest to follow this approach only if you have really huge codebase and frequent merge of changes in to the base branch is critical.

Update dependencies carefully

If you run bundle update rails after setting new Rails version in your project Gemfile, most likely you will stuck with bundling failure, since your dependencies (and/or their dependencies) are still requiring previous version of some Rails frameworks. While updating these dependencies sequentially, make sure make sure that you have only updated their versions to the lowest possible major and minor versions for working with Rails. This will save you from wasting time on fixing all breaking changes and debugging of unexpected behaviour. --conservative Bundler key is very helpful in this case as well as Gemfile’s pessimistic operator.

Also worth to note that successful complete of bundle install with new Rails version is not yet the guarantee of dependencies compatibility, so keep in mind that there can be some gems which have “greater than” constraint for Rails version in gemspec but they are not actually compatible with all of these versions. CHANGELOG.md and analogues often contains notes about whether the gem really started to support specific Rails version.

Get ready for debugging

After your app dependencies are resolved and app boots with no errors it’s time to check status of test suite. Applying changes from Rails release notes seems reasonable and that should cover most of failures. However there can be many spots which were affected by undocumented updates, so you will have to debug the test failure.

Sometimes finding the reason of test failure is tricky and can took several days. So there some things that were very helpful for me during the debug:

While the last approach seems to be hardcore it can really helpful when you don’t understand well what happens behind the scenes between two breakpoints of your program execution.

Сhecklists and follow-up tasks

If you have several services where Rails upgrade is needed, it worth to create update checklist and have same tasks breakdown in all projects. It may looks like so:

  • Bump new Rails version in Gemfile and fix dependencies conflicts.
  • Make app start successfully.
  • Replace positional test request arguments with keyword arguments.
  • Update the gem X to prevent Y.

You can also create tasks for non priority issues that do not block the Rails update to deliver upgrade asap. Here’re some examples of such tasks:

  • Fix warning messages produced by gem X.
  • Replace all #to_unsafe_h and #permit! calls on user-supplied parameters used for mass-assignment.
  • Upgrade gem X when changes from applied patch will be released.

Last steps you may forget

After your test suite becomes green, it worth to not to forget about some little things:

  • Your schema.rb is updated correspond to the new Rails version.
  • rails db:setup completes successfully with correct seeds creating.
  • All migrations that should run with new Rails version are versioned.

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK