0

I have a Rails app that I'm going to start putting on different servers. Each server the codebase will be slightly different (Logo change, small feature changes, etc). I'm working off of one github repo and was wondering what the best way to manage this is.

My initial thought process was to create a github account for each app instance so I can maintain different instances off the app. So for instance have a github account for server1/instance1 and another for server2/instance2.

My other thought process was to clone the current codebase, push it to a new github account, and rename it, and add the proper git remote credentials and ssh keys to push/pull properly.

Basically I'm trying to maintain the same app on multiple servers but with small changes to each app instance (again, Logo, small feature changes, etc).

What is the best way to manage something like this?

If my question is not clear, please let me know and I'll be happy to explain.

nulltek
  • 3,247
  • 9
  • 44
  • 94

1 Answers1

2

Let's say two of your servers are for "instance1" and "instance2."

This might be more of an architecture problem than a Git problem. Would it be possible to use the exact same codebase for each instance, and abstract away the differences? It would be very easy to maintain if you had, say, a shared CSS file for all instances, then loaded instance1.css or instance2.css based on whether your app is instance1 or instance2. Same for logos—just load /path/to/logo1 or /path/to/logo2 depending on whether the config file says you're on instance1 or instance2. It's a lot more work at first, but would be a lot less work to maintain in the long run.

I'm not entirely sure if that would be possible with your architecture, but if it is, it would be very easy to complement with Git if 100% of the differences between app instances were maintained in a single settings file. Instead of separate repos or separate accounts, maybe you could use Git branches:

  • The master branch would contain the latest version of the shared code
  • The instance1 and instance2 branches would only differ from each other in that the config files says "this is instance1" or "this is instance2"

Then you'd have the added benenfit of being able to update instance1 to the latest shared code by simply merging master into instance1, without having to update instance2 until you're ready to do so.

The Git book has a great explanation of branching, and I think you can achieve your goal with nothing more than creating separate branches and merging when you need to. And merging will be much easier if only the config file is different.

Andrew
  • 2,438
  • 1
  • 19
  • 19
  • Sorry for taking so long to comment. So couldn't I do the same thing by keeping one master branch and setting all the different configs (like logo path, Twilio API keys, etc) as ENV variables in an application.yml file and creating a different one for each instance? Add it to .gitignore, and manually place it in the app/shared/config directory? If I branch and I end up having 100 different instances, this might be a pain to maintain. Or am I not understanding your answer properly? – nulltek Oct 21 '14 at 18:46
  • I'd hate to leave important components outside of source control—what happens if you accidentally `rm` it? I don't think syncing 100 separate repositories would be any easier than merging branches... hmm. Merging is quick and you wouldn't be doing it that much, and could even write a tiny shell script to do it if it becomes monotonous.Oh, here's somebody that already went through this process: http://stackoverflow.com/a/1774399/2546659. I think the key is just to keep your code as generic as possible from the beginning. – Andrew Oct 22 '14 at 05:37