Rails and J2EE Deployment

Hongli Lai asks why some think Rails deployment is difficult. First, a disclaimer. I am not a Ruby on Rails expert. I have only used Rails for one small production project. I found both Ruby and Rails quite easy to pick up coming from a J2EE background. What can be done with such a small investment in learning and in time writing code is quite amazing. However, I, like others, found deployment to be surprisingly inconsistent with the rest of the Ruby on Rails experience.

First let me begin by adding some detail to Hongli Lai's description of deploying a J2EE app. A WAR is just a ZIP file of your application's directory structure that ends in ".war". You don't need to create a WAR to deploy J2EE apps, you can also just upload files to the server like PHP. Depending on what framework(s) you use (Struts, Spring, Faces, etc) you may need to edit XML configuration files. Stock JSP, like PHP, doesn't require any configuration files.

The trouble I have had with deploying Rails is the difficulty of ensuring the same gems are installed on the deployment machine as on the development machine. In my view, the confusing issue is that gems by default seem to install system-wide or user-wide unless you configure your Rails apps to look in a specific directory. This is in comparison to J2EE where libraries are by convention usually all in your application's directory structure (/WEB-INF/libs) so you can just zip up the directory and give it to an installation of Tomcat (or any J2EE application server) and it will just work.

I never understand why with the strong emphasis on convention in the Rails development model, why the deployment process includes system administration tasks like gem installation. Why isn't it convention that gems and Rails are all installed in a place inside the application's directory structure so as to be independent of whatever versions the rest of the system has installed? The Ruby on Rails deployment model seems to default to assuming the developer has superuser control of the deployment machine. However, this is often not the case both in corporate environments and shared hosting environments.