关于开发测试环境管理，阿里专家说，“每位开发者都应该得到独占且稳定的测试环境。” 我们跟了。

本文回顾了从十个人共享一台服务器，到每个人可5分钟自助申请到一套完整的与线上环境一致的测试环境的过程。 

十个人共享一台服务器进行测试

在笔者带领一个初创团队开始测试工作时，因为硬件资源有限，整个小组只分配到了一台服务器可以进行测试活动。为了避免让环境问题成为阻碍测试进度的障碍，需要找到一个方案能让所有人能按需使用这台服务器进行测试，而不需要考虑环境和数据的冲突问题。而方案本身也非常简单，就是为每个人分配一个系统用户和一套端口，利用用户和端口隔离环境资源进行环境共享。这样，每个人都可以部署一套被测环境进行测试。而在测试过程中彼此之间互不影响。而由于每部署一个系统，需要十几个TCP/UDP端口，为此专门写了一个脚本来进行端口偏移，也就是为每个用户来指定一套专用的端口号。

利用这个方案，团队平稳度过了硬件资源匮乏的草创期。之后虽然硬件资源有增加，也是沿用这个方案以提升环境资源的利用率，直到测试环境被虚拟化。

一台VM扛下了所有，如果不行就2台

 对于业务系统的开发、测试工作来说，环境的制备就复杂很多。即使是在早期，也有几十套不同的系统。在开发一个新系统或者对某个既有系统进行改造时，不可避免会对其它系统进行调用。系统和系统之间存在依赖关系。而最终，这些系统的数据又会落到各个数据库中，对于Oracle来说，就是N个schema。于是，就有同学提出了开发测试模板机的方案。也就是由测试部门来维护一台虚拟机，在业务系统版本上线之后，有专人将这些版本连同基础数据一并部署到这台VM上并发布到云管平台上。其他开发、测试用户只要通过云管平台就可以自助克隆该VM以获得一套与包括了所有线上应用系统、且基线一致的开发测试环境，并且也包括了必须必要的测试铺底数据。由于早期的业务系统以单体架构为主，拉起各个系统的资源消耗并不大，通常测试时也不是需要拉起所有系统，因此单台虚拟机能够很好地支撑开发、测试的需要。

也就是说，如果有100套开发测试环境的需求，则只要申请100台VM即可。高峰时期，整个云管平台上有几百台此类的VM在运行。

一台不行就2台

 在现今，随着XC工作的深入，各种CPU + OS + DB的组合也让一台VM不再能满足需求，因此一套环境可能需要多个VM来组成。不过这个变化带来的冲击还只是一种横向扩展。更大的变化来自于业务系统的云原生化。

一个K8S集群承载100套环境

随着云原生时代的到来，业务系统逐渐容器化并上云。这个过程对于开发测试环境服务提出了新的要求。

 线上环境由于管控要求，被划分成了彼此隔离的区域。区域之间通过网关(envoy，白名单控制)进行通信，同一区域内的微服务则可以彼此直连通信，不需要经过网关。

此外，虽然业务系统逐渐迁移到了K8S，需要提供相应的开发测试环境, 但是前端、中间件、数据库以及部分系统还都未容器化。在开发测试环境，后面这些系统还依旧以VM的形式存在，继续使用着模板机服务。因此，一套完整的环境就需要整合大几十个在K8S中的微服务以及其它在一个或者多个VM中的系统，彼此之间还需要按照线上系统网络区域隔离的要求进行通信（某个namespace模拟某个网络区域，类似一个海洋上的群岛。多个群岛之间的点对点（envoy网关）飞机航线，群岛内部水路交通（直连）。复杂度又一次提升了。 

（这里吐槽一下豆包生成的图）

通常大家所熟悉的K8S 多副本部署等都是以一套环境为假定条件的。如何在一个K8S中为每个开发人员整出1套环境，各个环境之间彼此流量和数据互相隔离，而环境内部的各个应用之间可以互联互通，则需要解决如配置中心、网关等底层服务的基础配置，而这些配置又往往依赖于数据库。因此在环境申请时，额外加入初始化和容器云namespace和虚拟机VM联动的配置。

因此最终的解决方案是：提出了虚拟的K8S namespace group的概念。

一套环境（ group ID ）= 若干个namespace下所有工作负载 + 某（几）台 VM 中所有系统

基线环境维护

VM基线环境维护：VM基线环境通过部署平台进行人工维护，每周将本周内上线的版本按照上线顺序进行部署，如果有人工特殊操作和初始化基础数据的，一并完成。近年来随着版本发布上线的节奏越来越快，每次维护的版本数量也随之增加，工作量也是比较可观的。由于特殊步骤的不确定性，这部分工作暂时不能实现自动化。

对于容器化应用来说，这个事情就简单很多了。开发侧的DevOps平台通过产品中心维护了所有微服务的版本号以及对应的镜像tag，也就形成了线上环境基线。运维平台在完成上线操作之后，会回调开发侧的DevOps平台进行线上环境基线的更新。在用户申请新的环境时，对于K8S中的部分来说，只要根据线上环境基线来动态生成工作负载即可。

 除了版本部署之外，开发测试环境基线的维护还有特殊步骤（如新增、下线数据库等）需要人工操作、新增测试公共基础业务数据、定期线上线下schema比对、部署后冒烟测试等等工作。

 当然还有个重要的工作就是 资源使用监控和回收

没有人会嫌工资低，也没有人会认为发给他的奖金多了而主动上交。资源也一样，申请是自助，回收就没那么“自主”了。要放得出去，收得回来。当然这是另外一个话题了。

更NB的方案？

进入云原生时，曾经考虑过是否继续往前演进开发测试环境，如在行业里非常有名的阿里 公共基础环境+特性环境的方案。

 在阿里，我们如何管理测试环境-阿里云开发者社区

评估之后，发现需要的基础架构支持（如 流量染色、全局路由（群岛内也要走路由），尤其是DB向前兼容等开发技术实践，以目前的技术能力，根本要不起。另外一些数据层面的问题，如 xx日期、XX价格等等有状态的全局性数据，如果在一套DB中，不可避免会彼此冲突造成的混乱会让用户无法共用，体验下降。当然也有人提出过影子库等技术方案。

成本上来看，目前的OpenStack云+K8S云底层设备都是线上环境淘汰下的利旧设备，本身就是0元购付个电费就行，并没有很强烈的“降本增效”的冲动去推动进一步架构升级。最重要的反而是做好资源分配和闲置资源回收的工作。

综合来看，架构要求上达不到、用户体验预期不高、硬件成本房门没有驱动力，所以就这样吧。