Лучшие практики разработки/развертывания Django и VirtualEnv

Question

Просто любопытно, как люди развертывают свои проекты Django в сочетании с virtualenv.

• Более конкретно, как обеспечить правильную синхронизацию рабочей виртуальной среды с вашей машиной разработки?

Я использую git для scm, но у меня нет виртуального окружения внутри репозитория git. Должен ли я использовать заморозку pip, а затем заново создать среду на сервере, используя вывод заморозки?(Если вы сделаете это, не могли бы вы описать шаги — я нахожу очень мало хорошей документации по процессу размораживания — что-то вроде pip install -r freeze_output.txt возможный?)

Answer 1

Я только что установил что-то подобное на работе, используя pip, Fabric и git.Поток в основном такой и во многом заимствован из этот сценарий:

1. В нашем дереве исходного кода мы храним файл require.txt.Мы будем поддерживать это вручную.
2. Когда мы выпускаем новый выпуск, сценарий Fabric создает архив на основе того древовидного кода, который мы ему передаем.
3. Fabric найдет SHA для того, что мы развертываем. git log -1 --format=format:%h TREEISH.Это дает нам SHA_OF_THE_RELEASE
4. Fabric получит последний SHA для нашего файла требований с помощью git log -1 --format=format:%h SHA_OF_THE_RELEASE requirements.txt.Это выдает короткую версию хеша, например 1d02afc который является SHA для этого файла для этой конкретной версии.
5. Затем сценарий Fabric проверит каталог, в котором хранятся наши виртуальные среды на удаленных хостах.
   1. Если нет каталога с именем 1d02afc, новый виртуальный окружение создается и настраивается с помощью pip install -E /path/to/venv/1d02afc -r /path/to/requirements.txt
   2. Если здесь является существующий path/to/venv/1d02afc, ничего не делается

Маленькая волшебная часть этого — передать любое дерево, которое вы хотите получить, и заставить его выполнить упаковку (из Fabric).Используя git archive my-branch, git archive 1d02afc или что-то еще, я гарантированно установлю нужные пакеты на свои удаленные машины.

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

Answer 2

Я использую этот bootstrap.py: http://github.com/ccnmtl/ccnmtldjango/blob/master/ccnmtldjango/template/bootstrap.py

который ожидает, что это каталог под названием «требования», который выглядит примерно так: http://github.com/ccnmtl/ccnmtldjango/tree/master/ccnmtldjango/template/requirements/

Есть файлы apps.txt, libs.txt (который включает в себя файл apps.txt — мне просто нравится хранить приложения django отдельно от других модулей Python) и каталог src, который содержит фактические архивы.

При запуске ./bootstrap.py он создает виртуальную среду (удаляя предыдущую, если она существует) и устанавливает в нее все из требований/apps.txt.В противном случае я никогда ничего не устанавливаю в виртуальную среду.Если я хочу включить новую библиотеку, я помещаю архив в требования/src/, добавляю строку в один из текстовых файлов и повторно запускаю ./bootstrap.py.

bootstrap.py и требования проверяются в системе контроля версий (также копия pip.py, так что мне даже не нужно устанавливать ее где-либо в масштабе всей системы).Сам virtualenv - нет.Скрипты, которые у меня отправляются в производство, запускаются ./bootstrap.py на рабочем сервере каждый раз, когда я отправляю.(bootstrap.py также делает все возможное, чтобы гарантировать, что он придерживается Python 2.5, поскольку это то, что у нас есть на рабочих серверах (Ubuntu Hardy), а на моей машине разработки (Ubuntu Karmic) по умолчанию используется Python 2.6, если вы не будете осторожны)