Hello, Ruby Wednesday
June 27, 2012 9:55 AM   Subscribe

Imagine I'm a transplant from 1950 who only has the vaguest idea of how the internet works. Now explain to me how to migrate a Ruby on Rails website from one server to another.

The people I work for are looking to move their old corporate site, which was initially developed in Ruby on Rails on a Linux box, to a shared hosting system on Bluehost. This is both so we can stop dealing with the vendor that originally developed the site, who is pretty much the most unhelpful vendor ever, and also so we have a greater level of control over things like MX/SPF records. The site seems pretty simple on the front-end - it's a pretty basic CMS.

I do mostly front-end web development work for these folks. This means that I am excellent at HTML and CSS, and I have enough knowledge of JS, PHP, and MySQL to customize Wordpress to our needs. I don't, however, know the first thing about Ruby, or Ruby app development/deployment.

I have a zip file of everything from the old site, including the SQL file, something called a "Rakefile" with no extension, and lots of .rb files I don't understand. Instead of HTML files, there seem to be a whole host of RHTML files.

I have SSH and FTP access to the Bluehost servers. I've read Bluehost's documentation on RoR, these hints on Bluehost setup, as well as these two posts on Rails migration, and I still have no idea where to begin.

The issue is, I think, that they're addressing people who've already built an application in Rails. I don't know how to hook up the database on the back-end, or how to start the application, or...well, anything.

I'm not above teaching myself Rails (I've seen these old AskMe posts) if necessary, and would in fact relish the additional tool in my toolbox. However, teaching myself an entire language just to migrate a website isn't what I would consider the most efficient way of going about it.

Does anyone have a handy guide to:
1. How Rails works and how its components interact with each other (What's a Rakefile? How does the DB get hooked up if it doesn't specify SQL authentificaton info?)
2. The theory/mechanics of what I'm doing when I'm moving the website? I obviously can't just throw the whole folder online and have it automatically work, right? What else is needed?
3. How to actually do it, in practical terms?

My job doesn't really depend on this, but it would go a long way to ease my anxieties. Thanks in advance, everyone.
posted by Phire to Computers & Internet (5 answers total) 2 users marked this as a favorite
Best answer: UNless you just want to spend 20-40 hours figuring it out yourself, just hire a Rails developer to migrate the site and be done with it. Odds are it won't take more than a couple of hours. Somebody here in MeFi can certainly handle it. Post it to jobs. Then teach yourself Rails maintaining the site.
posted by COD at 10:23 AM on June 27, 2012 [5 favorites]

Best answer: It actually wouldn't be an outrageous idea to go through a tutorial and set up a toy Rails app to get some of the ideas -- part of the point of Rails is that it makes the easy really, really easy and it's dominated by conventions that make it relatively easy to know where to look for things. You could do this in a couple of hours.

Rakefiles are sort of like Makefiles -- they define lists of tasks and are invoked with the 'rake' command. You configure your database in config/database.yml, and then say 'rake db:migrate' and pouf -- your db exists with the up-to-date schema. Then manually with mysql or psql or whatever import the data.

If you have the right version of all the ruby gems (and if you're lucky, the gems your app depends on were 'frozen' into the vendor directory before your zip file was made) then, yeah, once you set up the db, you have a shot at it just running. (But the real world usually isn't that simple.)

Note that the Rails world is all-too-comfortable with backwards-incompatibility and Rails 2 apps can be expected to break in Rails 3. If you're lucky, your app specifies the exact version of things it depends on. If you're not lucky, you're in for some pain there.
posted by Zed at 10:29 AM on June 27, 2012

Best answer: Ohh boy, you're asking for a lot here.

/app is where the webapp code goes. If your familiar with the MVC paradigm then /app/controlers, /app/models, and /app/views makes sense. There's also now /app/assets for stuff like JS and CSS that has bits of Ruby code in it and needs to be "compiled".

/lib is where non webapp code, yet still app code, goes. For example, I've but in here code to clear out sessions and code to extend the system's net-ldap module. It's used by the webapp but not part of the webapp logic directly, if that makes sense.

/config is where config goes (duh). You should have a /config/database.yml that tells the RoR app how to connect to the database.

/Gemfile lists the apps external dependencies
/Rakefile sets up tasks that run from the CLI. Like, create the database schema and upgrade/populate it.

Ruby on Rails apps don't run in the webserver (Apache I'm assuming) like most apps you're familiar with. They're not PHP or Perl or CGI. What almost everyone does is run a seperate, Ruby based webserver through Mongrel or Unicorn on an internal port ( for example). Then configure the frontend webserver (Apache) to proxy all requests for Rails stuff to the backend server. Static files like JS and CSS are mapped into the Apache space and served directly by the frontend. This is very much like common configurations for Tomcat and Java Servlet containers.

All in all, if you got lost then I think you need to hire someone to help you move this to a new service. It's much more complicated than a collection of PHP files or Perl scripts.
posted by sbutler at 10:30 AM on June 27, 2012

Best answer: As a ruby hacker...

This is not something that somebody can write an idiot-proof guide for. RoR is, as a platform, infinitely more flexible than Wordpress, and ruby hackers fucking love exploiting that flexibility. The database will need to be migrated, and migrated correctly in order to function. Dependencies and infrastructure services will need to be migrated.

Because of this flexibility, I can't tell you what needs to be migrated. I mean, it probably needs the SQL database schema replicated across, the data repopulated, the HTTP server strategy migrated (with mongrel and nginx or whatever half-ass server they're using) or a new rack stack built, the ruby environment replicated, and the application code copied over. But, he could have chosen to use redis instead of SQL. Or he could be running in JRuby even, making the whole process totally different.

You say you don't want to learn an entire language just to migrate a website. But, in the world of rails, that's pretty much necessary. We rubyists prefer to write *everything* in ruby. So, that Rakefile? That's ruby. The .ru (rackup) script? That's ruby. Config files? Probably ruby, but maybe YAML instead. And all of it is specialized into domain-specific languages. So, it'll share ruby syntax and semantics, but will have a whole bunch of pseudo-keywords defined by the tool in question (rake, for instance). This is the cat's pajamas if you're a ruby hacker. This is not so friendly if you don't want to learn the language.

Even worse, depending on how much of a circlejerker the previous dev was, you may have to learn the language at a *deep level* in order to successfully diagnose errors arising from unfulfilled conditions in the new environment. This is because many rubyists are more in love with writing elegant "magic" than they are with writing readable code.

Bugs can and will present themselves during migrations.

You need to hire a professional. Somebody who knows what they're doing should be able to achieve this in a couple of days for a few hundred dollars. It's an easy job if you know enough to easily diagnose problems. It's going to be virtual hell if you have to google every error.
posted by Netzapper at 10:46 AM on June 27, 2012 [2 favorites]

Response by poster: Hrm, I was afraid of something like that. I doubt I'll be able to convince the bosspeople to shell out money to hire a contractor... Think I'll just pitch to speed up launching the new site in lieu of moving the old one.

Thanks for taking the time to explain the reasoning to me, everyone. And thanks for all the linked resources!
posted by Phire at 1:18 PM on June 27, 2012

« Older I Still Love You, California! Goodnight!   |   Ice cube trays Newer »
This thread is closed to new comments.