一、当前遇到的环境问题
初期，根据实际研发需要，LigaAI 主要应用了以下四套环境：
- Dev 环境是开发环境，专供前 / 后端开发人员进行功能开发自测、联调等；
- Sit 环境为测试环境，供测试成员进行迭代功能验收；
- Pre 环境为预发布环境，主要承担整体测试、回归测试等；
- 最后，Prod 环境为生产环境。
随着团队规模不断扩大、业务组划分走向清晰，以及微服务拆分愈发精细，环境资源开始逐步缩紧，资源紧张带来的冲突频繁制约着团队发展。
- 对迭代有风险的复杂需求需要剥离迭代，进行单独测试；
- 开发人员需要不同的 Dev 环境进行联调；
- 迭代小组的迭代进度各异，需要分批提测；
- 紧急 Hotfix 急需测试，但环境已被占用；
- 需要进行系统压测，却缺乏一套压测环境；
为缓解环境资源紧张问题，LigaAI 对原有的 Dev 环境和 Sit 环境做了如下扩展。
如此虽一定程度上满足了不断增加的环境需求，但不可避免地导致了其他问题。因此，针对以下环境需求痛点，LigaAI 着手搭建了一套高弹性、可伸缩的测试环境。
二、测试环境的改造目标
开始正式改造前，LigaAI 结合研发流程和环境需求，对目标测试环境提出了几点要求：
- 多环境：针对不同的测试场景，可以提供不同的测试环境。
- 互相区隔：数据、配置信息和应用访问在不同环境之间要相互隔离。
- 高效稳定：环境要保持稳定且高效地运转，不能影响正常迭代进度。
- 低成本：产生尽可能较低的额外成本，任何时期都要将资源用在刀刃上。
- 可复用：针对特殊需求可快速扩展新环境；简化测试环境维护，让团队聚焦研发与测试。
第一步：测试环境的标准化改造
Step 1：搭建底层基础设施
围绕弹性、扩展和部署等关键词，LigaAI 最终选用 Amazon EKS 作为环境伸缩的底层基础设施。
Amazon EKS 即 Amazon Elastic Kubernetes Service，是一项完全托管的服务。无需安装、操作或维护集群也可轻松运行 Kubernetes，而其内置的控制面板则为 LigaAI 的集群管理提供了便利。
Step 2：规范中间件资源
为方便应用接入，我们梳理了系统中需要改造或命名规范化的基础资源和中间件，包括域名命名、数据库地址、消息队列、Redis 和 Elasticsearch 等。
命名规范化可以以环境名称为统一标识，采用「资源名称_环境名称」等形式完成。
Step 3：应用改造
下一步，依据梳理好的基础资源和中间件规范，重新整理并统一测试环境配置信息，规范化应用配置和持久化数据。
应用改造目标是，只需注入环境名称，即可替换所有与环境相关的配置信息，如回调地址、消息队列、数据库信息等；而持久化的数据不应保存与环境信息相关的数据。
该阶段可能涉及到一部分代码改造，需要开发团队参与配合。
Step 4：制作环境模板
想要自动生成环境，首先必须有一套含有持久化数据、配置文件和应用包的环境模板；其中，应用包数据包括后端镜像和前端资源包。
在本次改造中，LigaAI 指定 Pre 环境作为基准环境模板来源。
Step 5：一键搭建环境
为最大程度提高产研团队效率，环境搭建必须方便快捷，且满足可复用要求。
将环境搭建流程的各个环节脚本化，并将这些脚本集成到流水线任务当中，实现环境搭建的一键生成效果；其中，将部分流程并行处理，也会加快环境生成速度。
Step 6：环境登记责任人
除一键生成环境外，制定标准化的环境管理流程也很重要。明确环境负责人，将环境生成、重置与释放流程集成到运维平台，让申请信息可视化；
同时，通过信息通知集成 IM，支持环境生成 / 释放信息、环境到期提醒等通知的及时触达。
