If a company is going to use Rails then they are going to invest in the
infrastructure to deploy Rails applications which means they will install
Ruby and dependencies. Specific gems and versions of Rails can be packaged
(frozen) with the application.
I probably wasn't fully clear about what I meant. I am talking precisely about
situations where a company manufactures software for general consumption,
or for a specific company, and the technology that it is implemented in is
practically invisible to the target consumer.
-its got a web interface
-you install it on a server
Its highly desirable in these cases to minimally impact the user during setup,
and quietly sort out the application dependencies. It may ultimately be a
.NET, Java or Rails app, but the user just clicks through the install
of the CLR,
JRE or Ruby Interpreter and other binaries.
Applications can be distributed as GEMs or (much better in my opinion)
distributed into production by automated builds from a version control
system. Automatied processes are better because they're less prone to error.
I am talking about scenarios where the comsumer of the software doesn't
have access to your source. You also don't want the customers first
exposure to Ruby Gems to be in your install procedure.
The point is that in order for Rails to succeed, the PEOPLE and PROCESSES
have to change. It's not Rails' fault that an organization has certain
requirements on deployment. Rails can work very well in the enterprise and
deployment is very easy once you lay the groundwork.
You shouldn't have to boil the ocean. I don't see why customers should shoulder
the effort of getting our product to work, if we write it in Rails.
But mostly I am trying to figure out why this is difficult to do or
Your application requires certain dependencies, so you wrap it all up
that conveniently deploys them.
Sure, deploying to the web requires specialist knowledge, and that kind of
handholding is a nuisance there.
My intended use of Rails (to make management software) is pretty
remote from its original intended use. But I don't think it is
incompatible. There would be a higher
proportion of pure Ruby code than a 'classic' Rails app for example,
but the performance
requirements are much lower.
But I need to get around this deployment hump. Good guidelines for doing this
would really help: how to package your Rails app in a single setup
(like a shrinkwrap
or downloadable app) and how to update the setup would be good ideas for a
Rails deployment book.