自动化持续部署号称持续集成最后一公里，对整个持续集成过程有很重要的意义。而且即使是非持续集成的团队，同样需要部署，需要快速上线。那么对于这个Topic来讲，问题域有多大，难点在哪里~今天 Ulric 来简单侃一侃，如果有说得不对或不全面的地方，欢迎指正，大家共同学习进步哈~~
俺们不是Hacker，俺们是工程师，工程师主要来解决工程问题，那么对于部署这个问题，典型场景大概如下~
1、本次有几个php文件修改了需要上线，因为php的每个请求过来都是重新初始化所有资源的，所以也不用重启服务，直接把文件替换喽就可以
2、有个java写的webapp，已经打好包了，放在了ftp://host/path/to/source.tar.gz，把他下载下来替换/home/worker/webapp/xxx目录下的应用，不过需要先停服务，上完文件之后再重启一下
3、新写好了一个so文件，只想上线这一个文件，需要先把原来的so文件删除（之前已经load到内存了，删除不会影响服务），然后再把这个新的so文件上上去，最后把服务restart一下
4、上次上线的程序没有开开关，这次只上线一个配置文件，把开关打开，然后reload一下程序即可
5、线上跑的是v2版本，服务所在目录为/home/worker/webapp/xy_v2，同时在/home/worker/webapp目录下有个软链xy->xy_v2，这次上线v3，先把文件上线到/home/worker/webapp/xy_v3目录，然后修改软链xy->xy_v3
6、擦，刚才上线的v3版本有bug，立马给我回滚，回滚版本的上线只是到目标机器上跑一条命令：把xy这个软链重新链到xy_v2上面即可
7、咱们总共有1万台服务器，这次想做个调研，看看哪种策略比较好，把其中300台单独上线一个v5版本，剩下的9700台上线v4版本
8、产品经理最近思路老活跃了，又想出了3个新feature，分30%（每个feature引入10%的流量）的流量给他验证一下想法
9、咱们的服务用的人越来越多了，得扩容200台机器，这200台机器上面很干净，啥都没有，咱们服务run的时候依赖的lib库需要上线过程一起安装好，奥对了，咱的服务还依赖于服务A和服务B，需要把他们也一起安装了啊
10、上游模块挖掘出来的数据咱们需要用一下，大约120G的数据，上线的时候得把这些数据上线到/home/worker/webapp/xxx/data目录下啊
11、上次上线那么大的数据太慢了，咱们先把数据提前分发到机器的某个临时位置，真正上线的时候直接从本地mv吧
12、哥今天比较郁闷，遇到一个模块在各个机器上面的配置都不一样，有30台机器呢。。。肿么办。。。
13、TMD，没有恶心只有更恶心，新模块有的需要在一台机器上面部署多个实例，而且每个实例的配置也不同。。。
。。。。
上面需求的直接来源是产品线研发工程师，我们作为部署发布工程师，需要接纳这些零零散散的部署需求各个击破，亲爱的看客，你想到解决方案了没？