解释一下
之所以弄成这样要解释一下，这个跟我们的业务形态耦合的很重。 由于我们是TO B的业务，而且大部分情况是进入到客户场地部署的。客户场地会出现各种限制。 例如没有网络，没有root权限，五花八门的操作系统等等。所以就衍生出了部署测试，我们也称后端兼容性测试。所以上图的右边我们的部署镜像有很多个系统版本的。这些是我们跟运维和进场工程师共同协定的标准镜像----基本就是一个官方的OS镜像加少量的工具。同时使用一个普通的没有任何额外权限的用户。目的就是测试产品对各种情况的兼容性。所以才造就了我们的部署包很大，因为依赖都打在了部署包里。 我们部署环境的时候可以选择一个镜像进行部署。
正确的打开方式
1、标准化，docker很适合做标准化。所有环境都是一样的，不会出现什么bug在这个地方能重现，那个地方复现不了的。也能让开发人员尽早发现部署上的bug，例如自己开发的时候不小心用了root权限，这样会很快发现这个bug，因为所有环境里都是没有root权限的。
2、并行化，我可以一个人起N个容器并发编译所有模块增加编译速度，也可以N个人同时起更多的容器并发的部署不同的环境。不会像以前的虚拟机一样一个人编译的时候另一个人就得等着。
3、定制化，标准化之外我们还可以定制化。为不同的角色定制化他们需要的环境。例如产品人员需求稳定可用的环境，我们给他们做蓝绿部署，服务高可用。运维人员需求一个标准镜像直接在线上部署，我们就给他做一个镜像。进场人员需求一个部署包，我们就在部署环境的过程中自动的打成一个大包(上图的汇总容器)放到FTP上，他下载直接带走。开发人员除了日常部署还需要能随时搭建一个老版本的产品(TO B业务的特性)来重现并修复一个bug，我们就对环境部署项目也做多分支策略，保留每个版本的镜像。总之我们可以针对不同的岗位为他们定制化不同的功能。
4、环境编排，当你的环境到达一定数量以后必然就会面临一个问题，一台服务器无法抗住这么多容器运行的压力。所以就会慢慢的变成2台，3台甚至更多。 这时候需要考虑很多东西，例如资源分配怎么搞，怎么确定哪些容器部署再哪个节点上。例如如果一台节点挂了怎么办？难道在它恢复正常之前这个节点上的服务就一直不可用么，是不是要加入recovery机制等等。所以这时候需要引入环境编排机制。一般无非就是在swarm，mesos，k8s，rancher上选了，一般公司没那个精力自研。只是用在测试环境上推荐docker 1.12内置的swarm mode， 之前还分别研究了mesos和k8s， 对于QA来说它们都过于复杂了，需要相当大的学习成本。以mesos来说需要各种其他插件才能正常服务，光是一个服务发现就需要安装一个mesos dns，高可用得维护ZK等等，就算你什么都没要求也得装个marathon，各种配置文件确实也让我这个非运维感觉比较棘手，想搞好它真的需要投入大量精力。而swarm mode所有的东西都已然内置，使用起来很简单方便，至于swarm mode的那些令人诟病的缺点，我们可以忽略了，这又不是生产环境。 当然了，劝告各位QA同僚。。。能不搞集群就别搞集群，能一台机器扛着就一台机器扛着。一但涉及到环境编排，那坑就多了。。。。。。 对swarm mode有兴趣的同学请看我之前发的swarm mode的科普贴
持续集成
以上介绍的所有自动化类型都是要加入到持续集成里的。 我之前写过一篇文章介绍过持续集成，在那里我就说过持续集成是个比较难的东西。它是对团队工程文化的一种考验。是细节的堆砌。你要把上面所说的所有自动化类型都做好，然后开发人员要写好单元测试，团队要设计好的分支模型。具体细节可以翻我之前的帖子，我就不重复的逼逼叨了。
总结
好了，这就是小弟做过的能拿的出手的自动化了，其他各类牛逼的东西不提也罢，我都不专业。
