Django Configuration: Managing Multiple Settings for Scalable Projects

In this guide, we delve into the complexities of Django configuration, focusing specifically on the management of multiple settings for projects that demand scalability. While Django’s default settings file is adequate for smaller projects, it often proves insufficient for larger, more intricate applications.

1. Introduction to Django Settings

In addition to facilitating the organization of configurations, the configuration file in Django plays a fundamental role in customizing and optimizing our project. Through this file, we can modify various options to tailor the application’s functionality to our specific needs.

2. Challenges with Single Settings File

Typically, when starting a new project, there is usually a single configuration file. This may not pose an issue for small-scale projects. However, as the system grows, problems arise because this file tends to become overwhelming, making it difficult to maintain a detailed structure of the configuration and the environments in which we want to run the project.

3. Creating Multiple Settings Files

Next, we’re going to create a default Django project. This project will serve as a foundation for exploring and understanding the code presented in this post. To access the complete code, you can go to the following repository: 🎖️[dj-multiple-settings-config] .Once there, you’ll find all the files and resources necessary to follow this tutorial step by step.

3.1. Creating a virtual environment and installing django

python3 -m venv venv

Once the virtual environment has been created, we’ll activate it with the following command:

For Linux:

source venv/bin/activate

In case of Windows:

\venv\Scripts\activate

Once activated, we will proceed to install Django and subsequently create a project named “core”.

Installing Django:

pip install django

Creating the Django project called “core”:

django-admin startproject core

In Linux, we execute the command “tree” within the “core” folder, and it appears as follows:

.
├── __init__.py
├── asgi.py
├── settings.py
├── urls.py
└── wsgi.py

4. Configuration-multiple Settings files

In this step, we will proceed to configure multiple settings files for our two main environments that we will be working with: development (dev) and production (prod). This process will ensure a more efficient and organized management of our project’s configuration.

To begin, we create a new directory within the “core” folder, located at the same level as the “settings” directory. We will name this new directory “settings”. Next, we proceed to copy the “settings.py” file from its original location to this new directory. Subsequently, we rename this file as “base.py”. In the same directory, we add three new files: one empty file called “init.py”, and two others named “prod.py” and “dev.py”.

We execute the command “tree” and the settings directory should appear to us in the following way.

├── __init__.py
├── base.py
├── dev.py
└── prod.py

5. Switching Between Settings

Once the project has been fully set up, we navigate to the directory containing the “manager.py” file. To verify that everything is functioning correctly, we proceed to execute the base file as follows:

python3 manage.py runserver --settings=core.settings.base

It should appear in the console as follows:

If we observe the square highlighted in red, we can notice that the file Django is executing is the one we specified as a parameter in the previous command, namely “core.settings.base”.

It is crucial to understand the structure of the configuration path for Django projects, which is formed as follows:

6. Django Settings Overrides

Once the initial setup is completed, it’s time to define the contents of the “prod.py” and “dev.py” files. In the context of team development, it’s common to have multiple environments for project execution. These environments are typically divided into development (dev) and production (prod). If the team has a testing environment, there may also be an additional configuration called “qa.py”. Furthermore, if the team follows a solid DevOps structure and wishes to deploy various stages of the project in different environments that mimic production, these could be called “stage-prod-1.py”, “stage-prod-2.py”, and so on. However, in our case, we will limit ourselves to having only two environments, as shown in the following image:

7. Overriding Configuration

In this step, we’re going to overwrite the base file and create the “dev.py” file as follows:

import os
from pathlib import Path
from core.settings import *

DEBUG = True
BASE_DIR = Path(__file__).resolve().parent.parent
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

And the “prod.py” file will look like this instead:

from core.settings import *

ALLOWED_HOSTS = ['*']
DEBUG = False

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'mydatabase',
        'USER': 'mydatabaseuser',
        'PASSWORD': 'mypassword',
        'HOST': 'localhost',
        'PORT': '',
    }
}

Next, to indicate to Django which configuration file we want to execute globally in our local environment, we run the following command in Linux:

export DJANGO_SETTINGS_MODULE=core.settings.dev

In the case of Windows, we can set the environment variable as follows:

setx DJANGO_SETTINGS_MODULE "core.settings.prod"

If you encounter issues when inserting the environment variable in Windows, here is a 🎖️ [Link]. The environment variable “DJANGO_SETTINGS_MODULE” instructs Django on which configuration file to load for the corresponding working environment.

Once the aforementioned steps are completed, it’s essential to execute the “makemigrations” and “migrate” commands to perform all necessary migrations in our local working environment.

 python manage.py makemigrations

python manage.py migrate

Finally, we run the server again using the “dev.py” configuration file. However, since we’ve already specified to Django in the “DJANGO_SETTINGS_MODULE” environment variable that we’re using the “dev.py” file, it’s no longer necessary to include the “ — settings” option in the “manager.py” command. Therefore, the command would be simplified as follows:

python manager.py runserver

And it will show us the following result.

Conclusion

In conclusion, mastering the management of multiple settings in Django is crucial for building scalable and robust web applications. By adopting a multi-settings approach, developers gain flexibility, modularity, and maintainability, allowing them to tailor configurations to different environments and deployment scenarios.

Thank you for reading!!!

Happy coding :)

Resources

Here is the link to the project at 🎖️[GitHub].

Follow me on 🎖️ [Linkedin] .

Official Documentation 🎖️ [Django Settings] .

The Twelve-Factor App 🎖️ [Link] .