One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to.
For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code.
On an unrelated note, having the Heroku service around for low-traffic side projects or whatever is just plain awesome.
Don't get me wrong -- passenger is great. But it's not set up by default (or even possible to set up often) on most shared hosts. Heroku is cool, but as a freelance developer I've found that it's best for me to not take any responsibility whatsoever for the hosting side of things -- just leads to the most un-fun kind of responsibility down the road.
Also, we're mostly programmers here, but there are a vast number of websites created by designers who have very limited understanding of programming and hosting setups, and all they know is shared hosting, copying files via ftp, and setting up wordpress (and maybe creating a database in phpMyAdmin).
Lots of PHP folks call that a disadvantage... It's nice knowing I can mess with files and after pressing F5 I'll always have the latest version. Yes, ok, caches can get out of sync, but they're easy to clear. There are furthermore no good PHP deployment automations, things Rails and Python have because of the level of complexity.
You claim that deployment automations for Rails and Python exist because of the complexity? Have you ever worked with PHP apps that are larger than 1 single file and use the database? Things like Capistrano do a lot of things that even PHP would benefit from.
Deployments are rarely atomic actions. With Capistrano, apps are stored in versioned release directories. Apache points to a 'current' symlink which points to the latest release directory. Upon deployment, Capistrano creates a new app directory, runs database migrations or updates configurations or creates asset files or whatever is necessary to upgrade the app. Only after it's done will it update the 'current' symlink and instruct the app server to restart.
Consider what happens if you upload your new PHP app with FTP. If someone visits /some_page.php while you're uploading then he could access an old version of it. Suppose some_page.php depends on common_library.php which may have been updated to the latest version in the mean time. Then things blow up because the new common_library.php is not compatible with the old some_page.php. With Capistrano, the deployment is as good as atomic.
Capistrano also supports deploying to multiple servers at the same time, and even to servers that are behind a firewall and can only be accessed through a gateway server. It supports rolling back to a previous version. And much more.
I had never used capistrano before, and still managed to get it working for a node.js project, which also involved Mono, c#, several monit scripts, etc. My config file is pretty big, and the documentation wasn't awesome, but at least it's working. If you want automated deployment, it's definitely worth the effort.
> One of the interesting things about doing Passenger deployments for Rails is that it's very similar to doing PHP deploys, with the added benefit of the server not reloading any application code until you tell it to.
You can get this with PHP's APC opcode caching with file_stat turned off. You deploy and when you're ready you clear the opcode cache.
Or if you want to deploy and clear, then add that to your deploy script. Done.
For example: you can update the Rails code on the server, maybe run some data migrations or last-minute production tasks against the new codebase, and THEN tell Passenger to reload the application code.
On an unrelated note, having the Heroku service around for low-traffic side projects or whatever is just plain awesome.