“最佳做法”非常依赖于上下文，因此我不会声称自己的做法是最佳的，只是说它们对我有用。我主要在小型站点上工作，因此不需要多服务器部署，CDN等。我确实需要支持Webfaction共享托管部署，因为某些客户端需要他们能找到的最便宜的托管。我经常不得不在不同的环境中多次部署站点，因此可重复的脚本部署至关重要。

• 我不使用pip捆绑包，而是从requirements.txt安装。我确实使用sdists来运行我自己的chishop服务器，因此构建过程中不会出现多个单点故障。我还在开发机器上使用PIP_DOWNLOAD_CACHE来加快引导项目环境的速度，因为我的大多数项目需求都有很多重叠之处。
• 我拥有Fabric脚本，这些脚本可以在Ubuntu VPS上自动设置和配置nginx + Apache / mod_wsgi，或者在Webfaction共享托管上配置等效的脚本，然后部署项目。
• 我不将–no-site-packages与virtualenv一起使用，因为我更喜欢在系统级别安装缓慢移动的已编译软件包（Python Imaging Library，psycopg2）。太慢且麻烦，无法在每个virtualenv中执行。我对受污染的系统站点程序包没有遇到麻烦，因为我通常不会污染它。而且在任何情况下，您都可以在virtualenv中安装其他版本的文件，并且它将具有优先权。
• 每个项目都有自己的virtualenv。我有一些bash脚本（不是virtualenvwrapper，虽然很多人都喜欢并喜欢它），这些脚本可以自动将给定项目的virtualenv部署到已知位置，并将该项目的需求安装到其中。
• 使用Fabric对从裸Ubuntu服务器VPS或Webfaction共享托管帐户到运行网站的整个部署过程进行脚本编写。
• 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。在回滚中没有什么特别神奇的；它只是将代码回滚到上次部署的版本，并将数据库迁移到先前的状态（这确实需要记录一些有关DB部署后迁移状态的元数据，我只是在一个文本文件中进行此操作）。

例子

几年来我都没有使用过此答案中描述的Fabric脚本，因此它们根本没有维护，我对它们的质量不承担任何责任:-)但是您可以在https://bitbucket.org/carljm上看到它们/ django-project-
template-在fabfile.py回购根目录和deploy/子目录中。