Подтвердить что ты не робот

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 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, он создает virtualenv (вытирая предыдущий, если он существует) и устанавливает все из требований /apps.txt в него. В любом случае я ничего не устанавливаю в virtualenv. Если я хочу включить новую библиотеку, я поставил tarball в требования /src/, добавлю строку в один из текстовых файлов и снова запустил. /bootstrap.py.

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