How to Reduce The Cost of Upgrading Rails with FastRuby.io
In the first article of this series, we discussed How Much Does It Cost to Upgrade Rails based on our historical data working on over 100 upgrade projects. In this article we’ll discuss how to minimize the cost once you’ve decided to move forward on an upgrade so your team can continue to focus on valuable product feature or roadmap work.
Working with our team of experts to upgrade your Rails application allows you to stay compliant and take advantage of the benefits and security updates of a supported version, while also letting your team focus on revenue-generating initiatives. Still, it can be a significant investment, especially, as we covered in the previous post, if your project requires a high level of manual QA, for example.
There are, however, ways to reduce the time (and therefore cost) it takes to upgrade your Rails application when working with an external team. In this article, we’ll cover a few different strategies. Does it mean you can’t upgrade unless you do all of this? No, it doesn’t. Being an Agile team allows us to adapt to your process and workflow and work with any team to get the upgrade done. However, employing at least one of these strategies can make your upgrade more cost-effective.
Paperwork and Accesses
Make sure all the paperwork has been sorted and all accesses are in place for the FastRuby.io team by your kick-off date. Lack of access to necessary tools (codebase, CI) will cause the work to be delayed and will generate idle time in the project. Having everything ready ensures everyone can hit the ground running on day one and start making progress.
It is imperative to make sure that everyone who will be working on the project has access to all of the possible tools, and repositories that they will need to move forward with the project. An common example of a team getting blocked is having access to the main repository but not having access to upgrade any custom gems that the application may depend on.
It is also important that everyone working on the project has the same access. We have seen many situations where access was granted on a case-by-case basis, and then it became difficult for one or more members of the team to work on upgrading something, and they would instead need to rely on the one teammate who had received access.
Local Set Up
The easier your app is to set up and the better the setup documentation, the quicker the team can get up and running. Some applications are quite complex, and that’s fine. As long as the documentation is comprehensive, setup can be completed quickly.
In case there is no documentation, or the documentation isn’t comprehensive, it is a good idea to either spend some time improving it in preparation for kick-off, or to prepare to have a team member available to help with setup questions.
There will likely be questions related to set up anyway, but the more the team can rely on documentation, the less they need your team member’s time.
If any specific requirements apply to equipment or software, it is best to let us know as early as possible, so we can be ready to set up the project on day one.
Team Support
Project complexity and availability of engineers for context questions are additional factors that can impact an upgrade. As we work, we will need at least one engineer to be able to answer questions and provide context. As much as the upgrade work can be parallelized to allow your team to focus on your business goals, there will always be reviews required before merging.
There might also be strategic decisions required as part of the upgrade or questions to answer related to the code itself. This kind of communication ensures more assertive pull requests related to the upgrade and helps avoid rework. Timely reviews also ensure the project keeps moving smoothly and prevents blockers and delays.
When we do an upgrade, we always prioritize backwards compatible changes first, for example. To ensure a continuous stream of work, we ship work in small pull requests that make review easier. If your team is prepared to review those in a timely manner and keep the flow moving as we progress through the upgrade, it will go much faster than trying to merge everything all at once. Letting these pull requests pile up will also cause delays due to blockers and conflicts arising.
Having someone who really knows the project and can provide helpful context about the codebase and business decisions that are not reflected in documentation or easily deducible is also helpful in speeding up the process. You don’t need to have a member of your team dedicated to the upgrade full-time, the whole point of upgrading with a vendor is that you can continue to focus on business priorities. However, setting aside a portion of their time to support the upgrade effort by providing information and answering questions will go a long way in making it faster.
Code Coverage and QA
As shown in the How Much Does it Cost to Upgrade Rails post, code coverage impacts the duration and, thus, the cost of an upgrade. Typically, projects with code coverage above 80% are a lot faster to upgrade than projects with much lower coverage. The more the team can rely on the test suite to perform the upgrade work, the faster the process will be.
This does not mean the only way to reduce the upgrade cost is by increasing your code coverage or that you must have a minimum amount of coverage before upgrading. If you’d like to upgrade your Rails application and the coverage is low, there are ways to avoid a lot of back-and-forth and potential production issues. We have written 10 Strategies for Upgrading Ruby or Rails Applications with Low Test Coverage .
The best way to reduce the cost of the upgrade when upgrading with an external team if your coverage is low is to be prepared to have a dedicated staging environment and QA analyst \ engineer to the project.
An external team does not have the same degree of business context your team has, and it’s not efficient to train an external team on complete context. Instead, it’s best to work with a dedicated QA person who can quickly QA pull requests and provide detailed feedback.
As an added bonus, staging environments that are closely related to your production environment help to reduce time and reduce possibility of having to rollback changes that made it to production. This is especially important for larger, more complex applications.
Waiting on QA is one of the most common blockers in upgrade projects, especially on pull requests that block other work. Having a dedicated QA person will ensure things move faster.
Adding More People to the Project
This is a very tricky one. A bigger team won’t always speed up an upgrade. In fact, it can actually delay it or cause a lot of idle time, depending on the project. When we analyzed the cost of upgrading, we used as a baseline two engineers working 60 combined hours per week. That is the smallest team possible to ensure enough communication, internal reviews, pairing when blocked and a quality deliverable.
So, how does having three or more engineers working on the project impact the timeline and, thus, the cost?
It depends on the size and complexity of the project. If the project is big and/or complex enough that three (or more) people can easily work in parallel on the upgrade tasks, then it is a good idea. Although the relationship is non-linear (a four-people team won’t necessarily deliver the upgrade in half as much time as a two-people team), there is a significant decrease in the timeline. This means you’ll use more hours each week and burn through the budget faster, but you’ll also get the upgrade done faster.
It is important to reiterate this isn’t a guaranteed solution, and in some cases, it’s better not to do it. More people on a team means more communication overhead and more potential for miscommunication and blockers. If the project isn’t big enough to accommodate three (or more) people working in parallel, you’ll end up with at least one engineer idle for significant periods of time. This means you’ll end up with roughly the same timeline for the upgrade as you would have for a smaller team, but for a much larger cost.
Therefore, it’s vital to evaluate what the ideal team size is and choose between the best available options without going too big or too small.
Conclusion
Upgrading Rails, be it in-house or with a vendor, can seem like a costly project at first. But there are ways to bring the cost down when working with a vendor by properly preparing for the upgrade and having the right people and the right resources available. Cutting down on waste (in the form of rework, idle time, duplicate work, blockers) can significantly speed up the upgrade process and, therefore, reduce the total cost.
Interested in getting an in-depth analysis customized to your application and understanding what it’ll take to upgrade your Rails app? Send us a message !