在日常测试工作中，有个必不可少的环节的便是环境的部署搭建，而在微策略各项产品的测试环境部署过程中，除开各自产品的服务以外，最必不可少的就是微策略的核心产品 – 智能服务器Intelligence Server了。
过去在安装Intelligence Server时漫长的等待时间不忍再提，如今容器化后的Intelligence Server镜像，完成启动需要的时间是 --------- 不到3分钟！！！
以PL-SDK-CTC团队的RESTful API产品admin-rest为例，测试过程中需要的服务有：admin-rest Server和Intelligence Server(iServer), 而搭建这些容器化的服务总共需要花的时间，显而易见，不到3分钟！
实际上，我们最终完成部署需要的时间是7～10分钟，原因却是，测试对象太多了，元数据库(Metadata Database – MD)太大了 – 580MB，在VRA远程机器中还原一个全新干净的mysql MD需要5～7 分钟（比iServer慢这么多，我们需要检讨 ）。
话说回来，容器化部署给我们带来的好处是什么? 一个字, 快 效率！
- 元数据库脏了，换！
- 开发有新的版本，换！
- iServer有新的改动，换！
- 回归测试指定的版本，换！
- 测完的这个branch，还要测那个branch，再测另一个branch（别问为啥要切branch，都是泪），换！换！换！
- 我想测Library了，也能换！
试想，这种种环境的切换，如果回到容器化以前的情景，如何快得起来，简直不堪回首 。。。
具体实践
话不多说，咱们来看看具体如何实操吧。到了今天，想必大家也熟悉微策略官方的容器化部署Tanzu了吧，跟Tanzu的高大齐全相比，我们的就是短小精悍了。
同样使用了helm来管理charts，我们只需要部署我们产品依赖的服务，这也是为什么我们能这么快的原因。
首先，我们需要一个运行测试脚本的镜像(image)，我们的测试脚本使用的是基于ruby的cucumber框架，是以，我们只需要一个安装有指定版本的ruby的基础镜像便已足够。
在后续运行过程中，我们将通过Gemfile来安装各种需要的库。
使用镜像的好处在于，我们能很好地屏蔽脚本环境不一带来的干扰，确保脚本每次运行都能跑在相同的环境里，这对我们排查问题非常有帮助。
在需要运行脚本时，只需要执行docker exec -it /bin/sh -c "cucumber features/ -r steps/"即可，一步解决，简单易用。
然后便是我们要测试的服务，还是以admin-rest为例，要搭建一个“自产自销”的镜像，也只需要简单几步：
再者，便是Intelligence Server以及数据库mysql的镜像，通过helm charts的编排管理，我们就可以快速顺利地部署一个满足测试所需的kubernetes单点集群了。
通过执行安装命令helm install test helm/admin-rest, 不到8分钟，出锅了！
emm…… 眼尖的同学已经发现，我们队伍中好像混进了什么东西。
没错，就是你(nee)! ！(谐音梗，扣钱！！)
咳咳，言归正传，容器化部署带来的另一个好处，就是，插拔特～方便。
admin-rest测试过程中需要用到其他的服务，直接加上就是：
- NEE(new export engine) Server, 加上！
- Modeling Service, 加上！
- 之前提到的Library，换上！
我们团队其实还负责了embedding SDK的产品，这个产品是偏前端的，与admin-rest难以兼容，而维护多套测试框架对我们来说可是不小的成本。
所幸，有了容器化部署，我们只需要用Library换掉admin-rest，再加一个远程selenium server的镜像(selenium-docker安利一下啊，能跳，能唱，能rap，能远程，能并行，提供最新版本浏览器Chrome ｜ Edge ｜Firefox。咳咳，Safari你走开！) ，我胡汉三又回来啦！！
One more thing
忘了还有个好处了，容器化的部署哪儿都能放，可移植性不要太好，我们同样的部署老早已经放到持续集成(CI)上去了，出个build跑个测试，美滋滋啊。
结语
基于团队各自需求，我们可以从丰富的微策略产品里随意组合，搭建自己想要的测试场景，还可以对每个容器作出自己想要的定制化需求。
在此，感谢微策略的所有团队(特此铭谢DevOps团队)为容器化部署作出的贡献，让我们能搭上这趟顺风车，撒花～
点击关注可以了解更多微策略最新动态，行业资讯以及程序员日常
,
