3

I'm embarking with 50 related rails apps that will have minor differences between them - the css may differ and maybe each app will have different routes and different titles for the views for the sake of SEO and so on.

But i want all 50 apps to be consistent when i change other things. So basically i will have to end up with my own cms and each website will have different settings.

I'm sure i'm not the first person to encounter this problem. How would i go about organizing this while using Rails, git, github and heroku so that when i deploy, all apps update and remain consistent but still hold their own settings?

Tom
  • 9,275
  • 25
  • 89
  • 147

3 Answers3

4

I fork a base project and keep it as "upstream". I clone the forked project in my development environment and keep it as "origin". So my development environment has an origin and an upstream.

When I do something that effects all forked projects, I do the change in upstream, then I go into each project, pull from upstream and merge.

You can also have a hierarchy of upstreams and keep them synchronized with the original upstream.

nurettin
  • 11,090
  • 5
  • 65
  • 85
  • i'll need to freshen up my bash scripting skills to automate things using this technique but i think it's the way to go – Tom Dec 15 '12 at 14:41
1

If those are purely configuration files, the best approach is to follow the Heroku page "Configuration and Config Vars":

Don't put those files in a Git repo itself.

Use the Heroku CLI’s config, config:add, config:get and config:remove to manage your config vars

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • i'm afraid it will take more than that @VonC. Think about a case in which i'd want to change, say the routes for a particular view in one app. It would be messy to say the least – Tom Dec 15 '12 at 13:55
0

I'm a huge fan of only having to maintain one project if it's possible. If it's only the (user-controlled) styling of an app you might go with a multi-tenant approach in the basecamp style. Your app would display different endpoints, e.g. differentiated by subdomains, that you could also point different top-level domains to. The variable parts of the app then needs to be stored in the database, such as e.g. the styles, layouts, and whatever user-controlled content you have. One approach is outlined in the answers to this question, though there are definitely more ways.

Community
  • 1
  • 1
Thomas Klemm
  • 10,678
  • 1
  • 51
  • 54
  • I viewed the two railscasts regarding multitenancy but it's flawed in the sense that each app will need it's own ip and quit possibly be hosted on different servers and also maybe in the future be sold to a third party. So this approach will violate my need for encapsulation and "build for detachable models" design. (i should have mentioned all of this in the question!) – Tom Dec 15 '12 at 14:33