Legacy Rails Projects?
This post is a question addressed to the Rails folks who read this blog:
In the event that you were asked for help to work on a legacy Rails project from a while back (say, the pre-1.2 days), how would you even begin to find out how to port the thing to a modern version? What are the compelling reasons to do so? I’m not really a Rails or Ruby developer by trade, so basic advice is still appreciated.
If the decision is made to just stay with the legacy version to keep it quick, I guess there’s no real way to get any documentation from a specific version? If so, that seems to be a real drag on maintainability of real-world projects that get built and left alone for a while.
June 10th, 2008 at 10:05 am
Is the app currently on Rails 1.2, or has it not even been upgraded to that yet?
My first suggestion would be to get it to 1.2 if it hadn’t yet been upgraded. This will get you that much closer to rails 2.0 compatibility, and you will then get all of the deprecations in the log during tests and development that will help you catch everything that you will need to fix.
My next suggestion would be to follow one of the deprecation guides out there (that I have bookmarked on a different machine, but just google for it :)) and follow those. I use script/console as my baseline for getting a new version of rails up and running. Once that runs I fire up script/server until I can hit pages till they don’t blow up, and then finally I run tests to get all the corner cases and other oddities that popped up.
It’s a huge pain in the ass when going from an app that was developed on a very old version of rails (0.12) in my case, but that is the price you pay for being such as early adopter. I don’t think it will be nearly as much of an issue going forward as the core team now has a set direction that they are working towards, and the changes are not nearly as frequent, drastic, or knee-jerk as they were in the past.
June 10th, 2008 at 10:06 am
Since it’s pre-1.2, then maybe leaving it as is it a good enough plan for now. If you have the time, take it in stages. If you have 1.2x installed as a gem, update the RAILSGEMVERSION to a 1.2x, and clean up the deprecation warnings. Then move on to the Rails 2 level and work on the warnings again. There are many blog posts out there (some with rake tasks) that will tell you what you need to change to bring it up to date.
For older rails docs, I came across this a while back:
http://delynnberry.com/projects/rails-chm-documentation
It’s in CHM format, but you can find readers for any platform if you’re not on Windows.
Feel free to email me if you have any questions. I’ve done that migration a couple of times now on several apps.
June 10th, 2008 at 11:17 am
Rails Brain (http://www.railsbrain.com/) has some older rails api documentation, but nothing before 1.1.6
June 10th, 2008 at 12:18 pm
Thanks for the recommendations, everyone. The version is definitely pre-1.2. I started fixing some deprecation problems, but some of them weren’t logged when running it on a 2.0 rails gem, I think.
Additionally, there were some plugins installed that basically never got ported to newer versions, so i’m left with the task of swapping them out with current versions or doing the porting work myself.
I’m definitely a little relieved to hear that 1.1-1.2 and 1.2-2.0 seem to be the major changes, and that there won’t be too many other issues.
June 11th, 2008 at 9:46 am
Well the last version of Rails I liked was 0.8, so I’m inclined to see it as a blessing
Also I’d ping Rabble, as he as he’s done some work as a consultant on a couple of legacy Rails app struggling with exactly that question.
June 11th, 2008 at 3:48 pm
First what other people have said is a good start.
What i do is put rails in vendor, put the versions, rails 1.1.4, then 1.2, then 2.x. Use symlinks to move between them, rails will use whatever is in /vendor/rails as it’s libraries. I also do this for gems putting them in /vendor/gems/ This way you’re sure what version you’re getting.
Then i run rake to see how the tests are in the old version. Usually they are half broken. Then you can try out for 2.x and see what changes. The big change between 1.1 and 1.2 is that objects returned from hasandbelongstomany lookups are read only. There are other stuff, but that’s the one which often i run in to problems with.
Other than that, it’s usually just a day or two’s work to upgrade. If it’s well tested then the upgrade goes much faster.
Feel free to ping me with questions. I’ve done this a bunch of times.
June 11th, 2008 at 6:31 pm
Rabble, thanks for the tips.