«Лучшие практики» очень зависят от контекста, поэтому я не буду утверждать, что мои практики являются лучшими, просто они работают для меня. Я работаю в основном на небольших сайтах, поэтому нет развертываний на нескольких серверах, CDN и т. Д. Мне нужно поддерживать развертывание общего хостинга Webfaction, поскольку некоторым клиентам нужен самый дешевый хостинг, который они могут найти. Мне часто приходится развертывать сайты несколько раз в разных средах, поэтому повторное развертывание по сценарию имеет решающее значение.
- Я не использую pip связки, я устанавливаю из файла require.txt. Я запускаю свой собственный сервер chishop со списками sdists всего, что мне нужно, поэтому в процессе сборки не бывает нескольких точек отказа. Я также использую PIP_DOWNLOAD_CACHE на своих машинах для разработки, чтобы ускорить загрузку среды проекта, поскольку требования большинства моих проектов частично перекрываются.
- У меня есть Fabric сценарии, которые могут автоматически устанавливать и настраивать nginx + Apache / mod_wsgi на Vbu Ubuntu или настраивать эквивалент на Webfaction общего хостинга, а затем развертывать проект .
- Я не использую --no-site-packages with virtualenv, потому что я предпочитаю иметь медленно движущиеся скомпилированные пакеты (Python Imaging Library, psycopg2), установленные на системном уровне; слишком медленный и хлопотный, чтобы делать внутри каждого virtualenv. У меня не было проблем с загрязненными системными пакетами сайтов, потому что я обычно не загрязняю их. И в любом случае вы можете установить другую версию чего-либо в virtualenv, и это будет иметь приоритет.
- Каждый проект имеет свою собственную virtualenv. У меня есть несколько скриптов bash (не virtualenvwrapper , хотя многие его используют и любят), которые автоматизируют развертывание virtualenv для данного проекта в известном месте и установку в него требований этого проекта.
- Весь процесс развертывания, от простой VPS-учетной записи сервера Ubuntu или учетной записи общего хостинга Webfaction до работающего веб-сайта, выполняется с помощью Fabric.
- Сценарии Fabric являются частью дерева исходного кода проекта, и я запускаю их из локальной проверки разработки.
- Мне не нужны SCons (о которых я знаю).
Развертывание
На данный момент новое развертывание разделено на следующие шаги:
fab staging bootstrap (настройка сервера и развертывание исходного кода) fab staging enable (включить конфигурацию Apache / nginx для этого сайта) fab staging reload_server (перезагрузить конфигурацию Apache / nginx).
Конечно, их можно объединить в единую командную строку fab staging bootstrap enable reload_server.
Как только эти шаги будут выполнены, обновление развертывания с новым кодом будет просто fab staging deploy.
Если мне нужно откатить обновление, fab staging rollback. Ничего особенно волшебного в откате; он просто откатывает код до последней развернутой версии и переносит базу данных в предыдущее состояние (для этого требуется записать некоторые метаданные о состоянии миграции БД после развертывания, я просто делаю это в текстовом файле).
Примеры
Я не использовал сценарии Fabric, описанные в этом ответе, в течение нескольких лет, поэтому они вообще не обслуживаются, и я отказываюсь от ответственности за их качество :-) Но вы можете увидеть их на https://bitbucket.org/carljm/django-project-template - в fabfile.py в корне репо и в подкаталоге deploy/.