आप विभिन्न environments में settings को कैसे manage करते हैं?

Question

Accepted Answer

Django का configuration `settings.py` में रहता है, लेकिन वास्तविक applications को **प्रत्येक environment के लिए अलग settings** चाहिए होती हैं (development, staging, production) और उन्हें **secrets को code से बाहर** रखना होता है। इसे सही ढंग से manage करना एक operational आवश्यकता और एक security requirement दोनों है।

## एकल settings.py की समस्या

```python
# ❌ hardcoded, environment-mixed, and INSECURE settings
DEBUG = True                                    # must be False in production!
SECRET_KEY = "hardcoded-secret-in-code"          # ❌ secret committed to git
DATABASES = {"default": {"PASSWORD": "prod-pw"}} # ❌ production password in code
```

Values को hardcode करना environments को mix कर देता है और — सबसे गंभीर बात — secrets (SECRET_KEY, database passwords, API keys) को version control में commit कर देता है, जो एक गंभीर security breach है।

## समाधान 1: environment variables से config पढ़ें

```python
import os
from pathlib import Path

SECRET_KEY = os.environ["DJANGO_SECRET_KEY"]    # from the environment, NOT code
DEBUG = os.environ.get("DJANGO_DEBUG", "False") == "True"
ALLOWED_HOSTS = os.environ.get("ALLOWED_HOSTS", "").split(",")
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": os.environ["DB_NAME"],
        "PASSWORD": os.environ["DB_PASSWORD"],   # injected per environment
    }
}
# tools like django-environ / python-decouple make this cleaner (+ .env file support)
```

Config (विशेष रूप से secrets) को **environment variables** से पढ़ना उसे code से बाहर रखता है — वही codebase किसी भी environment में अलग-अलग injected values के साथ चलता है (twelve-factor approach)।

## समाधान 2: प्रत्येक environment के लिए settings files को विभाजित करें

```text
settings/
  base.py          # shared settings (apps, middleware, templates)
  development.py   # from base import *; DEBUG=True, local DB, debug toolbar
  production.py    # from base import *; DEBUG=False, security hardening, real DB
  test.py          # test-specific settings
```

```python
# production.py
from .base import *
DEBUG = False
ALLOWED_HOSTS = ["example.com"]
SECURE_SSL_REDIRECT = True            # production-only security settings
# select via: DJANGO_SETTINGS_MODULE=config.settings.production
```

Settings को एक shared `base.py` और प्रत्येक environment की files में विभाजित करना (जिन्हें `DJANGO_SETTINGS_MODULE` के माध्यम से select किया जाता है) common settings को share करते हुए environment-specific configuration को साफ-सुथरे ढंग से अलग करता है।

## महत्वपूर्ण production settings

```python
DEBUG = False                  # ❗ NEVER True in production — leaks sensitive error info
ALLOWED_HOSTS = ["example.com"] # required when DEBUG=False
SECRET_KEY = os.environ[...]    # strong, secret, from the environment
# + SECURE_SSL_REDIRECT, SESSION_COOKIE_SECURE, HSTS, etc. for hardening
```

```text
✓ NEVER commit secrets — use env vars / a secret manager; gitignore .env
✓ DEBUG=False in production (DEBUG=True leaks tracebacks, settings → security risk)
✓ Commit a .env.example documenting required variables (no real values)
```

## यह क्यों महत्वपूर्ण है

Environments में settings को manage करना किसी भी वास्तविक Django application के लिए एक operational आवश्यकता और एक **महत्वपूर्ण security practice** दोनों है।

Applications को विभिन्न environments में अलग व्यवहार करना चाहिए — development को `DEBUG=True` और सुविधाजनक local settings चाहिए, जबकि production को `DEBUG=False`, security hardening, real databases, और उचित hosts चाहिए — और एक एकल hardcoded `settings.py` इन सबको पूरा नहीं कर सकता।

इससे भी महत्वपूर्ण, यह एक **बड़ी security चिंता** है: secrets (SECRET_KEY, database passwords, API keys) को hardcode करना उन्हें version control में commit कर देता है, जो सबसे आम और गंभीर security breaches में से एक है (repo access वाला कोई भी व्यक्ति, या एक public repo में, आपकी application और data की keys पा जाता है)।

समाधानों को समझना — config और secrets को **environment variables** से पढ़ना (उन्हें code से बाहर रखना, twelve-factor approach, अक्सर django-environ और gitignored `.env` files जैसे tools के साथ) और **settings को विभाजित करना** एक shared base और प्रत्येक environment की files में — Django को सुरक्षित और सही ढंग से deploy करने के लिए आवश्यक है।

**महत्वपूर्ण production settings** को जानना (विशेष रूप से कि production में `DEBUG` को `False` होना चाहिए, क्योंकि `DEBUG=True` tracebacks, source paths, और settings को attackers को leak कर देता है, साथ ही `ALLOWED_HOSTS` और security hardening) अनिवार्य production ज्ञान है।

Settings management को सही करना — environment में secrets, environment-appropriate configuration, secure production defaults — Django applications को professional ढंग से चलाने और leaked secrets या misconfigured production environments से आने वाली गंभीर vulnerabilities से बचने के लिए मौलिक है, जो इसे किसी भी वास्तविक deployment के लिए महत्वपूर्ण, व्यावहारिक रूप से अनिवार्य ज्ञान बनाता है।