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 
@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
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.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks