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.
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:
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.
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:
Main repo
.N-Profit
webapp, clone theMain repo
.N-Profit
code, like the stylesheets, and settings likeFPROFIT = False
, etc.N-Profit
.F-Profit
, clone theMain repo
.FPROFIT = True
, etc.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.