Rails Deployment Book

I've been mulling over an idea for a book covering Ruby on Rails
application deployment. Obvious topics include using Mongrel by itself
and with Apache/Lighttpd, load balancers, memcached, and Capistrano.

What other topics would you like to see covered in such a book?

Cheers,

Isn't Ezra releasing a book like this soon? You might want to check
out what's covered there and see what's missing.

-- James

Dave... a few thoughts;

Deployment architectures
- logical
- newtork
- hardware
Session management
Performance tuning
Problem solving in production
Disaster recovery (or preparation for!)
Deployment case studies e.g.
- initial deployments
- re-architecture
- scaleing

James

Thank you - I wasn't aware that one was already being authored. Guess
mine will have to be a bit more specialised!

Cheers,

Thank you.

Jamie Buck, Aaron Huslage and Obie Fernandez are preparing also
a book about Capistrano for Addison Wesley :

http://jamis.jamisbuck.org/articles/2006/03/18/got-a-snazzy-capistrano-recipe

  -- Jean-François.

Maybe I am a bit too new to the whole Rails scene (i.e. I am still getting
my feet wet and I haven't looked at Capistrano yet), but Rails appears
to assume too much that you as a Rails developer also own and
control/have access to the target system on which the Rails app will
be installed.

In enterprise software you are often making applications with Web
interfaces that are installed on a corporate network by that companies
staff.

The application in this case needs to be self contained in an OS
installer (MSI, RPM) and be able to update itself, or be updated. You
also need to be able to install dependencies if unavailable (like Ruby
and all the gems you need) and possibly interact with software
firewalls.

Rails seems to totally leave you out in the cold here.

Rails is developed by folks in small teams, so the tools tend to favor
that mindset. I don't think anyone in the core team would be a good
fit to write deployment tools for enterprise railers. These tools
need to be written by the very folks that need them.

@Richard:
Slightly OT

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.

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.

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.

Whoa... topic drift, I'll get my skis...

Rails is successful already, rails will be deployed. Good experiences
are valuable to share as are bad experiences too; a streetmap of what
is around now that works or doesn't is incredibly valuable.

Regarding big business, small business, mindsets and processes it isn't
worth speculating. If people want something bad enough they will build
it and the process and practices and skills will spring up whether the
core team are involved or even care.

In the corner of an almost forgotten bit of my mind I have a
recollection of people in large corporations saying Windows will never
be used in here... there are no process and people to support that
hobbyist toy! There was a time when Linux had no corporate supporters.
History.

Irrespective of how things appear now just watch it change. So if
somebody wants to write a book on making this great framework work in
the places people currently want to deploy it go for it...

After all... tomorrow is another day....

Richard,

A recent post by Jamis discusses just this very thing...

http://jamis.jamisbuck.org/articles/2006/08/30/the-future-of-capistrano

Why not use gems?

Use the fossilize plug in to pack up your rails app and voila

Any corporate sys admin should be able to install that

That .. or a live rails cd :wink:

Link to info on Ezra’s book

http://www.pragmaticprogrammer.com/titles/fr_deploy/index.html

@Richard:
Slightly OT

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.

Brian,
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
even contentious.
Your application requires certain dependencies, so you wrap it all up
in something
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.

Isn't Ezra releasing a book like this soon? You might want to check
out what's covered there and see what's missing.

Here's the link:

http://www.pragmaticprogrammer.com/titles/fr_deploy/index.html

@Richard:

I see… you’re talking about things like Microsoft’s OWA, Sharepoint, things of that nature then.

Not impossible at all… all of the pieces are there. On Windows, it’d be really easy with some simple scripts. Gems can be installed silently, Mongrel runs as a service, MySQL can be manually installed. You may even consider modifying InstantRails to include your application so it’s all a one-click installation. On Linux you could just distribute a package much in the same way.

The thing is, a lot of companies I deal with don’t bother… they want me to use my web server, my database server. When you pay $20,000 for a software package, they often times even come out and help with the installation as part of the price.

Interesting topic though… might warrant further investigation. Just keep in mind that if the need is actually there and enough people have the desire to do something similar, someone will devise a solution. Maybe it’s something you’re interested in organizing or contributing to.