hexvolt-блог: Django Workflow. Организация рабочего процесса.

7. Наводим порядок с settings.py

У нас есть пустая (пока) папка settings/. Перенесем в нее файл настроек settings.py из корневой папки проекта и для удобства переименуем этот файл в defaults.py (поскольку эти настройки, по сути и являются настройками по умолчанию). Кроме того, на данном этапе целесообразно вынести настройки, относящиеся к девелопмент-версии нашего проекта, в отдельный файл local.py. В дальнейшем мы можем добавлять в папку settings/ другие файлы с теми или иными настройками.



Для того, чтобы django нашел наш модуль "django1.settings" после перемещения, необходимо сделать папку settings пакетом. Для этого внутри папки создаем файл "__init__.py" со следующим текстом:



from .defaults import *



try:

    from .local import *

except ImportError:

    pass



Таким образом, теперь django вместо модуля settings будет подключать пакет settings, который включает в себя все содержимое файла defaults.py, а также файла local.py в случае его наличия.



Примечание: для чего нужно вынесение локальных настроек в отдельный файл? Как известно, при развертывании проекта на продакшн-сервере, необходимо изменять настройки проекта (например, выключать режим отладки DEBUG = False). Если все настройки хранятся в одном файле, то при клонировании репозитория на продакшн-сервере этот файл появится в "боевой" версии проекта. Соответственно, чтобы на продакшене наш проект не работал с девелопмент-настройками, необходимо вручную заходить на сервер и править настройки на такие, которые будут пригодны именно для продакшн, а не для девелопмент-среды. Чтобы не повторять эти операции при каждом деплое, можно вынести локальные настройки в отдельный файл (local.py) и исключить его из индекса git (что мы и сделали в предыдущем шаге). Тогда в репозиторий (и на сервер) будет попадать все файлы настроек, кроме локальных, что избавит нас от необходимости ручной правки. Ну и наконец, чтобы продакшн-версия проекта не ругалась на отсутствие подключаемого файла, нужно внести заглушку "try… except" в файл __init__.py, что мы только что и сделали.



Итак, текущая структура директорий:

.

└── django1

    ├── django1

    │   ├── apps

    │   │   ├── core

    │   │   │   ├── admin.py

    │   │   │   ├── __init__.py

    │   │   │   ├── models.py

    │   │   │   ├── tests.py

    │   │   │   └── views.py

    │   │   └── __init__.py

    │   ├── settings

    │   │   ├── defaults.py

    │   │   ├── local.py

    │   │   └── __init__.py

    │   ├── templates

    │   ├── __init__.py

    │   ├── urls.py

    │   └── wsgi.py

    ├── media

    ├── requirements

    ├── static

    ├── manage.py

    └── README.rst

После всех манипуляций, желательно сделать очередной коммит, например, с комментарием "Settings moved" (не забываем предварительно добавить в индекс git файл defaults.py).

8. Настраиваем СУБД, подключаем South

• schemamigration — анализирует изменения, внесенные в код моделей, и создает соответствующий файл миграций, который позволит отразить их в БД. Первый раз запускается с ключом —initial, все последующие разы — с ключом —auto;
• migrate — считывает предварительно созданный файл миграций и согласно ему вносит измененя непосредственно в БД.

Применительно к нашу проекту, пока мы еще не создавали модели в приложении core, выполняем:

    python manage.py schemamigration core —initial

и применяем все изменения (даже если их пока и нет):

    python manage.py migrate core



В дальнейшем, внося изменения в код моделей в приложении core, мы будем применять их следующим образом:

    python manage.py schemamigration core —auto

    python manage.py migrate core



Примчение: указанные команды набираются в терминале под виртуальным окружением проекта django1



Принцип работы и порядок работы South хорошо описан тут.

9. Стратегия дальнешей разработки

Дальше — непосредственно разработка django-проекта. При этом я обычно веду две git-ветки — master и develop, которые существуют постоянно. В master ветку выкладываются только полностью рабочие версии проекта, а в develop — промежуточные версии. Т.е. весь процесс написания и отладки кода ведется только в ветке develop. Когда же какой-то новый функционал сайта полностью отлажен — в мастер-ветку подтягивается последний коммит из ветки develop. При таком объединении важно не использовать режим fast-forward, поэтому команда объединения должна быть с таким ключом:



    git merge -m "some_text" —no-ff develop



В противном случае после операции merge коммиты с двух веток сольются в одну.



Таким образом, в master-ветке гарантированно будут только рабочие версии проекта, именно они и будут выкладываться на сервер. В процессе разработки необходимо не забывать почаще делать коммиты и выкладывать изменения в удаленный репозиторий на сервере.



О том, как разрвернуть проект из репозитория на продакшн-сервере, будет описано чуть позже.