Question

I want to break our RoR website into different sections\domain, for the people working on each section can independently release there code.

Think of it as https://www.yahoo.com/

The main website has link to sub-domains

https://finance.yahoo.com/
https://waether.yahoo.com/
https://sports.yahoo.com/

Each team works on it's own section, and does independent releases.

I have tons of common code\configurations, that each section would need. So I'm hoping that I can create a main website that is a template of some sort, and is configurable. Teams that plug in there section when they are ready. And after that can manage their own releasing with need much help from us.

Was it helpful?

Solution

You might want to look into Rails Engines as an alternative to subdomains. Engines let you "mount" one (or more) Rails applications into a main "host" application. This makes it trivial to share code and configuration between the applications, but it does couple things more tightly.

How "separate" do you want things? The subdomain approach lends itself well to decentralization. You can have completely separate infrastructure for each subdomain; only sharing the parts that make sense. Engines provide a half-way option that lets you develop each piece independently, then deploy and manage a single application in production.

If you want to share stuff (code, infrastructure, etc), both options will require careful coordination and testing when it comes to deployment.

OTHER TIPS

Separate sites are generally separate projects. If you have shared infrastructure or configuration you might be able to share that via a private gem, a shared database, or a centralized service of some kind, depending on your needs.

Depending on how big or diverse you expect your various sub-projects to be, it may not make sense to put them all in one place.

I guess I would ask, do my apps actually need to depend on one another? If not, and they're mostly just sharing code/configuration, then that problem has already been solved via shared libraries and databases for config data. I don't see why you would need to manage the project as one thing (especially in terms of source control, etc.) if the separate parts do distinct and separate jobs.

This largely depends on what differences you will see between the various subdomains.

If it is only written content, styles, etc. you may want to consider a CMS solution such as Refinery CMS (http://refinerycms.com) which is open-source and can be customised if you require.

If you are thinking that each subdomain will have different code, tests and deployment schedules then this will quickly become a nightmare. In that case I would suggest you write common code modules for the functionality that is shared between the domains, and then have each subdomain as a separate rails project and app that references the common code.

Edit: Thinking about it further, you will find either initially or over time that the various subdomains will diverge as they have different use cases, business rules and requirements. Putting the shared code into a library or gem that each project can reference will give you the flexibility to create and update the common code separately while leaving each individual domain to implement their own custom logic - imagine if you needed to update your if rules and case logic every time the subdomains had a new requirement

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top