Of late, work has been super busy. This is traditional for us; for our bigger customers with e-commerce sites, we have big changes locked down by mid-September, leaving the build up to Christmas for them as one of minor tweaks and changes, dealing with last minute small change requests, development for the new year and occasional capacity issues. Our smaller clients, especially those that aren’t selling directly through the web, then pile up requests to get things done before they break for the year end.
However, January and February tend to be slightly quieter times, with the lull of Christmas leaning over to the constraints of budget until the new financial year. And that tends to leave us a period of time to work on our internal apps and products. Recently, I’ve been looking at one we use it everyday as it fulfils some important internal functions, that are currently in a state of change, so we’re doing a good chunk of development on it. This has caused me to have a closer peek at the software stack that underlies it. It’s old, and not externally facing, which gives me an excellent opportunity to work on that tricky being: seamlessly updating a regularly used application.
This is the first in a series of posts about it – I need to learn what I’ve done right?
What Have I Got?
This old app was written 6 years ago in Rails, and was one of our first forays into the Ruby world. It has a software stack to match: Ruby 1.8.6 and Rails 2.3.4.
Ruby 1.8.6
This hit maintenance support in 2009, and in 2011 ran into its end of life. The current version this writing is 1.9.3.
Rails 2.3
This went into ‘security maintenance’ mode in 2011 as well, although there have been a number of releases since then. The current version is 3.2.
Gems
A surprising number of them given that this is a 2.3 app. Some of the highlights include juggernaut, will_paginate and tmail. All of them have more recent versions (and tmail has been deprecated for Activemail in more recent Rails versions.
Tests
None – not really. There are the automatically generated functional tests and unit tests, but none of these have been customised or edited to reflect changes to the code base since they were first generated in 2008. None of the new functionality has written tests either.
Plan
The most sensible thing to me is to bring everything up to a more supported position security wise first. That means bringing Rails up to the latest 2.3 release, and shifting Ruby to 1.8.7. There are issues around that to consider – MRI Ruby 1.8.7 is being end-of-lifed in June 2013 for example, but it will put us in a better place to think about the much larger migrations – to Rails 3.x and then onwards to Ruby 1.9.
Given that, I’m going to bring Ruby up to scratch first, and then Rails. Along the way, I’m sure to hit problems with Rubygems, considerations about bringing Bundler into the mix to make it more manageable, as well as writing some supporting tests.
After that, we’ll see where we go.