我們僅僅處理一個單一的設置文件 settings.py文件由django-admin.py startproject命令生成。但是當你準備要進行配置的時候，你將發現你需要多個配置文件以使你的開發環境和產品環境相獨立。 比如，你可能不想每次在本地機器上測試代碼改變的時候將DEBUG從False 改為True。Django通過使用多個配置文件而使得這種情況很容易得到避免。

如果你想把你的配置文件按照產品設置和開發設置組織起來，你可以通過下面三種方法的其中一種達到這個目的。

•     設置成兩個全面的，彼此獨立的配置文件
•     設置一個基本的配置文件（比如，為了開發)和第二個（為了產品)配置文件，第二個配置文件僅僅從基本的那個配置文件導入配置，并對需要定義的進行復寫.
•     使用一個單獨的配置文件，此配置文件包含一個Python的邏輯判斷根據上下文環境改變設置。

我們將會在依次解釋這幾種方式

首先，最基本的方法是定義兩個單獨的配置文件。 如果你是跟隨之前的例子做下來的，那么你已經有了一個settings.py了，現在你只需要將它復制一份并命名為settings_production.py（文件名可以按照你自己的喜好定義),在這個新文件中改變DEBUG等設置。

第二種方法比較類似，但是減少了許多冗余。 作為使用兩個內容大部分相同的配置文件的替代方式，你可以使用一個文件為基本文件，另外一個文件從基本文件中導入相關設定。 例如

此處，settings_production.py 從settings.py 導入所有的設定，僅僅只是重新定義了產品模式下需要特殊處理的設置。 在這個案例中，DEBUG 被設置為False，但是我們已經對產品模式設置了不同的數據庫訪問參數。 （后者將向你演示你可以重新定義 任何 設置，并不只是象 DEBUG 這樣的基本設置。）

最終，最精簡的達到兩個配置環境設定的方案是使用一個配置文件，在此配置文件中根據不同的環境進行設置。 一個達到這個目的的方法是檢查當前的主機名。 例如：

在這里，我們從python標準庫導入了socket 模塊，使用它來檢查當前系統的主機名。 我們可以通過檢查主機名來確認代碼是否運行在產品服務器上。

一個關鍵是配置文件僅僅是包含python代碼的文件。你可以從其他文件導入這些python代碼，可以通過這些代碼執行任意的邏輯判斷等操作。 如果你打算按照這種方案走下去，請確定這些配置文件中的代碼是足夠安全（防彈)的。 如果這個配置文件拋出任何的異常，Django都有可能會發生很嚴重的崩潰。

重命名settings.py

隨便將你的settings.py重命名為settings_dev.py或settings/dev.py或foobar.py，Django 并不在乎你的配置文件取什么名字，只要你告訴它你使用的哪個配置文件就可以了。

但是如果你真的重命名了由django-admin.py startproject 命令創建的settings.py文件，你會發現manage.py會給出一個錯誤信息說找不到配置文件。 那是由于它嘗試從這個文件中導入一個叫做settings的模塊，你可以通過修改manage.py 文件，將 import settings 語句改為導入你自己的模塊，或者使用django-admin.py而不是使用manage.py,在后一種方式中你需要設置 DJANGO_SETTINGS_MODULE 環境變量為你的配置文件所在的python 路徑.(比如'mysite.settings'）。
DJANGO_SETTINGS_MODULE

通過這種方式的代碼改變后，本章的下一部分將集中在對具體環境(比如Apache)的發布所需要的指令上。 這些指令針對每一種環境都不同，但是有一件事情是相同的。 在每一種環境中，你都需要告訴Web服務器你的DJANGO_SETTINGS_MODULE是什么,這是你的Django應用程序的進入點。 DJANGO_SETTINGS_MODULE指向你的配置文件，在你的配置文件中指向你的ROOT_URLCONF,在ROOT_URLCONF中指向了你的視圖以及其他的部分。

DJANGO_SETTINGS_MODULE是你的配置文件的python的路徑 比如，假設mysite是在你的Python路徑中，DJANGO_SETTINGS_MODULE對于我們正在進行的例子就是'mysite.settings'。