I use the term "environment" quite a lot in this article. If you’re not aware of what that means, or just want to be sure that I use it in the same way as you do, look at the definition I give at the end of the article<\/a>.<\/em><\/p>\n<\/blockquote>\n But once you start setting up your Django app on multiple environments; like production, testing, and staging \u2014 and on machines for new developers, you are likely to run into a pain point; managing the configuration across the different environments.<\/p>\n This article discusses about this problem, provides the solution that we have used for most of our projects, and also lists other ways in which the Django community tackles this.<\/p>\n I think one of the reasons that many Django tutorials; including the official one, don’t mention this issue is because honestly, it’s not a huge<\/strong> pain. Compared to how often your make changes to the code for your views, templates, and models \u2013 you rarely touch the But do the same thing over and over again; over the period of years that some projects are in use, and you tend to get tired of it and start wanting a better solution. But what exactly is the problem?<\/p>\n Imagine you are developing a new web application in Django. You have been working on it for a couple of weeks now. Initially it was just something you started as a proof-of-concept, but now your employer sees it going somewhere \u2013 and you get assigned a team to help you finish this thing and release it.<\/p>\n When that second developer wants to start working on the project, they clone it from the Git\/Mercurial\/whatever repo, install the project dependencies, and run Errors like these are common when you setup a Django project on a new machine. When you were working on your own, you set some configuration options; like the logging file path, to work on your machine. But now that your colleague wants to run the project on their machine, they don’t have the same file system structure as yours.<\/p>\n The quickest way most beginner Django developers solve this is to change the If your colleague pushes their modified One solution is to use relative paths instead of absolute ones. So instead of<\/p>\n you use<\/p>\n This way the logs are now written to a location relative to the This solves the problem described above with system specific paths, but it’s not the complete answer. You have many other types of configuration options \u2013 the database username and password, authentication keys for APIs, When you want to deploy your application to multiple environments, API keys are something that are most likely to change. Many of the APIs we use everyday offer testing\/sandbox and live environments.<\/p>\n SendWithUs (a service used to send emails) for example allows you to create test API keys that deliver emails to only 1 inbox, ideal when testing as you don’t want test emails going to your customers. When you have production, testing, and local development environments, you will need different keys for all these different setups.<\/p>\n There is also issue of security; you ideally don’t want API keys for your services to be a part of your code repository. Why not?<\/p>\n There are a number of good ways in which you can solve this problem. I’ll first show what the solution that we at Agile Leaf use. Later I’ll also list some other solutions from the Django community.<\/p>\n The solution we use here at Agile Leaf is surprisingly simple; both to implement and understand. At the end of and then we put all our environment dependent configuration options into a The reason this works is because the Now, instead of defining our API keys in the Each developer on our team is then free to modify their own copy of the More importantly, we don’t need to worry about having live API keys on our test environments, or test keys on our production environments. When we create a new environment, we first create a For example, the first time we create a production server for our projects, we will create the local settings file, which then gets saved on an internal machine that isn’t publicly accessible. The next time we need to create a production server, we can just copy this file over and have the new server up and running quickly.<\/p>\n Which configuration options you put in As your project grows and you learn more about this approach, you’ll get an intuitive feel for where a specific configuration option should go to. I plan to write another article later discussing the particular method we use when dividing our configuration options between the main and local settings.<\/p>\n We settled upon this approach because it solves almost all of the pains we felt while developing Django projects.<\/p>\n We have been using this technique in our Django projects for a couple of years, and it has served us well. Give it a try. Next I’ll discuss one alternative in detail, and then list some other options available in the community.<\/p>\n A small tweak to our approach is to move the You could define variables like<\/p>\n at the start of in the This allows you to make it even easier to create a new local settings file. If it’s imported at the bottom; like we do, you need to define that entire We haven’t used this way yet because for us, the tradeoff of making sure that the file is imported in the correct place \u2013 after the variables that can be overridden, but before those variables are used vs. needing to write the complete config option to override (like Over the years, people have successfully used a number of ways different than what we have described here. Some of these are listed here.<\/p>\n One popular method that you can see suggested on Django forums and Stackoverflow is to have multiple settings files. For example, you could have<\/p>\n Then when you need to run your project you define the Let’s say you want to run the development server for your project called myproject<\/strong>. Instead of<\/p>\n You would run<\/p>\n Likewise on the production and test environments, you’d configure I personally don’t like this because:<\/p>\n While I prefer my way \ud83d\ude42 I do see the benefits of this approach:<\/p>\n While researching for this article, I found this<\/a> answer on Stackoverflow. It’s similar to how you would create different settings files for different environments, but instead of selecting one manually, your Some of the same reservations that I have to the last method apply here.<\/p>\n There’s a nice project I found called This seems like a nice option that we might try out in the future. One reservation though is that it adds another thing that new developers will now need to learn.<\/p>\n django-configurations<\/a> is a Django module I found from the Stackoverflow answer I mentioned above. I haven’t researched it in detail so can’t say anything, but it’s another option for you to consider.<\/p>\n I found during research for this article a page on the Django wiki that lists many different ways people handle this and other configuration pains. I’m sure it’s an interesting read to compare different ways. You can see it at https:\/\/code.djangoproject.com\/wiki\/SplitSettings<\/a>.<\/p>\nsettings.py<\/code> is a core file in Django projects. It holds all the configuration values that your web app needs to work; database settings, logging configuration, where to find static files, API keys if you work with external APIs, and a bunch of other stuff.<\/p>\nThe problem<\/h2>\n
settings.py<\/code> file once you have it setup.<\/p>\npython manage.py runserver<\/code> to test it out. But wait, what’s this.<\/p>\n![\"Screenshot-2017-11-10-15.25.30\"](\"https:\/\/someweb.com\/content\/images\/2017\/11\/Screenshot-2017-11-10-15.25.30.png\")
<\/p>\nsettings.py<\/code> file to make the project run on their machines. But this just creates another problem a bit later down the line.<\/p>\nsettings.py<\/code> to the code repo and you pull the changes, the project stops working on your machine. Because, wait for it \u2014 their file system structure is different than yours.<\/p>\nA first stab at the problem<\/h2>\n
LOGGING_DIR = "\/home\/jibran\/logs\/"<\/code><\/pre>\nLOGGING_DIR = os.path.join(BASE_DIR, "logs")<\/code><\/pre>\nBASE_DIR<\/code> variable, which for Django projects is set to the directory containing the manage.py<\/code> file.<\/p>\nSMTP<\/code> options on how to send emails…<\/p>\n\n
Our solution<\/h2>\n
settings.py<\/code> for our Django projects, we put<\/p>\ntry: from local_settings import *except ImportError: raise Exception("A local_settings.py file is required to run this project")<\/code><\/pre>\nlocal_settings.py<\/code> file that sits in the same directory as the settings.py<\/code>. We make sure that the local settings file isn’t version controlled, and then each environment we deploy to, we create a new local_settings.py<\/code> file on that machine with settings specific for that environment.<\/p>\nsettings.py<\/code> file is just another Python script. When Django needs to read a configuration value, it will import this file. Since we are doing a star import<\/em> from our local settings into the main settings file, all variables defined in local_settings.py<\/code> become available inside settings.py<\/code>. More importantly, these imported variables override any that are already defined in the settings.py<\/code>, which is why this import goes at the end of the settings file.<\/p>\nsettings.py<\/code> file, we define it in local_settings.py<\/code>, like this.<\/p>\nSENDWITHUS_API_KEY = "<API KEY>"AWS_KEY = "<AWS_KEY>"...<\/code><\/pre>\nlocal_settings.py<\/code> without needing to touch the main settings.py<\/code> file. Since the local settings are not pushed to our code repo, we don’t get accidentally break each others development environments.<\/p>\nlocal_settings.py<\/code> file for that environment.<\/p>\nsettings.py<\/code> and which you put in local_settings.py<\/code> depends on your project. The best advice I can give is to move settings that definitely change between environments; like the database and logging configurations.<\/p>\nWhy this way?<\/h2>\n
\n
local_settings.py<\/code> and override whatever settings.py<\/code> already defines. For example our main settings file can have DEBUG = False<\/code> but for our local development machines we can put DEBUG = True<\/code> in the local settings file to override that.<\/li>\nsettings.py<\/code>, we don’t need to put every configuration option in local_settings.py<\/code>, only those that we need to change for the machine the project is running on. This also allows us to keep common settings; like the INSTALLED_APPS<\/code>, MIDDLEWARE<\/code> and other similar options in our settings.py<\/code> file.<\/li>\nlocal_settings.py<\/code> we have for our production environment, and then copy that file over to all the production servers.<\/li>\nsettings.py<\/code> file. Which means that new Django developers who have just started using Django can directly use the knowledge they gained about configuration from the Django tutorial in our project. They don’t need to learn 1 more thing specific to our projects.<\/li>\n<\/ul>\nA small tweak<\/h3>\n
from local_settings import *<\/code> near the top of settings.py<\/code>. This has some benefits.<\/p>\nDATABASE_HOST = 'localhost:5678'DATABASE_USER = 'root'LOGGING_DIR = '\/home\/jibran\/logs'<\/code><\/pre>\nsettings.py<\/code> with reasonable defaults for a local development environment. Then import local settings. Finally, instead of using something like<\/p>\nDATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'db_name', 'USER': 'jibran' }}<\/code><\/pre>\nsettings.py<\/code> file, you could use<\/p>\nDATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': DATABASE_NAME, 'USER': DATABASE_USER }}<\/code><\/pre>\nDATABASES<\/code> config dictionary in the local settings to override the configuration in the main settings. By importing near the top, you can override just specific variables and settings.py<\/code> will use those new values.<\/p>\nDATABASES<\/code> in the example above) isn’t worth it. But maybe it’s something you prefer.<\/p>\nOther options<\/h2>\n
Version controlled environment specific settings files<\/h3>\n
\n
settings.dev.py<\/code><\/li>\nsettings.prod.py<\/code><\/li>\nsettings.test.py<\/code><\/li>\n<\/ul>\nDJANGO_SETTINGS_MODULE<\/code> env var to point to the correct file.<\/p>\npython manage.py runserver<\/code><\/pre>\nDJANGO_SETTINGS_MODULE=myproject.settings.dev python manage.py runserver<\/code><\/pre>\nuwsgi<\/code> or gunirocrn<\/code> to set DJANGO_SETTINGS_MODULE<\/code> to the correct settings file name for that environment.<\/p>\n\n
DJANGO_SETTINGS_MODULE<\/code> env var every time you use manage.py<\/code> commands. It’s easier for me to define a local settings once instead of needing to remember this.<\/li>\nINSTALLED_APPS<\/code> for your local environment and forget to add it to the production environment settings. A blog post<\/a> I found while researching this article discusses a very good way of side stepping this problem, while having environment specific settings files.<\/li>\n<\/ul>\n\n
local_settings.py<\/code> to use.<\/li>\n<\/ul>\nMultiple settings files, without needing to explicitly select one<\/h3>\n
settings.py<\/code> file now selects for you based on which machine the project is running on.<\/p>\nDjango split settings<\/h3>\n
django_split_settings<\/code><\/a>. It seems to be a combination of the method we use, and splitting the settings across multiple files. You can include optional local settings files to override default configs.<\/p>\nDjango configurations<\/h3>\n
All the other options<\/h3>\n