Configuration. dev vs production
I do not think that this topic should be a revelation for advanced Django-coders. But from experience in different projects, I can say that many programmers are not in the subject.
So, any project (practically) requires a separate configuration for the development machine and the production server. You can simply make two configuration files, but sometimes you need to enter and change common settings for each configuration.
Some insert a bunch of if-s or something else worse, relying on ip (uzhos) or the name of the machine, but this is all extremely inconvenient and clutters up the configuration. For me, this is a very strong argument for not participating in a project, since This indicates the quality of the entire code.
In the Django community, unspoken standards have already been adopted based on the experience of many: creating a separate local_settings.py configuration file and turning it on at the end of the main configuration, thus overwriting the values of the necessary parameters.
')
I think it is better to demonstrate.
settings.py
Next, create local_settings.py and write:
Immediately add local_settings.py to svn: ignore, so as not to get rid of it further.
All is ready. We load the project in svn, we do on the svn co / var / svn production (well, or just like anyone). Now, without much crap, you can deploy a version from SVN, while the developer has enough space for maneuver in the local configuration.
It is simple, but extremely convenient. Use who did not know yet.
So, any project (practically) requires a separate configuration for the development machine and the production server. You can simply make two configuration files, but sometimes you need to enter and change common settings for each configuration.
Some insert a bunch of if-s or something else worse, relying on ip (uzhos) or the name of the machine, but this is all extremely inconvenient and clutters up the configuration. For me, this is a very strong argument for not participating in a project, since This indicates the quality of the entire code.
In the Django community, unspoken standards have already been adopted based on the experience of many: creating a separate local_settings.py configuration file and turning it on at the end of the main configuration, thus overwriting the values of the necessary parameters.
')
I think it is better to demonstrate.
settings.py
# ()
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'professors'
DATABASE_USER = 'root'
DATABASE_PASSWORD = 'blabla'
DATABASE_HOST = 'localhost'
DATABASE_PORT = ''
#
# ...
#
try:
from local_settings import *
except ImportError:
pass
Next, create local_settings.py and write:
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_NAME = 'professors_v2'
DATABASE_USER = 'developer'
DATABASE_PASSWORD = 'blabla2'
Immediately add local_settings.py to svn: ignore, so as not to get rid of it further.
All is ready. We load the project in svn, we do on the svn co / var / svn production (well, or just like anyone). Now, without much crap, you can deploy a version from SVN, while the developer has enough space for maneuver in the local configuration.
It is simple, but extremely convenient. Use who did not know yet.
Related Links
Source: https://habr.com/ru/post/25934/
All Articles