测试开发之路–环境管理

背景

他姥爷又来了，他姥爷又忍不住寂寞打算码字了。 今天他姥爷想聊聊环境的问题。因为这里面有很多的坑，环境管理的好能让生产力翻倍，管理不好会团队痛苦不堪。这个是我的感受。记得也就3个月前吧，项目刚启动。开发，测试，产品都在使用同一套环境。是每个模块的开发人员出一个人临时糊出来的环境。我们有个习惯就是每个迭代结束后都开一个总结会，记得那时候大家抱怨最多的就是环境了。这么多人公用一套环境，难免互相影响，一会这个服务要重启，一会那个服务因为哪个bug挂了。再搭建几套环境也不现实，系统太复杂了，暂时没人能独立搭出来，维护的成本也太高。反正那时候大家都挺痛苦的。正好那时候基本没开发出什么功能，我还比较闲。而且本来我就在研究CI的方案，正好涉及到环境部署的问题。于是就想换个思路，以前做自动化部署大多是给测试人员服务的，这次给所有人定制环境。让每人都人手一套自己的环境。于是就这么干下去了。

准备工作

万事开头难，整合所有模块的部署细节往往是苦难的。因为这时候还没有配置管理，所有配置都是散落在各个不同的目录里。而且可能会变化。反正这时候就克服一下，以后有了配置管理方案就好了。

技术选型

谈到环境，首先想到的就是自动化管理。我们之所以只占用一个QA很少部分的时间就支撑起20多套产品环境，依靠的就是高度自动化。一般自动化部署要么就是传统的脚本驱动模式，要么就是虚拟化技术。我选择了docker，有多方面的原因吧：

• 一个是公司本来就是用docker搭建的基础服务，大家对docker也都熟悉了，起码使用上没什么障碍了。
• 二是我希望给每个人都搭建一套独立的环境，未来可能起几十个甚至上百个环境，所以传统的脚本模式就不行了，新建环境成本太高，要解决很多依赖问题。而且产品中有几个模块的语言是node.js，scala，c++。都是编译时间长的典范，用传统的脚本驱动搭环境感觉一定会慢的像蜗牛。换成docker就很好了，首先由于虚拟化技术，做好镜像以后我们就没有依赖问题了。同时分成几个容器去部署不同的模块也可以加快部署时间。
• 三是对资源的利用，docker本就是以轻量级和使用方便闻名。搭建这么多环境，我觉得也就只有docker能把资源利用到最好了。不会搭建个几套环境就把资源占满。

成型的结构图

画的不好大家见谅。每一个模块都是一个容器，每套环境都有独立的数据库，共用一个hadoop集群和config server。但是有一个容器装了单机版的集群做备用，以防万一。记得第一次启用的时候，一下子开了13套环境（这个数字还真不吉利。。。），到现在将近30套。基本做到了人手一套环境。其中细节不表了，有兴趣的学习一下docker吧。总之多语言构成的产品比较麻烦，每种语言在部署的时候都或多或少的有些问题

开发环境定制

一开始就说了，环境不仅是给测试人员用，还要给开发人员用。于是就需要定制一些东西满足开发人员的要求。为了满足开发人员的需求就必然跟传统CI中的环境部署冲突。传统的测试环境部署方式一般是下面这样的：

这样的部署方式有一个问题，环境中可能只有一个部署的jar包。也许这对测试人员来说足够了，能看log就行。 但对于开发人员来说就有诸多不便。我们发现开发人员很喜欢在环境中直接编译源文件做开发。有时候可能fix一个bug很简单，直接在环境中编译一下重新启动服务就试一下了。 这比写代码，push，merge，重新拉取代码，重新部署要快速简便的多。我们开发人员大多都用idea，大多都配置了remote debug。所以只有一个jar包肯定是不行的。我们要在环境中保持一个完整的开发环境，例如完成的项目的git目录，git client，ssh，mysql client，local 编码设置等等等等。同时要有很方便的方式重启服务，不能让开发人员在重启服务的时候那么麻烦的走重新启动容器，拉取代码等等这一套流程。那么解决方案是：

• 抛弃编译服务器，直接在容器内编译，启动服务。做法也很简单，使用docker的entrypoint机制。在启动容器的时候拉取代码，编译并启动服务。
• 在基础镜像中安装git client，ssh，mysql client等等等服务
• 定制好各种重新启动服务等等的方便的功能性脚本。反正能自动化的就自动化起来。

测试环境定制

测试环境跟开发环境又有一点不一样。 我们在测试环境中最怕的是什么？ 部署一个环境的时候发现连冒烟测试都过不去。bug直接block测试流程，这时候只能等着开发修好bug再重新部署了。这很影响效率。 对于产品人员呢？ 也一样的，产品人员有时候要跟老大，要跟客户演示，因为客户可能会来公司的。产品人员要演示最新的功能。但最新的功能可能还没有发布。需要在公司内找个环境演示。 所以不论是测试人员还是产品人员，都有一个稳定环境的需求。但其实我们避免不了bug的，我们部署一次环境的时候难免当时就有什么严重的bug。解决方案一般有两个，一个是把以前的部署的包做备份。另一个是学运维在线上的策略–蓝绿部署。 我选择了后者，所以测试环境的结构就变成了下面这个样子：

两套环境共用一个数据库和集群。 开发人员在提测的时候部署在stable1， 下一次部署的时候我们就部署在stable2。如果stable2是有问题的，例如冒烟测试没过。那么就切换回stable1测试。stable2就打回去让开发修bug。如此循环往复。我们保证始终有一套环境是可用的。

线上部署的定制

通过刚才的介绍我们发现我们是没有编译服务器的，我们在各自的容器里自行编译。这时候运维的同学就比较蛋疼。因为他们需要部署包来在线上或者进场进行部署。而我们的产品是比较复杂的，多语言构成的产品。让运维同学再搞一套编译服务器来生产部署包的成本也比较高。所以我跟运维的小伙伴商量了一下，还是复用我们现有的东西。其实就是我们新加了一个脚本。在已启动的经过测试的容器中把部署包copy出来。也就是说，我们的环境被当成了编译服务器

配置管理

这个东西单独拿出来说是因为它比较重要，我们在没有配置管理方案之前，部署是很痛苦的。因为配置文件散落在各个地方，掌握这些信息的成本太高，而且十分不利于扩展。增加或者修改配置的结果往往都是要更改docker的镜像并让所有人重新部署环境。所以大家在做环境管理的时候，一定要先推配置管理方案。否则你会痛苦死。这是血淋淋的教训。

总结

暂时就分享到这吧，其实我们做的还有很多不足，毕竟我们的项目才成立了几个月，好多东西不完善。现在docker的容器都是跑在一个机器里。之后一旦环境多了，肯定把docker做成集群。还有一些镜像的减肥，脚本的优化，环境自检的机制等等都需要完善。这里就当抛砖引玉了。大家晚安，俺陪媳妇睡觉去了

,