诞生之初

事情还得从头开始说起，从那些自动化的fabric文件开始，也从我刚入职搜狐负责手机搜狐开发开始说起。我参与开发的时候项目的部署已经是自动化了，不过并没有抽象出一个工具来。那会儿主要由两个项目，一个基于tornado，一个基于Django。两个项目都有各自的发版方法，但逻辑基本一致。

两个项目的上线流程都是先打包（py的源码包），然后在通过内部的pypiserver安装到各个服务器上，由supervisord启动、管理。

随着业务的发展，新的项目逐渐多了起来。这时一个新的项目开发流程是这样的：先从就项目中把fabfile（fabric的配置文件）和supervisord配置文件以及setup.py文件拷贝过来，然后再往里面填源码。流程依然是一致的。

这就是一开始的状态，混沌中带着那么一点秩序。

开始造轮子

说起来，程序员都是十足的懒人。这样copy的方式多少让自己都有点不忍直视，于是 @熊总 建议我们不如造这样一个轮子，让所有的项目都能在这上面滚起来。于是把这个造轮子的任务交给我来做，刚好我也是懒人一个，于是很happy的开始了。

要造一个通用的轮子，必然是要把项目中用到的部分抽象出来，哪些部分是通用的呢，这只有深切参与到项目的开发和部署中才能体会得到。刚好在那段时间之前，我也参与了修改bug，打包，部署上线的过程，包括copy那些打包的脚本和配置文件。

有了上面的经验，只要把必需的东西输出就行了。总结了一下，当时项目的打包和上线涉及到这几个方面：:

1. 打包 —— 生成版本号，渲染setup中的版本和项目信息，然后放到pypi server的packages目录下
2. 虚拟环境 —— 在新的服务器上创建虚拟环境
3. 安装项目 —— 从pypiserver安装项目到虚拟环境中
4. 启动supervisord —— 管理项目进程
5. 切换nginx配置 —— 我们有两套环境在线上同时运行，可以称为a环境和b环境，主要用于上线以及线上突然出现问题时回滚

细分的话就上面五个步骤，不太理解的可以去看看我们的essay说明。也就是只要满足了这些功能，那么这轮子就算是完成了。另外还考虑到为了便于新项目的开发，还需要能自动创建具备这些功能的项目模板。这其实是最主要的痛点，总是拷贝什么的最没技术含量了。

于是添加了创建项目并且初始化模板，然后还能初始化到gitlab或者github上。

这样的工具俨然是项目开发部署、居家旅行之良品。

争论之处

需求明确之后，怎么组织项目的代码呢，对于正常的web项目来说，没有啥难度的，都有固定的模板。对于这个工具类的东西，还是第一次考虑，怎么设计才能更合理——易扩展、易维护。在翻了好久django的源代码之后，我开始按照一个core，然后一些tools的思路开始码代码。

我的考虑是，这个工具应该有一个核心的功能，然后是周围的一些辅助工具。遗憾的是，这种思路最后还是被推翻了。熊总的意思是应该参考linux的pipeline来设计，所有的功能都应能单独拿出来。于是底层的工具模块都按照这个逻辑被他重写了（so，如果你们觉得那部分代码有槽点尽管吐好了，我不介意的，^_^)。

代码结构的争论还好些，基于经验就能看出哪种更好。但是一些逻辑的设计却不是经验能得到的，就像软件开发没有银弹一样，各自的业务场景都不同，没有统一的解决方案。

另外一个争执的点是部署方式。如果你已经看了我们的文档，或者已经理解了上面的部署方式。你可能已经疑惑了：“为毛你们不直接用git部署呢?还可以打tag什么的。” 这也是我们之前在考虑的问题。

摆在我们面前的有两条路，一条路是用git来部署代码，另外一条路是用pip install项目包来部署。我们选择了后者。原因是这样的：:

1. 历史原因 —— 之前的项目一直在用这样的方式
2. 服务器配置的成本 —— 这个我觉得是最主要的，对比两种方式，git部署的话服务器要统一安装git环境，但是我们申请到新的服务器没有这东西，我们得自己安装；另外还有一个包依赖的问题。而使用pip的方式安装，不需要做多余的处理，新来机器，给了ip，直接就能部署上去。

大概就基于上述的两个原因，选择了用pip install的方式来部署了。有什么没说到得地方，有同事路过留言补充下吧。

开放的初衷

有了上面的过程，也就产生了这么个工具： essay 。在项目完成之后，后面的时间里我们划分了不同的组，又开始负责新的项目。这个工具算是一直在我们的项目开发中起着重要的作用。我们觉得这个工具算是我们在过去一年多中开发和部署经验的总结，开放出来应该会有些价值，无论是对于开发者还是对于团队。

我自己是在这个工具的开发过程中学到很多东西，我想任何一个渴望了解项目从开发到部署整个流程的开发人员都应该能从中有所收益。

开放的目的除了分享经验，还有一个重要的作用就是交流。我们所积累的经验在业内并不一定是最佳的，肯定还有更多更好的解决方案，而这些东西都要来源于交流。这样才能相互促进，而相互促进才是开放和开源的初衷。

项目地址： https://github.com/SohuTech/essay

补充一些数据

手机搜狐网（m.sohu.com)每天有几亿的PV，在这样的情况下，发现线上bug，一般情况下从修复bug到上线不会超过15分钟。并且在上线的时候用户是不会感觉到页面访问慢或者打不开的。在新功能点或者bug多的情况下，一天上线十几个版本的情况也是有的。每次上线都不会对用户造成影响的关键在于我们部署了a，b两套环境。

之前在我参与手机搜狐网开发时后台有100多台虚机，在遇到热点事件的时候会扩充一倍。在这种情况下，新功能上线的过程我印象中不会超过5分钟，如果关闭fabric的success的console输出以及开启并行模式，发布的速度会更快。