1

I'm working on a Django back end that will be used by two websites (i.e., a job board for non-profits and a job board for for-profit companies), but I'm not sure how this is best structured to make it easy to push/pull updates to the two websites.

The Django code for the websites is highly similar (let's say over 95% overlap), but the websites have slightly different templates and separate CSS style sheets, in order to give each a distinct look and feel.

My inclination would be to set this up as a single Django project that stores the CSS style sheets for both websites, has a different templates folder for each website, and has multiple settings files (e.g., base, production_fprofit, production_nprofit). To facilitate any current or future differences in the back end, a settings variable would indicate the platform for which the code is used (e.g., FPROFIT = True/FPROFIT = False) and this variable is called when necessary (e.g., if settings.FPROFIT == True: payment_required()). Whenever the Django code changes, the code is pushed to GIT and pulled by the two platforms - each running on a separate virtual host, with their own testing, staging, and production environments.

The two main alternatives that I can see include keeping the projects separate, but sharing the apps (not sure how this works with version control/GIT) or "forking" the project and updating the master branch like so:

Updating forked GitHub repo to match original's latest code and commits

Although my approach (i.e., one project, separate style sheets and templates) seems the most straightforward to me, it does not feel very GITonic/Djangothonic/Pythonic. I'm concerned that my choice for this solution is based on my lack of experience with the deployment of apps or working with forks in GIT and that I will run into issues down the line. Therefore, I am keen to hear your thoughts and experiences.

Colin Lee
  • 27
  • 5

1 Answers1

1

I ran into a similar situation once where I had to deploy two different web applications with different templates but the same backend for the most part (a few lines of different code here and there).

This is the approach I follow:

  1. Main repo
    It contains all the Django/Python code. And all the main development happens in this repo. It also has some barebones templates and basic stylesheet. All the bugs are also fixed here.
  2. Clone repos
    These repos are clones of the Main repo. Every time you need to deploy a new application, you just create a clone for it.
    You implement new features that are specific to a particular instance of the webapp in it's own repo, for example extra fields in a model, extra lines in a view, or changing the templates and stylesheets.

Workflow:

  1. Create the core app in the Main repo.
  2. For N-Profit webapp, clone the Main repo.
  3. Update the N-Profit code, like the stylesheets, and settings like FPROFIT = False, etc.
  4. Deploy N-Profit.
  5. For F-Profit, clone the Main repo.
  6. Update code, like FPROFIT = True, etc.
  7. Deploy F-Profit.

You can implement new features that are common to all your webapps in the Main repo and then pull the new changes from here.

xyres
  • 20,487
  • 3
  • 56
  • 85
  • Makes sense! So when you pulled the changes, did you do it selectively (i.e., cherry-pick)? Or did you re-implement the instance-specific features each time? – Colin Lee Dec 05 '17 at 09:35
  • @ColinLee Yes, instance specific features are implemented in their own repos. Cherry-picking might also work, but I tend to stay away from the complex. You should try and simulate the behaviour you need with a couple of test repos and see what works better for you. – xyres Dec 05 '17 at 15:25