Ruby on Rails is a powerful web application framework that has evolved over the years, with new versions bringing in features, improvements, and security updates. As your application matures, keeping it up-to-date with the latest Rails version becomes crucial. However, the prospect of upgrading an entire Rails application can be daunting. In this blog post, we’ll explore whether it’s possible to upgrade your Rails application in increments and how to go about it.
Read moreArticles on Upgrades
In software development, there are instances where creating a long-running branch when working on a project will be considered by developers. Long-running branches have been debated a lot by many teams due to their risks mainly around but not limited to, dare I say it, merge conflicts.
However, it isn’t necessarily the evil it’s made out to be and when handled with care, they can present extreme value to a team. Even DHH argues the benefits of maintaining a ‘cohesive architecture’ in this article
Read moreAs we mentioned many times, at FastRuby.io we like to use the Dual-Boot technique during upgrades to quickly test the same code with the current and the next version of what we are upgrading. We usually talk about dual-booting Rails versions but this can be used to upgrade Ruby itself too. We have to make some changes to adapt the technique, and we’ll explain the basic changes in this article.
Read moreHow many times have you or someone on your team brushed off a failing build with a casual, ‘It’s fine, it’s just a flaky spec—ignore it’?
If you’re nodding in agreement, you’re not alone. It’s a scenario familiar to many of us, especially when dealing with sprawling monolithic projects and untouched code sections.
Read moreMaintaining an up-to-date Ruby on Rails application is crucial for performance, security, and feature enhancements. However, finding the time for a full-scale upgrade can be challenging. In this blog post, we’ll explore practical steps you can take to delay a Rails upgrade when you don’t have the immediate bandwidth but want to set the stage for a seamless process in the future.
Read moreYou just finished upgrading your app to the latest Rails version and you made the decision to never stay behind and always be ready to upgrade as soon as possible… But how can you do that?
In this article we’ll explain how the Dual-Boot technique can be used to test the app against Rails’ main
branch, to catch problems and warnings before a new version is released.
If you are upgrading a Rails application, you may come across the configuration of load_defaults
in the config/application.rb
file.
In this article, we will learn more about what to do with this configuration when working on a Rails upgrade.
Read moreMost people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.
However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.
- Rails 2.3 - 3.2: 5 - 15 upgrades
- Rails 3.2 - 4.2: ~40 upgrades
- Rails 4.2 - 5.2: ~40 upgrades
- Rails 5.2 - 6.1: ~10 upgrades
- Rails 6.1 - 7.1: ~10 upgrades
We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?
Read moreIn this blog post, I detail my journey upgrading a client’s Ruby from version 2.7 to 3.0. While some of the approaches I took may be tailored to their specific needs and might not directly apply to your situation, they offer insights into one possible path for upgrading Ruby, particularly in scenarios with limited test coverage.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 7.0 to version 7.1.
Read moreWhen working on upgrades, we use the Dual-Boot technique so we can gradually update the app to work with the current version and the next one.
Eventually, the upgrade is done and the app is ready to drop the old version, but how do we handle that process? What are the steps between one upgrade and the next?
Read moreWhen 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.
Read moreAt 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.
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!
Read moreImagine 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.
Read moreYou 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?
Read moreUpgrading 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.
Read moreAfter 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.
Read moreRecently, while working on a Rails 6.1 to 7.0 upgrade, we encountered the following deprecation warning regarding changes made to ActiveRecord::Relation’s merge
method:
"Merging (#{node.to_sql}) and (#{ref.to_sql}) no longer maintains both conditions, and will be replaced by the latter in Rails 7.0. To migrate to Rails 7.0's behavior, use relation.merge(other, rewhere: true)."
In this article, we will talk about the expected behavior of merge
, how it has changed and what to do in order to use the new behavior if you find yourself looking at this deprecation.
Ruby on Rails is a popular web application framework that is constantly evolving with new versions being released frequently. While upgrading to a newer Rails version can bring new features, better performance, and security patches/improvements, it can also be a challenging task.
In this blog post, we will discuss 7 common mistakes made while doing Rails upgrades and how to avoid them.
Read moreSince 2017 we have been focusing on upgrading Ruby on Rails applications. It’s been quite a fulfilling learning process as we continuously improve our workflow best practices, and internal tooling.
In this article I will go into detail to explain how we determine the best approach to create the roadmap for a successful upgrade project.
Read moreAs of May 1st, 2023, Heroku will no longer be supporting the Heroku-18 stack. The reason for this deprecation is to maintain synchronization with the Ubuntu Long Term Support releases. If you are currently running your Rails application on this stack, when you navigate to the Heroku dashboard you will notice a warning to upgrade to either Heroku-20 or Heroku-22 before the end of the Heroku-18 stack life on April 30th, 2023.
While Heroku-18 will not be supported, do not be alarmed or concerned that the apps running on this stack will stop working. Heroku has confirmed that all existing applications will not be interrupted and non-build functionality will still be available. However, to maintain access to security updates, technical support and the ability to perform new builds, an upgrade will be necessary and is highly recommended.
Read moreAt OmbuLabs, one of our specialities is upgrading Ruby on Rails applications through our specialized service called FastRuby.io. In this post, I want to share with you some of the things that I’ve learned while working on my first Rails upgrade client project as a less experienced Rails developer.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.1 to version 7.0.
Read moreIn case you are not familiar with us, FastRuby.io specializes in Ruby and Rails upgrades. Over these past 10 years we have had the opportunity to perform dozens of upgrades for our clients, which has given us all sorts of experiences. A common scenario that we experience is when the upgrade isn’t straightforward and we can’t just upgrade the Ruby or the Rails version directly.
We often find ourselves in a situation where we need to upgrade one or more dependencies before we can actually upgrade Ruby or Rails itself. For instance, if your want to upgrade your app from Rails 5.x to 6.x and the application still uses Paperclip to manage your file attachments, first you’ll need to replace that gem because Paperclip was deprecated in favor of Active Storage after Rails 5.2 was released.
This was the case for one of our clients that has been doing upgrades with us for a few years now. In this article I’m going to share the mishaps found by the team and the strategy that we adopted to migrate their huge volume of attachments over to Active Storage while still keeping Paperclip active until the migration was finished.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.0 to 6.1.
Read moreRuby 3.0 was released on December 25th 2020. We can now enjoy the great new features of this version, such as performance boost (we talked about that in this recent article), ractors for concurrency, fiber schedulers, and type checking.
If you already have an application running in production and want to be able to use such benefits you’ll need to upgrade your Ruby version.
This article will cover the most important aspects that you’ll need to know to get your Ruby application from version 2.7 to 3.0
Read moreWhen upgrading a Rails application, you might find that sometimes functionality is extracted from Rails and moved into a new gem. These gems are called shims, and they will basically allow you to keep using an old functionality, once the core API takes that out. You can also find shims in form of monkey patches. In this case it’s functionality that you develop to make your migration easier.
In this article I will list some of the functionality of past versions of Rails that was extracted into gems.
Read moreHaving a clear idea of how much test coverage your Rails application has is really important. Especially if you are planning to upgrade to a newer version of Rails. A good test suite will tell you if your application is working as it did before the upgrade.
At FastRuby.io, we recommend having at least 80% of your application covered before attempting to upgrade. A number lower than that would require you to make a lot more manual testing to ensure that the application is properly working after the upgrade. If your application doesn’t meet that number, we suggest to first spend some time improving the test suite before starting the upgrade.
In this article, I’ll show you how you can measure your test coverage using SimpleCov.
A quick note before starting: SimpleCov doesn’t work in projects with Ruby 1.8.7
or lower. If that’s your case, you can try rcov.
We recently collaborated with Procore on a Rails upgrade for their Rails application which allows teams in the construction industry to connect their entire business process.
We spoke with Andy Maltun, Procore’s VP of Software Engineering, about the work performed to help them upgrade their app to version 5.1. According to Maltun, Procore’s R&D department is large and complex. While Procore previously had handled their Rails upgrades internally, with so many teams working on the application, it caused a lot of disruption as each team would handle only part of the upgrade. Therefore, Maltun “wanted to take a different approach this time in an effort to centralize the update and minimize the project management overhead and disruption of teams.”
Read moreRails upgrades can be done in many different ways. Depending on the application that you want to upgrade, some ways make more sense than others. There are factors that determine which Rails upgrade strategy is the best for your case, like how big your application is, or how frequently changes are pushed to the master branch. In this article I’ll be covering two common Rails Upgrade strategies so you can decide which one is the best for your application.
Read moreWe all know testing is important. We have our unit tests and integration tests to make sure everything is working as expected. At OmbuLabs, we use Capybara for our integration tests so that we can interact with the app as a real user would.
This is the process we used to replace the capybara-webkit
gem in a legacy project with a more modern approach that uses the webdrivers
gem and a headless browser.
Deprecation warnings are a common thing in our industry. They are warnings that notify us that a specific feature (e.g. a method) will be removed soon (usually in the next minor or major version) and should be replaced with something else. Features are deprecated rather than immediately removed, in order to provide backward compatibility (a solution that works in both the current and the future version), and to give programmers time to implement the code in a way that follows the new standard.
In this guide we’ll show you what the workflow is that we use at FastRuby.io to address deprecation warnings when we upgrade Rails applications.
Read moreWe know that there are many challenges involved in a Rails upgrade project. Depending on how big your application is, how old your Rails version is and how well structured your code is, it can be difficult to perform that job and keep your sanity. If you don’t find a reliable and trustable process to guide you from version X to version Y, you can end-up in a nightmare.
The good news is that here at OmbuLabs, we have been upgrading Rails applications for over 10 years now and this gave us a know-how to define a process that has proven to be very effective. And today I want to share Our Rails Upgrade Process with you.
Read moreTechnology evolves quickly. When you first created your Rails application, it’s likely you did it using the latest version of Rails. As time passes, however, new Rails versions come out and your application becomes more and more out of touch with the latest version. But why is this important? Why does it matter?
There are several different reasons to upgrade your Rails application. In this article, I’ll list what we consider to be the most important ones.
Read moreMigrating from Protected Attributes
to Strong Parameters
in a Rails project can be a huge step of the upgrade process. Especially when we are upgrading a large application. This guide is meant to help you tackle that step faster and with a lot less pain.
As part of our Roadmap service at FastRuby.io, we analyze the test suite of the application we are auditing to give a proper estimate on how long it will take us to upgrade. One of the tools we use for this is SimpleCov.
Often times our clients use parallelization in their continuous integration tools. SimpleCov generates multiple .resultset.json
files for the same codebase. However, our goal is to have a single .resultset.json
for the whole application. In this blog post we are going to show you how we solved the problem.
We recently collaborated with Amitree on a Rails upgrade for their application which “is an AI assistant for email, integrated deeply within Google and Microsoft’s products and is in heavy use by real estate professionals” and were able to speak to them about their experience with OmbuLabs.
Read moreAn outdated Rails application doesn’t happen overnight. In FastRuby.io we work with a lot of clients who have outdated Rails applications and we help them upgrade to a newer Rails version. In this article I share some things that you could start doing to avoid falling out of date.
Read moreEvery time we start a new Rails upgrade project, we need to setup a whole new environment in our local machines. Sometimes that leads us down the rabbit hole which ends up breaking our environment for other client projects.
After years upgrading Rails applications, we learned that the best way to isolate our client projects’ environments is using Docker.
That’s why we decided to use Docker and docker-compose for all of our client projects. This year I had the opportunity to share our process in a series of workshops: Upgrade Rails 101: The Roadmap to Smooth Upgrades
Read moreOver the years we have seen a significant increase in the demand for Ruby on Rails upgrades. That’s why a few years ago we decided to launch FastRuby.io, our Ruby on Rails upgrade service.
When we receive an inquiry via FastRuby.io, the first thing we like to do is schedule a call with the potential client to get more details about their app.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.2 to 6.0.
Read moreWe recently spoke with Ryan Findley, Principal at Neomind Labs. We worked with his team to execute a Rails upgrade from 2.3 to 4.2 on one of their applications.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.1 to 5.2.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.0 to 5.1.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.2 to 5.0.
Read moreWe recently collaborated with Power Home Remodeling on a Rails upgrade for their self-described “monolith CRM/ERP application” and were able to speak to them about their experience with OmbuLabs.
Read moreThis article takes a look at some of the changes to the ActiveRecord::Dirty
module between Rails 5.1 and 5.2.
If you’re running Rails 5.1, you may have already seen some of the deprecation warnings related to the API changes contained in it. Most of them are behavior changes, and there are some new additions as well.
To better understand these modifications, we’ll take a look at sample projects in Rails 5.1 and Rails 5.2.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.1 to 4.2.
Read moreThis article is part of our Upgrade Rails series. To see more of them, click here.
This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.0 to 4.1.
Read moreThis article is part of our Upgrade Rails series. To see more of them, check our article title The Rails Upgrade Series.
A previous post covered some general tips to take into account for this migration. This article will try to go a bit more in depth. We will first go from 3.2 to 4.0, then to 4.1 and finally to 4.2. Depending on the complexity of your app, a Rails upgrade can take anywhere from one week for a single developer, to a few months for two developers.
Read moreThis is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.1 to 3.2.
Read moreThis is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.0 to 3.1. If you are in an older version, you can take a look at our previous article.
Read moreThis article is the first of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 2.3 to 3.0.
Read more