I recently picked up a rescue project. It’s pretty gnarly–the application was, I believe, originally written in Rails 2.3 (possibly older), was updated to Rails 3.0 at some point, and sat unattended for most of last year. When major security issues hit Ruby and Rails the past few months, there were concerns that the application would have to be taken offline if action weren’t taken. So I agreed to the work.
Rescue projects are unique challenges. Chances are, you’re working with someone else’s code. (Or maybe you’re working with your own code, but it’s been so long you don’t remember the work or it represents a former self’s skill set.) If a project hasn’t been touched in awhile, you may need to do a lot of infrastructure work before getting to things like new features. In the case of this project, not only was the version of Rails grossly out of date; pretty much every dependency was as well. On top of that, the project was written by a developer who was new to Rails and new to the profession, so there were quality issues. The biggest: No meaningful tests to speak of–and making major infrastructure changes without halfway-decent tests is never fun.
So what I’d like to present here, over time, is a log of the work. Since it’s not my code to share, there won’t be a lot of code samples for you to copy and paste. Instead, I’m going to focus on the thought processes I go through on this project, as I bring it up to code:
My general plan of attack is to get the application up to as current of a release of Rails 3.0 as I can, then build out tests against that. Using those tests, I can then more comfortably update to Rails 3.1, then 3.2. From there I can update Ruby to at least 1.9, if not 2.0, and, finally, get things running in Rails 4.0.
I’m not sure where this journal of the work will head, but honestly, after writing and maintaining a living book heavy with code samples for a year, I’m ready to try something different.
So let’s start with my development setup. The most pressing matter was to get Rails patched. As I mentioned, the project was built on Ruby Enterprise Edition (REE), an optimized version of Ruby 1.8.7. I had to get REE installed on my laptop, but installing pre-1.9 versions of Ruby on Mountain Lion involves a couple of extra steps beyond
rvm install ree.
So in the interest of time, I turned to Vagrant. Using an disk image I already had for Ubuntu 10.04, I created a Vagrant virtual machine and spun it up. A couple of minutes later, I had REE installed on that virtual machine and was able to bring Rails up to the final 3.0 release. Since security patches are still being back-ported to the Rails repository on GitHub, I can grab them by updating the
gem 'rails', :git => "git://github.com/rails/rails.git", :branch => "3-0-stable"
This isn’t an ideal long-term solution, but it will take care of the immediate security issues while I work on other issues.
With Rails patched, I turned my attention to the other dependencies listed in the Gemfile. Did any of them have security patches to apply? This took some research. Given that the version of Rails was so out of date, some of the gems required by the application no longer supported the outdated version of Rails–or, if they do, only do so with a specific older version. Take Devise, for example. Jumping across major releases for any library is foolhardy, but for something like Devise, it’s nearly impossible to do without major headaches. Instead, I told Bundler to stick to a specific version, at least until specs can be added to test against when integrating future versions:
gem 'devise', '~> 1.3.4'
In some cases, loading a gem from a specific branch on GitHub is necessary, as I showed with the Rails example. Again, not ideal, but it keeps the project moving forward. (As an aside, if you’re relying on source from a Git repository and you’re not absolutely certain that repo’s going to stick around for the long haul, you might consider forking it first and pointing to that fork in your Gemfile.)
I wasn’t as familiar with other dependencies, so in some cases I left them at their current versions until I could get a better understanding. And since the project doesn’t yet have any tests, I had to work with a dump of the production database for a local spot-check. This isn’t a good practice, and I don’t condone it as a regular means of testing! However, given the time crunch and lack of other tests, this had to do.
The project was luckily already set up to deploy with Capistrano–I was worried I’d have to set that up as well–so in a minute or so everything was patched on the server and I could begin tackling other issues in the project.
In the next post of this series, I’ll start writing tests against the current code base in order to get a better understanding of it, and to use as a development tool as I apply changes to the software itself.
I stand with the Black community against systemic racism, police violence and brutality, intolerance, and hate in the United States and worldwide. We must all demand better from our leaders, and ourselves. Stop tolerating intolerance.
While you're here, please consider making a donation to Black Girls CODE, who do great, important work to provide opportunity to underprivileged girls interested in tech, or any organization working toward equity and safety for all, not just the privileged. Thank you.
If you liked my series on practical advice for adding reliable tests to your Rails apps, check out the expanded ebook version. Lots of additional, exclusive content and a complete sample Rails application.
Ruby on Rails news and tips, and other ideas and surprises from Aaron at Everyday Rails. Delivered to your inbox on no particular set schedule.