🔧 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.

[Copilot]

Pull Request Overview

This PR refactors the Django settings by splitting them into modular files for both development and production environments to enhance security, maintainability, and overall configuration management.

• Updated manage.py to dynamically select between development and production settings based on the DEBUG flag.
• Created dedicated settings files: base.py for common settings, development.py for local testing, and production.py for deployment.
• Removed the legacy settings.py and updated the settings/init.py to conditionally import the correct configuration.

Reviewed Changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
manage.py	Updated to dynamically set DJANGO_SETTINGS_MODULE based on DEBUG from the development file.
hello_world/settings/production.py	New production settings with PostgreSQL and Django security best practices.
hello_world/settings/development.py	New development settings using SQLite, with additional support for GitHub Codespaces.
hello_world/settings/base.py	Common settings extracted for reuse in both production and development configurations.
hello_world/settings/init.py	Imports settings based on DJANGO_SETTINGS_MODULE to ensure proper configuration load.
hello_world/settings.py	Deprecated legacy settings file now removed.

Files not reviewed (1)

• .env.example: Language not supported

[Copilot]

Currently, the main() function imports the development settings first to check DEBUG, which may lead to confusion when switching to production. Consider using an environment variable or another configuration flag to determine the settings module prior to importing any settings.

Suggested change

	from hello_world.settings import development as settings
	if settings.DEBUG:
	os.environ.setdefault("DJANGO_SETTINGS_MODULE", "hello_world.settings.development")
	else:
	os.environ.setdefault("DJANGO_SETTINGS_MODULE", "hello_world.settings.production")
	settings_module = os.getenv("DJANGO_SETTINGS_MODULE", "hello_world.settings.development")
	os.environ.setdefault("DJANGO_SETTINGS_MODULE", settings_module)