之所以想写这篇文章，就是因为涉及到正好需要设计到部署线上生产环境的问题。线上生产环境一般要求比较严，比如说我现有的生产环境基本上是比较严格的内网环境：办公网隔离，无法直接从外网下载任何文件，这给本来需要大量依赖环境的Python部署带来了很大的麻烦。
之前360公开了一部分他们在Python环境中的一些经验[1][2]，这些东西非常值得我们学习。虽然我非常期待有3，但是，起码现在看起来还是没有的。
但是实际上，我在实际操作过程中遇到的环境也远比文章中简单提到的也更为复杂。
首先，在文章中提到的私有pypi环境在我现在的线上生产环境中并不存在，起码在询问了一遍周围也没有确定的答复，因此很多依赖库都无法通过简单的pip或者easy_install部署。否则使用包管理部署，可以让操作更加简便，具体可以参考我在《使用镜像服务器加速你的Python PyPi》中提到的方法。
其次，由于没有pypi环境，因此也很难通过简单的python distribute实现分发。尤其是Web Service导致有大量的依赖，包括大量的C扩展，都是需要解决的问题。
所以我采用的方式是使用virtualenv包部署方式。
virtualenv可以提供一个相对虚拟的沙盒环境，之所以说是一个相对虚拟的沙盒环境，是因为这里面是有一些坑存在的，这些坑目前我发现了一下，还有一些没有遇到，如果遇到了再说吧。实际上virtualenv环境是直接可以打包上传的，前提是你需要一个和线上生产环境相同的环境（为什么相同，因为需要避开一些坑）。除此之外，最好使用和线上环境相同的权限和路径配置，这样会方便定位和解决问题。
多余的话不多说，相信大家想想就明白了：通过源代码管理工具（项目部署需求，生产环境是可以访问如CVS、SVN或GIT一类服务的），将工具部署至线上环境。通过持续集成或者简单的SVN Hook/Git Hook实现自动化环境配置。
那么接下来，让我们谈一谈坑吧：
1. virtualenv非是万能药，对环境依赖。最常见到的应该是C扩展依赖的一些so文件或者程序文件。这也是我前面为什么强调和线上生产环境最好相同的原因。若有这方面的问题，比如libc版本不对，估计大概只有哭的份了（笑）。
2. 自动化部署限制：脚本一定要经过严格验证，对相关变量尽量进行集中化控制，减少硬编码路径的存在。
3. 服务器选择。这个问题很奇怪，我在生产环境部署一遍才发现，原来需要root权限才能启动nginx，这个以前都是root跑的。还真没注意过。最初打算使用Gunicorn，但是发现不能自动reload，增加程序fu’za’duuWSGI虽然需要编译，但是说回来，他的autoreload的功能还是非常好用的，尽管不太可能经常reload，但是也减少了很多成本。Gunicron
参考文章：