views:

240

answers:

3

UPDATE: It looks like DHH and the Rails Core team finally have a productization itch to scratch as it were. I'll keep this question up-to-date as and when I get to grips with the new options. It's all in a state of flux at the moment.

I'd like to install a Rails app, My$uperWeb$olutionTM, on multiple servers for multiple clients.

At the very least, each client is going to have different API keys, urls, logos etc. That's fairly easy.

They may also want custom layouts and views, and in some cases, custom functionality (models and controllers).

What's the best way of acheiving this but keeping the ability to push updates and bug-fixes to all installations as simple as possible?

As I see it the options are:

What's the best way and why?

+4  A: 

We went along with a solution implemented with Capistrano. Each installation is a different "stage" packaged with appropriate configuration files, images, API keys etc.

Read about Capistrano and Multistaging on Jamis Buck's weblog.

Nicolai Reuschling
+1  A: 

I have recently worked on a system that was in a similar vein - we used Git to create a master branch of development which constituted the core of the app, and had with each installation as a branch off the master.

I wrote a rake task to automate the merging of new features in the master to all of the branches, and we created a rake task that could deploy all installations in one go.

In our case, we were able to develop the core, customise each installation and deploy / update all 20 sites efficiently.

Mr. Matt
You wouldn't want to share those rake scripts here, would you? :)
Dave Nolan
+1  A: 

I wrote an application for realtors that hosted all of their data on a centralized server and then used PHP to make RESTful requests for the data. I did all of this in Rails 0.9.4. It hurt.

If I was rewriting it today, I would use all of the new 2.x RESTful goodies built in with the same architecture. I would use ActiveResource and create client libraries to go on client servers that access the central server where the primary business logic is. This way the customer will not have access to the valuable code or even more valuable data. One down side to this architecture is that it requires a caching on the client side.

Sixty4Bit
Yup I can imagine that hurt plenty :)
Dave Nolan