Sorry about not going live over the weekend. I’ve been fighting with some deployment issues in getting things running on our host server. In some sense, this is to be expected, as we’ve never done it before, and there is a whole lot of new technology for us. So, we’ve found some folks with Ruby on Rails experience, and they are going to help us debug whatever we were doing wrong.
What Went Right?
A lot, actually. Ruby on Rails is new enough that there aren’t overwhelming amounts of help available via Google. When I learned perl a couple years ago, it was trivial to make a mistake, search for the error message, learn, and fix it. And that’s true for most of Rails issues – that got me really far. Here’s some of what we did accomplish:
- Got RSA-encrypted ssh access operational to our server at Site5. This protects the site, but allows for “remote control” of our portion of the shared-server environment.
- Got subversion (svn) operational on the server. Protected source prevents us from losing data and allows us to roll back if we make mistakes, or keep working if my dev machine dies, etc.
- We already had Apache and mySQL running on the server at Site5 (to support the blog), and Site5 has Rails already available – we just had to use it.
- Got Capistrano, the deployment technology of choice for Rails applications installed, integrated with subversion, the best source code control repository, on our server. We can deploy the code, make changes, and deploy the changes.
- Got FastCGI operational – the server-side technology that makes the pages render more quickly. FastCGI is what is used at Site5.
- Got RSpec running – the test framework that allows us to write tests of higher level “behaviors” as part of the development process.
All of this cool stuff allowed me to actually hit the deployed site (at least one page of it) on the server, but the site didn’t work.
What Went Wrong?
Only one thing, but it was arcane enough that if other people have had it, they haven’t shared their solutions somewhere that I could find them with Google. And ultimately, they prevented the site from launching.
Rails is designed to have three deployment environments “baked in” to each code base – dev, test, and production. We did all of our dev work in the dev environment. All of the automated tests run automatically against a separate database in a distinct environment. And production has a third environment and database – the differences can be summed up as follows: the production database is on the server, and the production environment avoids some dev overhead (for debugging) and allows for caching (faster performance through re-use of pages and page fragments when supporting multiple users).
- Our Capistrano deployment, for some unknown reason, was running in “dev” mode instead of production mode. That caused one problem – not setting up the production database. And would cause a second problem (slow performance).
What Went Stupid?
You can argue that the time I spent trying to debug without escalating to experienced Ruby on Rails developers for help was 100% stupid. I’ll agree that much of that time was wasted. One thing I did discover is that Site5 was using earlier versions of Ruby and Rails than I had been using on the dev box. Not matching the Ruby version was stupid – and maybe the source of the weird deployment problem. Not matching the Rails version is supposed to be ok (I now know).
As part of the debug process, I tried rolling my dev environment back to a matched environment with Site5, and in the process, broke my development environment. At a minimum, I broke the RSpec test harness. That was stupid.
What is Happening Now?
I’m in the process, after a rational and soothing short break, and a nice cup of tea :), of fixing my local dev environment. Assuming I can do that today or tomorrow, I will spend the rest of the time working on additional testing until…
I am also meeting with some Rails developers tomorrow night who can hopefully set me straight. All of the “deployment documentation” I’ve read has great advice, and lists a few steps as “type X, then type Y.” My problems resolved from “X” not working – which apparently never happens, since no one shows you how to fix it. That makes me believe that I screwed up something simple earlier in the process. Hence the help from the pros.
All told, this still seems to be an exciting technology for developing applications rapidly. The common is very easy to do, and the uncommon seems to be no harder than with other languages.
Will keep you posted.
