Оглавление:
- 0.1 Django Workflow. Организация рабочего процесса.
- 0.1.1 Общая концепция
- 0.1.2 0. Подготовка к началу работы
- 0.1.3 1. Создаем виртуальное окружение для проекта
- 0.1.4 2. Устанавливаем Django и создаем новый проект
- 0.1.5 3. Создаем структуру директорий django
- 0.1.6 4. Создаем основное django-приложение
- 0.1.7 5. Открываем проект в PyCharm
- 0.1.8 6. Задействуем систему контроля верий — Git
- 0.1.9 7. Наводим порядок с settings.py
- 0.1.10 8. Настраиваем СУБД, подключаем South
- 0.1.11 9. Стратегия дальнешей разработки
- 0.1.12 8 комментариев:
- 1 Поиск
- 2 Ярлыки
- 3 Обо мне
- 4 Полезные страницы
- 5 Читатели
- 6 Подпишитесь на hexvolt-блог
- 7 Архив блога
Django Workflow. Организация рабочего процесса.
Общая концепция
Что касается организации локального рабочего места, то ниже (п. 0) будет показан список рекомендуемых к установке программ. Здесь же я хотел бы выделить самый важный инструмент из них — это система контроля версий Git. В сети много информации о ней, если в двух словах — Git позволяет вести историю изменений всех файлов проекта, откатываться до любой из предыдущих версий проекта, организовывать командную работу, синхронизировать изменения, сделанные разными пользователями в одном и том же проекте, создавать репозитории для распространения вашего проекта и т.д. По сути, Git (и аналогичные ему системы контроля версий) стали своего рода стандартом ведения проектов, поэтому крайне рекомендуется сразу организовывать работу через Git, даже если вы будете вести свой сайт сами и не будете ни с кем делиться. Таким образом, использование Git позволяет убить сразу нескольких зайцев — разработчик может не бояться потерять предыдущие версии своего кода, отпадает необходимость в резервных копиях, и появляется возможность расшаривать и синхроинзировать свой проект в случае командной разработки.
И последний момент. Система контроля версий Git обычно связана с использованием удаленного Git-сервера (например, BitBucket, GitHub), на который осуществляется выгрузка локального проекта (с целью расшаривания его другим пользователям, портирования на другие компьютеры или просто с целью хранения исходников "на облаке"). С учетмо этого, общий принцип работы над Django-проектом может выглядеть примерно так:
- редактируем код на девелопмент-машине
- выгружаем проект (операция push) с локальной машины на Git-сервер
- когда нужно развернуть проект на "боевом" сервере, то скачиваем наш проект (операция pull) с Git-сервера на продакшн-машину.
Если есть необходимость работать над своим проектом, например, дома и на работе, то процесс может выглядеть так:
- редактируем код на домашней девелопмент-машине
- перед уходом на работу выгружаем наш проект на Git-сервер
- находясь на работе, скачиваем последнюю версию своего проекта с Git-сервера на рабочую девелопмент-машину
- редактируем код на работе, перед уходом домой снова выгружаем уже новую версию проекта на Git-сервер
- дома забираем ее с Git-сервера на домашнюю девелопмент-машину и т.д.
- когда же нужно развернуть проект на "боевом" сервере, скачиваем его с Git-сервера на продакшн-сервер
Ниже приведен список рекомендуемого ПО, которое нужно установить перед началом работы и на примере показана последовательность подготовки рабочего места, организации директорий и пр.
0. Подготовка к началу работы
- virtualenv с virtualenvwrapper
- git, заданы позывные (email, username) + есть аккаунт на сервере
- PyCharm
Приступаем к работе над новым проектом под названием django1.
1. Создаем виртуальное окружение для проекта
Неважно, где именно вызвана эта команда — в папке .virtualenvs создасться и автоматически активируется виртуальное окружение django1.
2. Устанавливаем Django и создаем новый проект
pip install django
После установки фреймворка, создаем наш джанго-проект, располагая его в папке projects_dev:
cd ~/projects_dev/
django-admin.py startproject django1
3. Создаем структуру директорий django
└── django1
├── django1
│ ├── __init__.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── manage.py
4. Создаем основное django-приложение
5. Открываем проект в PyCharm
6. Задействуем систему контроля верий — Git
Для этого в среде PyCharm выделяем эту папку и инициализируем в ней репозиторий (меню "VCS > Enable Version Control Integration — Git" — это аналог консольной команды "git init").
После создания репозитория необходимо указать Git, с какими именно файлами ему следует работать, а какие следует игнорировать. Для этого создаем в корневой папке нашего проекта файл .gitignore со следующим содержимым (файл можно создавать прямо в PyCharm):
local.py
Примечание: чтобы не переключаться между окнами, здесь и далее удобнее использовать терминал, встроенный прямо в PyCharm: меню "Tools > Open Terminal…"
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
- установить в систему саму СУБД (для установки PostgreSQL — см. инструкцию);
- настроить Django-проект на работу именно с этой СУБД (инструкция по подключению PostgreSQL — здесь).
Примечание: как известно, Django поддерживает разные СУБД (SQLite, MySQL, PostgreSQL и т.д.). Если мы будем работать с SQLite — то ничего устанавливать и настраивать на данном этапе не нужно, т.к. по умолчанию проект уже настроен на SQLite.
Что такое South? South — это приложение для Django-проектов, которое является альтернативой утилите syncdb. Избавляет от головной боли при внесении изменений в структуру моделей БД. Как известно, штатная утилита syncdb может только создавать таблицы по моделям, но не может изменять их при изменении структуры моделей. Поэтому, когда мы правим код моделей (что в процессе разработки бывает довольно часто), приходится вручную изменять таблицы БД или пересоздавать всю базу. South может автоматически отслеживать изменения программного кода и соответствующим образом обновлять БД.
python manage.py syncdb
Примечание: эту команду нужно запускать, находясь в виртуальном окружении нашего проекта. Альтернативный способ — в среде PyCharm выбрать меню "Tools > Run manage.py Task…". Поскольку syncdb в нашем проекте запускается впервые, система захочет создать суперпользователя и запросит его имя, e-mail и пароль.
После этого в БД автоматически создадутся таблицы, необходимые для работы South, и manage.py станет поддерживать несколько новых команд, которые мы будем использовать в дальнейшем при работе с базами. На этом базовая настройка БД завершена, поэтому можно сделать коммит в наш репозиторий.
Как пользоваться 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-ветке гарантированно будут только рабочие версии проекта, именно они и будут выкладываться на сервер. В процессе разработки необходимо не забывать почаще делать коммиты и выкладывать изменения в удаленный репозиторий на сервере.
О том, как разрвернуть проект из репозитория на продакшн-сервере, будет описано чуть позже.
8 комментариев:
- Анонимный 23 сентября 2014 г., 20:19
Спасибо! Мне, как новичку, прояснили и помогли организовать воркфлоу.
- Анонимный 23 сентября 2014 г., 20:22
>>О том, как разрвернуть проект из репозитория на продакшн-сервере, будет описано чуть позже.
Статья планируется?) - FireGM 26 сентября 2014 г., 17:29
Хорошая статья, спасибо. Очень хочу статью про развёртывание и обновление проекта, после изменение в ветке мастер.
-
-
Отличная статья. Главное, наглядная.
Внутреннее противоречие вызывает один момент: судя по тому, как себя ведёт Django, расположение приложений в папке apps противоречит внутренней логике. По официальному ману приложения создаются через manage.py в той же папке, что и сам manage.Ответы-
-
в принципе дело вкуса. Сейчас я работаю на одном проекте — там все аппы свалены в корневую папку. Проект довольно большой и количество приложений там — 25+. В итоге имеем "колбасу" из папок в корне проекта с маленьким скролликом, которая перемешана с кучей другий папок (settings, static, templates, …) — довольно напряжно это все постоянно листать и отыскивать где там приложение, а где не приложение
-
-
- Анонимный 6 февраля 2015 г., 13:21
Большое спасибо за статью, очень полезная информация в сжатом и понятном виде. С течением времени и обновления Django до версии 1.7 в south нет необходимости, при его применении выдаеться исключение. Теперь его функции интегрированны в сам django, а всё остальное очень актуально. Еще раз большое спасибо и жду следующих публикаций
Поиск
Ярлыки
Обо мне
Полезные страницы
Читатели
Подпишитесь на hexvolt-блог
http://hexvolt.blogspot.ru/2014/05/django-workflow.html
- Автоматическое монтирование fstab и systemd - 24.02.2021
- Как в Linux подключить новый диск, разметить и отформатировать разделы - 24.02.2021
- Как сменить режим работы PHP - 24.02.2021