🔧 Split Settings into Development and Production Environments and updating the requirements

[snipher-marube]

Summary This PR improves project configuration by splitting the Django settings into modular files for development and production environments. This structure follows best practices for environment-specific configuration and enhances maintainability, security, and developer experience.

Changes Introduced 📁 Created settings/base.py: common settings shared across all environments.

📁 Added settings/development.py: tailored for local development.

Enables DEBUG=True

Uses SQLite

Adds localhost to ALLOWED_HOSTS

📁 Added settings/production.py: ready for deployment

Sets DEBUG=False

Uses PostgreSQL with environment variables via python-decouple

Implements Django security best practices (HSTS, secure cookies, SSL redirects)

🔐 Improved use of decouple to load secrets and database config securely

🛡 Ensures ALLOWED_HOSTS is explicitly set in all environments

📦 Added .env.example to guide contributors on environment setup

Why This Is Needed Separating settings avoids accidental use of development configurations in production.

Prepares the Codespace for real-world deployment scenarios.

Supports cleaner, more secure environment management.

How to Test Copy .env.example to .env and populate required fields.

Run development server with: python manage.py runserver --settings=hello_world.settings.development

To simulate production locally: python manage.py runserver --settings=hello_world.settings.production

Notes

• This update is fully backward-compatible with existing codespace environment variables like CODESPACE_NAME.

• Environment-specific settings now prevent misconfigurations during deployment.