My Favorite Rails Upgrade Strategy
Upgrading a Ruby on Rails app can be a daunting task, but I've found a strategy that works well, particularly for small to medium size projects.
Instead of using the
rails app:updaterake task, which is the approach recommended in the official Rails Guides, I prefer to generate a new app, for example with the following command:
rails new --database postgresql --skip-test /tmp/my-app # Use any other flag to make it as close as possible to the original app
Then, I replace all the files in the current repository with the new ones, except for the
.gitdirectory. After that, I compare the changes in each file and decide whether to keep or remove them based on whether they make sense for my project running on the new version of Rails.
One of the benefits of this approach is that it addresses all the necessary changes at once, rather than only updating the strictly required files like the rake task does.
The rake task will always create a
config/initializers/new_framework_defaults_[old-version].rbfile, which is frequently overlooked and left unmodified (until it causes problems or during the next upgrade), resulting in the app running on the new Rails version with some of the old version's defaults.
The strategy I use can be a bit more time-consuming (after all, you're ripping the whole upgrade steps off like a Band-Aid), but in my experience, it has resulted in fewer issues.
For example, I recently upgraded an app and realised that with the rake task approach, it didn't upgrade the
app/models/application_record.rbfile at all, while this method would have replaced:
class ApplicationRecord < ActiveRecord::Base - self.abstract_class = true + primary_abstract_class end
It's not a big deal but I'd like to have my app fully upgraded, almost like it was created using the
rails newcommand from the latest Rails.
Overall, while both approaches can get the job done, I find that generating a new app and carefully comparing the changes is a more reliable strategy for upgrading a Rails app.