posts by tag

We got a new production server for Rails apps at work. In its early life, it’s running Ubuntu and Apache (no mongrels yet, but fcgi instead). But the issue, here, is with Apache. Sort of.

In a recent deployment, I noticed that the image uploads quit working. So I glanced through the logs, and noticed that it was going from new straight to index, essentially neglecting create. Rather than POSTing to /files, it was GETting /files. I wasn’t sure what was going on. After all, it worked fine in development. (can’t keep track of how many times I’ve said that)

Then I remembered something: the action in the form (/files) matches the database table name, which attachment_fu then uses as the public directory to store the files in. So Apache was seeing /files and was trying to show that directory, in which Rails was then catching and routing to the index action. So, what now?

Well, it turns out that /files/ works just fine, whereas /files does not (notice the trailing slash). Some people say this is the fix:

# application.rb
def default_url_options(options)
  { :trailing_slash => true }
end

But that didn’t work for me. Maybe default_url_options only gets called on url_for, and not named routes? Or maybe it’s because I use files_path instead of files_url? Whatever the reason, setting the :trailing_slash option didn’t work for me. I could only get this to work in production by ignoring the named route (ugh) and using :url => '/files/' instead.

Anyway, you’ve been warned.

I started a post on this a couple of days ago, but haven’t had a chance to finish it. After reading Chris’ Deployment woes on the slate blog, I figured I’d go ahead and post a few of my thoughts on deployment.

I’ve spent the last couple of years working in web development and I’ve loved (nearly) every bit of it. But there is a part of this field that I don’t like very much: moving an application into production. Typically, I end up in one of these three scenarios:

1. successful deployment on the first attempt—in fantasy land, maybe
2. unsuccessful deployment and knowing what the problem is—this is usually where I end up, where I’ve forgotten to do something, or incompatible versions exist, or whatever
3. unsuccessful deployment and not knowing what the problem is—this is what I fear and despise, and is the very reason for my pessimistic outlook on deployment

In the first case, life isn’t too bad. Still, whether it’s 10 seconds or 10 minutes, it’s always stressful waiting to see if the application is still alive after deployment. What a relief when everything goes smoothly.

In the second case, it’s somewhat comforting to have an immediate idea as to what the problem might be; but at that point I’m working in light speed trying to fix whatever is wrong. Annoyingly, I always make quick decisions which usually have consequences. But nonetheless, this case is just a matter of time until you crank through the things you’ve realized were wrong.

The third case is flat out sickening. I love problem solving, but that’s different. I get chills just thinking about number three. I’ve been in that situation more than I’d like, even with my own site. That type of troubleshooting is terrible. As soon as I resort to Google, I’m in a state of desperation. And of course, a lot of what works for other people never seems to work for me.

The other day I had about 2 hours worth of troubleshooting a live application after deploying (it could have been worse, I guess). Looking back, I don’t know why it took me that long to fix. Maybe it relates to how disoriented and frantic I get when trying to fix something in production. Unfortunately for me, I’ve yet to come up with a consistently smooth method of deployment. Capistrano looks ideal, but when I tried it the second time a few months ago, I couldn’t get everything working properly, so quit on it. The bottom line: deployment is by far the worst part of web development.