“最佳实践”非常依赖于上下文,所以我不会声称我的实践是最好的,只是它们对我有用。我主要在小型站点上工作,因此没有多服务器部署、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 部署到已知位置并将该项目的要求安装到其中。
- 整个部署过程,从裸 Ubuntu 服务器 VPS 或 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
repo 根目录和deploy/
子目录中。