तपाई विभिन्न environments मा settings कसरी व्यवस्थापन गर्नुहुन्छ?

Question

Accepted Answer

Django configuration `settings.py` मा रहन्छ, तर वास्तविक applications लाई **environment प्रति फरक settings** (development, staging, production) चाहिन्छ र **secrets लाई code बाहिर राख्न** आवश्यक छ। यो सही तरिकाले व्यवस्थापन गर्नु एक 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
```

Hardcoding मानहरूले environments मिलाइदिन्छ र — महत्त्वपूर्णको साथ — 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 लाई साझा `base.py` र प्रति-environment files (DJANGO_SETTINGS_MODULE को माध्यमबाट चयन गरिएको) मा बिभाजन गर्नुले environment-specific configuration लाई स्पष्टतापूर्वक अलग गर्दछ जबकि साझा settings साझा गर्दछ।

## महत्त्वपूर्ण 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 व्यवस्थापन गर्नु कुनै पनि वास्तविक Django application को लागि एक **operational आवश्यकता** र **महत्त्वपूर्ण security practice** दुवै हो।

Applications लाई environments मा फरक-फरक व्यवहार गर्न आवश्यक छ — development लाई `DEBUG=True` र सुविधाजनक local settings चाहिन्छ, जबकि production लाई `DEBUG=False`, security hardening, वास्तविक 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 पाइन्छ)।

समाधानहरू बुझ्नु — **environment variables** बाट config र secrets पढ्नु (तिनीलाई code बाहिर राख्दै, twelve-factor approach, प्रायः django-environ र gitignored `.env` files जस्ता tools को साथ) र **settings बिभाजन** गरी साझा 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 लाई सही तरिकाले गर्नु — secrets environment मा, environment-appropriate configuration, secure production defaults — Django applications लाई व्यावसायिकतापूर्वक चलाउन र leaked secrets वा misconfigured production environments बाट आउने गम्भीर vulnerabilities बचाउन मौलिक हो, यसलाई कुनै पनि वास्तविक deployment को लागि महत्त्वपूर्ण, व्यावहारिक-महत्त्वपूर्ण ज्ञान बनाइदिन्छ।