I have a rather large application in rails 2.3.6 (about 40 controllers
and 20 plugins) with a working version in 2.3.11
I am planing to upgrade to rails 3 and at the same time upgrading to
html5, css3 and to jquery
My question is the following
Should I try to upgrade the existing application as described in e.g
the book Raisl 3 upgrade handbook, rafactoring all of it ??
Or should I Generate a new Rails 3 application copying the code action
for action method for method from the old application at the same time
as I am refactoring the copied parts ???
Any-one that had the same problem ?
Any experiencies of these approaches ?
Which one should I use, considering that I have not implemented any
tests ? (Will do that at the same time)
First I assume you are using a source control system (git for
example). If not then start with that.
Then I suggest writing tests before making any changes, otherwise you
will not be confident all is working. Then upgrade to rails 3 only
changing what needs to be changed to make it work (ie passing tests).
Then proceed with enhancements and re-factoring.
I will follow them
However, I am thinking of limiting myself mostly to functional test
(testing controllers).
Is that ok ?
Your suggestions with source control an testdriven development implies
that I should make a new rails 3 application copying source from my
old application needed for each test then refactoring and enhancing
the code.
Is that correct or should I still try to upgrade the whole
application.
I will follow them
However, I am thinking of limiting myself mostly to functional test
(testing controllers).
Is that ok ?
You should certainly have unit tests for any logic in the models.
Your suggestions with source control an testdriven development implies
that I should make a new rails 3 application copying source from my
old application needed for each test then refactoring and enhancing
the code.
Is that correct or should I still try to upgrade the whole
application.
That is not what I meant, I would just upgrade in place after getting
all the tests working. Initially it may not run at all so fix it a
bit at a time, committing to the VCS after every improvement, then
keep going till it passes all the tests. A key point about a VCS in
this situation is that if you realise later that one of the 'fixes'
was actually a mistake then it is easy to determine exactly what you
changed and change it back again. I would suggest initially you only
do what is necessary to get it working on Rails 3 and pass all the
tests before starting any refactoring, rather than mix up refactoring
and upgrading.
I upgraded an app from rails 1.2.3 to rails 3. First, I installed RVM
with both Rails versions (gemset: rails1.2.3 and rails3.0.0), I
created a new Rails 3 app from scratch and I was adding the
controllers (helpers, views, etc) one by one. It was a lot of work but
I was sure that all things were working OK.
When you do that, you can refactor/update/remove....etc and you'll be
sure you didn't touch the working app. And you need some source
control system (svn or git are OK), just in case you do something
wrong.
Exequiel.
That was also my approach but Colin seems to prefer the other
approach.
Maybe its a question about control. I think your approach gives more
control to the uppgrading process than Colins
If anything goes wrong using Colins approach then it could be the old
code but also the combination of an old rails 2 structure and
configuration and rails 3.
A drawback with your approach is that there are many depedents between
models and controllers in my application and
these could be hard to manage in a syepwise process. Exequiel, did you
have any problems with that ???
In addition my controller does not follow the proposed structure that
is generated in a rails 3 scaffold with respond_to do |format|, which
will be corrected with Exequiel's approach
Maybe a good compromise would be to follow Colins advices about source
control system
and a testdriven approach but then uppgrading it stepwise as propsoed
by Exequiel???
I do not understand what you are saying here. There are generally not
great changes required to upgrade to Rails 3, most of the Rails 2 code
is still supported. What has the structure used by Rails 3 scaffold
got to do with upgrading your app to Rails 3?
Actually I didn't have many problems with Rails (if a remember well),
just with some methods, like link_to, response_to, etc and many
warnings, they were catched doing tests. The files into config
directory are very different between RoR v1.2.3 and v3.0.0, it was
using fastcgi and the pagination was removed from the core. I had more
problems with javascripts because the prototype.js changed and the app
had many dependencies with that (in helpers, views) and it was hard to
test them. I think you will be alright, because the code should be
supported and you have to monitor the log entries looking for errors
and warnings.
Colin
I thought that the conguration filés and environment filés were
different
But that may not be the case or New filés may be generated
In addition the controls templates for rails 3 and later rails 2
version use
respons to and I do not use that but that is another problem and
respons to may not be needed
If these problems are no real problem it may be simpler to upgrade the
whole application as
Sudgested by you
That's great. I also prepare my app for migration from 2.3.9 to 3
I started to cover all controllers with Rspec(and do a little
refactoring). Then I'll cover all models. And only then I'll generate
new Rails 3 app, copy my specs, and start to copy the code from old
app to make specs pass. That's my plan
I have recently completed an upgrade of 3 applications (with 2 more to
go) with more than a dozen plugins from Rails 2.3.5 to Rails 3.0.6.
My process was to do not only upgrade each app but to convert each
plugin into a rails engine-gem.
I made a Rails3 branch of each of our repo's.
For each app and plugin I ran: rails new .
Where conflicts exist I either merged the changes manually - in some
cases like environment.rb you may have things going in 2 or 3
different places. I started with the engines which are lowest on the
build order and moved up until I had the applications running.
We are also upgrading to rspec 2.5, with upgrades to shoulda and
factory_girl - rspec is SO different that we have are still working
through the upgrades to get all the testing working again. We chose
to get the applications working again first just to verify our
approach and engine design and well for a bit we couldnt even run rake
tasks.
In our case - to make matters more complicated - many of our engines
have models and migrations - and we have a separate schema namespace
for each engine - this required alot of custom extensions to the
PostgreSQLAdapters and other ActiveRecord classes - these had some
fixes and as well the rspec.rake tasks and others had to be
rewritten.
