Джанго + SVN + Развертывание

Question

Я сильный сторонник контроля версий и начинаю работу над проектом Django.Я сделал несколько раньше и попробовал несколько разных подходов, но я еще не нашел приличную структуру, с которой я действительно чувствую себя комфортно.

Вот что я хочу:

a) Исходный код проверен на контроль версий

b) Предпочтительно среда не проверяется на контроль версий (что-то вроде buildout или pip needs.txt отлично подходит для настройки среды)

c)Разумная история «получи нового разработчика»

d) Разумная история развертывания - желательно, чтобы вся среда развертывания могла быть сгенерирована скриптом на сервере

Мне кажется, что кто-точтобы сделать это раньше, но многие часы поиска привели к полуобожженным решениям, которые на самом деле не решают все эти проблемы.

Есть мысли о том, куда мне смотреть?

Answer 1

Посмотрите на фабрика для управления развертываниями.

Это то, что я использую для управления серверами / развертываниями с фабрикой: Луи (это просто коллекция фабрикикоманд).Я сохраняю louisconf.py файл с каждым проектом.

Я бы рекомендовал использовать распределенную VCS (git, hg, ...) вместо svn.Причина в том, что простота ветвления позволяет использовать несколько схем развертывания.Вы можете иметь, например, ветви production и staging.Затем вы обязуетесь, чтобы единственное слияние с производством происходило в соответствии с соглашением.

Что касается быстрого начала разработки, у вас все в порядке с pip и needs.txt.Я думаю, это также означает, что вы используете virtualenv , но если нет, то это третья часть.Я бы порекомендовал получить базовый README на месте.Поручите каждому разработчику, который присоединится к проекту, первым делом обновить README.

. Грубый способ привлечь кого-то к участию в проекте - получить ее код проверки, создать virtualenv и установить требования.

Я бы порекомендовал иметь файл settings.py, который работает с sqlite3 и такой, чтобы новый разработчик мог использовать его, чтобы быстро начать работу (т.е. после установки требований).Однако то, как вы управляете различными файлами настроек, зависит от макета вашего проекта.Для новых разработчиков должен быть некоторый набор настроек по умолчанию.

Answer 2

Я храню каталог проектов / в моем домашнем каталоге (в Linux).Когда мне нужно начать новый проект, я делаю новый каталог с коротким именем (который достаточно описывает проект) в проектах /;это становится корнем нового virtualenv (с --no-site-packages) для этого проекта.

Внутри этого каталога (после того, как я установил venv, поставил его и установил копию django I)Я буду работать с), я "django-admin.py startproject" подкаталог, обычно с тем же коротким именем.Этот каталог становится корнем моего репозитория hg (с быстрой инициализацией hg и ci), независимо от того, насколько мал проект.

Если есть шанс поделиться проектом с другими разработчиками (проект для работы, дляпример), я включаю pip needs.txt в корень репо.Только требования проекта входят туда;Например, django-debug-toolbar и django-extensions, главные элементы для моего рабочего процесса dev, не являются требованиями проекта.Юг, когда мы его используем, равен.

Что касается проекта django, я обычно сохраняю файл settings.py по умолчанию, возможно, с некоторыми изменениями, и добавляю соглашение local_settings в конец его (try: from local_settings import *; except ImportError: pass).Настройки среды моего и других разработчиков (например, добавление django-extensions и django-debug-toolbar к установленным приложениям) идут в local_settings.py, который не зарегистрирован для контроля версий.Чтобы помочь новому разработчику, вы можете предоставить шаблон этого файла как local_settings.py.temp или другое имя, которое не будет использоваться для каких-либо других целей, но я считаю, что это излишне загромождает репо.

Для личных проектов я обычно включаю README, если планирую опубликовать его публично.На работе мы поддерживаем среду Trac и хорошую коммуникацию, чтобы ускорить разработку новых проектов в проекте.

Что касается развертывания, как уже упоминалось, я слышал, что фабрика действительно хороша для такого рода локальных / удаленных сценариев.хотя я сам не воспользовался случаем, чтобы разобраться в этом.

---

Для непосвященных типичный сеанс оболочки для этого может выглядеть следующим образом:

$ cd ~/projects/
$ mkdir newproj
$ cd newproj/
$ virtualenv --no-site-packages .
$ source bin/activate
(newproj)$ pip install django django-debug-toolbar django-extensions
... installing stuff ...
(newproj)$ django-admin.py startproject newproj
(newproj)$ cd newproj/
(newproj)$ hg init .; hg ci -A -m "Initial code"