Running multiple sites from the same rails codebase?

Question

I have a client that wants to take their Rails app that has been successful in one niche and apply it to another similar niche. This new instance of the app is going to start out very similar: all the same functionality, different logo and colors. However, if the new site is successful it will inevitably need significant customizations that shouldn't be applied to the original site. At the same time, if bugs are fixed and improvements are made to one app, then both apps should be able to share those improvements.

Can anyone suggest strategies or resources that address this issue? How do I keep changes that apply to both apps from taking significantly longer to test and implement?

Yes, I know the answer involves SCM, plugins, gems, and Rails engines. These tools will and are being used. but I want to know when and how to use these tools towards solving this problem.

Links are also welcome.

---

This question is not the same as:

Multiple websites running on same codebase? In my question, I'm not running the exact same app with different settings.

How do you sync changes between multiple codebases? I'm asking a similar question, but I'm specifically asking about Rails apps.

Answer 1

I know this could be possible using Git Submodules

Answer 2

With minimal touching of the main site, it might be possible to use the Ruby code from it while extending the templates and changing the styles. I have worked on that extensively in Django and the layout can look like:

project/
    sites/
        site_one/
            templates/
            models.py
            settings.py
            urls.py
            views.py
        site_two/
            templates/
            models.py
            settings.py
            urls.py
            views.py
    base_app/
    settings.py

You could try do something similar in Rails:

main_webapp/
    app/
    config/
    ...
    sites/
        site_one/
            controllers/
            models/
            views/
        site_two/
            controllers/
            models/
            views/

Assuming the functionalities are identical across sites but they just have different layout and styles, there will be none or very little model and controller code. Should you wish to add more functionality to specific sites, just stick the code under the desired site folder.

Django also have the concept of Sites and the ability to look for templates in one specific project folder and an app folder. You could try to copy those features and bring them over to Rails to achieve running multiple site from one codebase.

I recognize that you are looking for a Rails solution but you can still checkout how it's done in Django and copy some of the useful features to the other side. If I like a Rails specific feature, I'll port it other to Django/Python.

Answer 3

We currently work with a setup quite similar with what you are describing.

We started developing a somewhat big Rails app (sales, stock management, product catalogue, etc) for a client. After finishing it, there came several new requests for almost identical functionality.

The original app, however, had to keep being maintained, adding new features, correcting bugs and whatnot.

The extended ones needed to maintain most functionality, but change appearance and looks.

What we did was follow a series of steps:

1. First we started cleaning up the code, pulling hardcode references to tables, reducing and optimizing queries, looking up missing indexes and ways to improve our ActiveRecord use
2. After being somewhat satisfied, we started developing missing tests. I can't stress hard enough why it's useful, since we'll be maintaining a same codebase for several apps, and need the core functionality to be as protected as it can be from new changes.
3. That was also the magic word: core functionality. We started selecting base functionality that could be reused, and extrating all generic code. That gave us a mix of controllers, models and views, which we started to change into modules, plugins and gems. What goes where? Depends greatly on your code. As a rule of thumb, functionality that doesn't deal with the domain language goes to plugins (or gems if it doesn't depends too much on Rails)
   4. This approach led us to a several of plugins, gems which we then pulled together reassembling the original project, and then it got to it's own GIT repository. That way, we had a main "template" repository which glued all the components and several other GIT repositories for each of them.
   5. Finally, we develop an easy theme system (basically loading /stylesheets/themes/:theme_name/ and getting theme_name from the DB). Since it's an intranet project, we could almost do anything with proper CSS styling. I'd guess for working with IE you'd need a more complex approach.
   6. Then, we just used that main repository developing the new functionality on top of it.

Now, how do we deal with changes to the core base. We start with our template repository. We fix or define where the fix or change should be and either change it there or on it's corresponding gem/plugin. After properly testing it, we deploy it to our GitHub account.

Finally, we merge/rebase the other projects from that template repository, getting the new updates.

Sounds a bit complicated, but it was only for the setup. The current workflow is quite simple and easy, with the given advantage of working with several developers without bigger issues.

Answer 4

We're doing something similar at my company. Except its currently involving multiple environments (production, test, development). We're using SVN as our SCM to keep our code straight and lets us duplicate the current stable environment and create separate versions of an application (and potentially changing things like the logos or certain functionality). I highly highly recommend running the environment with Apache/Nginx and Phusion's Passenger. This is letting us run all of these applications separately, on the same/similar codebase(s). And that's it. We have to DBs, one Production and one Development to keep our live data separate, but you can easily connect two app instances to the same db this way. Its worked out really well for us so far in being able to develop, test and deploy multiple web applcations without taking down the primary production server.