0

I have 5 different websites that use exactly the same code, apart from they have an uploads folder with different contents (AKA images that aren't consistent through every site) and also a config file which has a few settings like whether this is a production environment, which database to use etc.

My problem is I have 5 different versions of the back-end system that should be the same for every site.

So, cue Git. I've just started learning and now understand the basics and need to choose a workflow for my development environment. This workflow will ideally allow me to swiftly switch between one website to another (with the same back-end, different images/config file).

My thoughts on how to achieve this

My idea is to have a branch for each of the different websites. On the master branch is where the back-end code will sit and will have all commits related to the back-end code. Then, create 5 other branches which contain the unique uploads' folders and the config file for each site. Then, when I want to view a different site I just git branch site3 and all the uploads load and the correct database is selected etc.

Does this sound like the right sort of approach? I'm looking for a reliable development workflow that I can use to scale up to 50 sites that I can maintain with ease. The idea is to have all the sites feed from the same back-end, but still be visually different when I switch to the relevant site branch (so I have an accurate representation of each website).

  • 1
    Don't do this. Trust me you'll regret it. Listen to @sjord-job-postmus – Esben Skov Pedersen Sep 11 '15 at 16:42
3

It sounds like you are trying to get the site configuration into your version control system (git). This sounds like a bad idea, especially if you want 1 branch per config.

You'd be best served by only storing the source code in git, and keep the rest as configuration on the server, outside of git. Either as a config file (database credentials), site-specific templates, or where possible: in the database. Every look&feel should be decoupled from the code, and where things differ per project, make a customization hook in the config.

Alternatively, if you really want this in git, I'd suggest having per-site settings in separate directories/file, and use a simple symbolic link with the name current to point to the specific configuration directory/file.

One of the projects I worked on has two separate branches for two specific layouts, and it already turned into a maintenance nightmare a few months in. Bad idea.

  • Does this mean that every time I want to see what the changes look like on another site I'm going to have to pull the changes on each different server? I can see where you're coming from but sadly this doesn't sound like a very good system to test a single code base in lots of different colours with different images etc (colours being database-side) – jskidd3 Sep 11 '15 at 16:51
  • That's why I suggested the alternative option: keeping all the different configurations in subdirectories. Then, changing the design is a simple rm current; ln -s site_layout7 current to see what it'd look like for the settings for site site_layout7. – Sjoerd Job Postmus Sep 11 '15 at 17:08
  • I guess it would help if I knew what a symbol link was ;-) reading into this now, thanks! – jskidd3 Sep 11 '15 at 17:24
  • Is current the name of the symbolic link that points to site_layout7? I assume I just change the symbolic link's destination when I want to change it to site_layout6? – jskidd3 Sep 11 '15 at 17:26
  • @jskidd6: yes, current would be the name of the symbolic link. Still, even this is something you will start to regret someday, just not as soon as the approach with branches. Best would be to come up with a system where the 'skin' (theme, styling, looks) is built on a framework that you trust to keep that looking good, and decoupled from thr backend. StackExchange has lots of skins (programmers.stackexchange.com being one of them), but I really doubt the developer test changes with all skins. – Sjoerd Job Postmus Sep 11 '15 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.