When you upgrade a Rails application from Rails 6.1 to 7.0, you may suddenly see a lot of changes in the schema.rb file and wonder where those changes come from and how to deal with them.

In this post, we look at what those changes are, and how to deal with them when upgrading a Rails application.

At FastRuby.io, we don’t always run rails app:update in our process to upgrade Rails apps.

It might seem like a sacrilege - after all, that’s why the task was created, to make upgrading Rails as painless as possible, right? But we have found while upgrading dozens of applications that running rails app:update isn’t the best idea in all situations.

In this article, you will learn what rails app:update does, when it should not be used, and how to upgrade your Rails app without it.

Note: In Rails versions before 5.0, rails app:update was called rake rails:update.

If you are using the i18n gem with Ruby 3.0 or are planning to upgrade Ruby to 3.0 while using the i18n gem, this blog post will cover a gotcha that can be tricky to understand.

We are used to checking the deprecation warnings displayed by Rails or warnings from different gems, but Ruby itself can also display warnings to help us find code that can be problematic.

In this article we will explore how to use them, how to analyze them, and some examples of interesting warnings that can be really helpful during upgrades.

When we work on Rails upgrades, most of the time we have to solve issues after updating the gems. These problems can go from simple and straightforward to really complex and hard to debug. Here we will discuss different skills and techniques that we use to complete the upgrade.

Are you considering an upgrade for your Rails or Ruby application, but you’re concerned about low test coverage? Don’t worry! In this post, we’ll explore effective strategies to address the risks associated with low test coverage. By implementing these strategies, you’ll be able to upgrade your application with confidence. Let’s dive in!

Imagine having the ability to deploy the next version of Rails in a dual booted application on your Heroku staging server or review app before deploying it to production. This capability can help you avoid bugs and downtime in your live environment. In this blog post, we will guide you on how to deploy a Rails upgrade to a staging environment, allowing you to thoroughly test it before it goes live.

There have been a lot of changes over the years in asset management for Ruby on Rails applications. The main question, after all the madness, is… “What should I do if I need to upgrade my Rails application?”

In this article we will talk about the options we have for each version jump.

You are upgrading a Rails application. You finished fixing a deprecation warning and it’s not present anymore. You continue working on other tasks and one day you find out the deprecation is back in the codebase. New code was added using the deprecated behavior, but it was not detected and now it needs to be fixed again…

How can you prevent that from happening and, at the same time, let the team know?

Upgrading from Ruby 2 to Ruby 3 can be a challenging task, especially when your Rails application relies on ActiveJob with Sidekiq. In the process, you may encounter cryptic ArgumentError exceptions that make the upgrade seem daunting. By following along you’ll be well-equipped to avoid some of the hurdles that come your way.

Over the years, Rails has been changing the default way to handle assets while also adding different alternative options at the same time.

At first there were static files, then Sprockets appeared, then we had a choice between Webpacker and Sprockets for a few years, now Webpacker is gone and importmaps are the default. But jsbundling-rails and cssbundling-rails are also official options.

Sound confusing? In this article we’ll try to explain the history of all these changes.

On Monday June 12th, 2023, FastRuby.io partnered with Expedited Security to talk about how to secure your Ruby on Rails application.

In this free webinar Ernesto Tagwerker (FastRuby.io) and Mike Buckbee (Expedited Security) discussed topics of interest related to Rails security (exploitable ActiveRecord code, vulnerable dependencies, botnets, DDoS, a breakdown of common threats, and more).

You’ll also get a sneak peak of Wafris, an Open Source service to prevent attackers and dark traffic to your application and of our new Rails Security Audit, a service to detect vulnerabilities and exploitable code in your app!

After upgrading your application from Rails 3 to Rails 4, you might start seeing the following deprecation warning if you are using the readonly option in an association.

DEPRECATION WARNING: The following options in your Company.has_many :users declaration are deprecated: :readonly. Please use a scope block instead. ...

In this blog post, we’ll discuss in detail what the readonly option is and how to handle the deprecation warning.

As always, RailsConf was a great experience this year. For the fourth time, we gave the FastRuby.io Rails Upgrade Workshop. It was actually my 2nd time participating in running the workshop, and my co-worker, Fiona’s 1st time.

Each time we run the workshop, we like to bring in a new co-presenter, so different members of our team can have the opportunity to present at RailsConf.

Rails Engines are an architectural pattern that can be used to modularize a Rails application. They are self-contained applications that can be mounted within a larger Rails application. In this post, we will dive into the world of Rails Engines and explore what they are, how to create them, how to use them, when to use them, and why they are important.