解释一下
　　之所以弄成这样要解释一下，这个跟我们的业务形态耦合的很重。 由于我们是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的科普贴
　　持续集成
　　以上介绍的所有自动化类型都是要加入到持续集成里的。 我之前写过一篇文章介绍过持续集成，在那里我说过持续集成是个比较难的东西。它是对团队工程文化的一种考验。是细节的堆砌。你要把上面所说的所有自动化类型都做好，然后开发人员要写好单元测试，团队要设计好的分支模型。具体细节可以翻我之前的帖子，我不重复的逼逼叨了。
　　总结
　　好了，这是小弟做过的能拿的出手的自动化了，其他各类牛逼的东西不提也罢，我都不专业。
        转载：https://testerhome.com/topics/7271