背景：
业绩流行的「测试泳道设计」目前在自如网中经由基础架构中心自研的发布系统「Omega」落地了，名为「特性环境」，但在推行业务线使用过程中实际效果并不理想。为深层次解决此问题，我们将进行调研与实践。
01
问题分析
2022年8月底，梳理现状。共分为三个问题部分：
1、稳定环境初始化难；
2、特性环境易用性差；
3、特性环境可靠性低。
1.1、稳定环境初始化难
1.1.1 骨干链路配套缺乏
当前应用部署稳定环境依赖的上游应用可能不存在稳定环境。
1.1.2 原有环境并存冲突
当前稳定环境与QA环境网络条件一致。复用MySQL的合理性需评估。为避免影响QA环境，一部分人会避免使用QA环境。
1.2、特性环境易用性差
1.2.1 创建环境过程繁琐
历经环境创建、资源申请、分支创建、合并部署四个过程。链路较长，前后衔接较差。
1.2.2 理解泳道概念复杂
教育研发人员泳道设计成本高，在实际操作时人员定义泳道标识困难。
1.2.3 缺乏最佳实践缺失
创建特性环境后部署成功，缺乏最佳实践，以至于创建后不知如何使用。
1.3、特性环境可靠性低
1.3.1 中间件初始化条件严苛
目前仅支持RabbitMQ。（底层是利用AMQP代理及泳道创建时新建RoutingKey及Queue来实现泳道特性。）但消息队列前置条件较为苛刻：需将Omega应用关联的队列关系保存正确，否则即便创建了Omega应用的特性环境亦无法正确创建特性环境消息队列。
且创建队列服务本身可能存在不可用的情况。（发生过一件事，特性环境创建调用了创建队列的开发API，但后续API由于添加了权限鉴定，导致队列创建失败）。
1.3.2 中间件本身不支持泳道
Dubbo采用的ZooKeeper注入Tag方式实现。但在某些特性版本的ZooKeeper中可能会丢失Tag标识。
1.3.3 复用中间件数据错乱
缺乏对MySQL等持久化数据库的使用规范。存在不同环境处理相同数据的情况。
02
解决方案分析
针对三个问题：
1、稳定环境初始化难；
2、特性环境易用性差；
3、特性环境可靠性低。
定制三大方面策略。
2.1、 稳定环境初始化难
2.1.1 忽略环境隔离问题
将日常（Daily）、QA（测试）、Stable（稳定）统一归为Test环境。打通各个环境相互访问。可复用各个环境的中间件配置。
2.2、特性环境易用性差
2.2.1 优化特性环境创建流程
将原有步骤「特性环境创建」、「泳道标识选择」、「环境资源审批」、「构建参数配置」、「开启平台赋能」、「特性分支集成」等浓缩成一个「加入特性环境」按钮。仅通过一个表单即可快速的创建特性环境。
2.2.2 部署自有服务进行模拟实践
基于Omega自身，采用特性环境进行新功能的测试。在新功能的测试过程中发现、收集、解决问题，并输入自身的思考及最佳实践方案。为后续迭代优化提供思路及方向。
2.3、特性环境可靠性低
2.3.1 编写测试用例
验证现有功能的可靠性。
2.3.2 修复现存异常
基于测试用例的结果，修复现存的异常问题。
2.3.3 编写使用文档
基于现状编写使用功能的前置条件（如RabbitMQ特性功能正确开启需满足Omega应用在ZMS平台正确关联Queue，否则将无法正确创建队列）
03
解决方案实践
| 序号 | 事项 | 负责人 | 说明 |
| 1 | 编写测试用例 | 熊超 | 验证特性环境现有功能可靠性：HTTP、Dubbo、SpringCloud（Eureka、Nacos）、RabbitMQ。 |
| 2 | 修复泳道异常 | 熊超 | 修复RabbitMQ创建失败问题。补充完善RabbitMQ正确创建的前置条件。 |
| 3 | 优化泳道创建 | 黄成 | 新增基于分支及关联Jira创建特性环境按钮。自动初始化特性环境相关配置，包括但不限于：开启增量代码覆盖率收集（SuperJacoco）、环境配置初始化（内存及CPU）、运行时变量继承（LinuxEnv及Hosts）、Maven构建参数（MavenRepo）等。 |
| 4 | 验证可行性 | 黄成 | 基于Omega本身前后端验证特性环境创建及特性环境的应用。 |
04
实践思考沉淀
在真实的实践过程中，我遇到了以下四个问题：
1、Omega本身稳定环境部署究竟应该对接哪些中间件？
2、Omega特性环境部署需要哪些前置条件？
3、Omega特性环境创建后应该如何使用？
4、特性环境与原有环境比起来优势有什么？
我相信大家在使用Omega特性环境时也会遇到相同的问题，故撰写于此，已飨视听。
4.1、稳定环境究竟应该对接哪些中间件？
由于历史原因（无QA介入），与业务线不同的是，基础架构中心绝大部份应用无KQ环境。故Omega在部署稳定环境时遭遇了第一个问题：对接上游系统是否需通知上游系统部署稳定环境？对接中间件是否需对接稳定环境中间件？
在经过短暂思考过后，我发现对接全部的稳定环境应用及中间件既无可能、亦无必要。
原因如下：
1、应用开发者在需要特性环境时，无法即刻推进全部的上游应用接入稳定环境；且即便不依赖于上游的稳定环境应用及中间件，亦可对接原有环境的应用及中间件进行特性环境开发。
2、后续需将多个应用串联至特性环境时，再做改造，也来得及。因为若多个应用归属于内部自不用说，若跨业务线，亦可基于相同的目标及技术基础进行协作部署。
故基于此判定：
我将Omega的前后端（omega-ui及omega-api）部署至稳定环境仅对接原有环境的应用及中间件。
omega-api对接的大多数为Daily（KT日常）环境的应用及中间件，如Message（消息推送）、Opst（工单）、SIA（定时任务）；
而omega-ui亦为Daily（KT日常）环境的服务，如私有云登录。
4.2、特性环境部署成功，需要哪些条件？
在实践过程中，我所遭遇的问题共分为两部分：后端及前端。
后端部署遭遇问题：
1、 跨环境访问
a) 需在稳定环境、特性环境访问日常环境服务。通过hosts配置进行跨环境访问。此功能仅在基础平台内部可执行。业务线绝大多数均部署KQ环境且稳定环境一部分均已部署。
前端部署遭遇问题：
1、 前端编译问题
a) 编译稳定环境需新增npm run build:stable。需在index.js中添加stable.env.js构建配置文件。
4.3、特性环境部署成功后，如何使用？
1、分析：共计三种情况：1、仅前端开发；2、仅后端开发；3、前后端均需开发。由于Omega仅涉及到Web端开发，，故抛砖引玉，仅阐述Web端开发的最佳实现，移动端复刻同理。
2、前提条件：前端与后端均已部署稳定环境。且采用稳定环境域名访问。Omega前端通过omega.ks.ziroom.com访问，且对接了omega-api.ks.ziroom.com后端。
3、特性环境部署逻辑：开发即部署，不开发即无需部署。 如仅开发前端则仅部署前端至某个特性环境，后端同理。
4、使用方式：依赖于Chrome插件ModHeader，该插件作用：在Header中添加KeyValue。在自如中实践即添加ziroom-env-tag及JiraID用于泳道标识。
详细阐述说明：
原则上来说，大家仅需遵循2、3、4即可。之所以这样做的详细解释如下：
还是基于1分为三类场景：1、仅前端开发；2、仅后端开发；3、前后端开发。
1、 仅前端开发：部署至特性环境后。由于前端已部署，故通过omega.ks.ziroom.com带标签访问会自动FullBack至特性环境的前端应用，而由于并无特性环境后端，故会请求会由稳定环境后端提供。
2、 仅后端开发：同理可得，仅部署特性环境后端。由于前端并未部署，即便omega.ks.ziroom.com带标签，依旧会通过稳定环境的前端返回页面，同时访问特性环境后端服务。
3、 前后端开发：均使用特性环境应用提供服务。
4.4、特性环境与原有环境比起来，优势有什么？
如果仅是为了用而用，难免存在自嗨的嫌疑，拿着锤子找钉子的事情无疑是对成本的极大浪费。那么在我个人的实践过程中，存在哪些对我而言更有价值的收益，以供大家参考呢？
1、 排查异常更独立。
a) 由于接入了代码覆盖率扫描工具，可以将增量代码扫描出来。在遭遇异常中断时，可以快速定位到究竟是在哪行代码中断的，以便在测试环境快速定位问题。
2、 环境隔离互不干扰。
a) 若存在多条并行测试时，不会因为并行测试造成相互间的逻辑影响。如功能A依赖于某开关「开启」但功能B依赖于某开关「关闭」。在不同环境中即可通过Mock的方式进行调试测试。
3、 泳道链路调试
a) 若存在跨多应用的需求，无需启动全量应用覆盖测试链路了，有益于降低业务线测试的测试链路部署的成本。
05
后记
之所以采用「绝知此事要躬行」作为标题，实际上也对应了软件开发中的一句话「吃自己的狗粮」。虽然特性环境主要受众是业务线研发，但若不亲身实践，我们亦无法得知在真实使用过程中到底会遭遇哪些问题。唯有亲身实践后，才能在实践中发现问题，最终切实的解决掉其存在的困难。
作者:互联网平台-黄成
来源-微信公众号:自如技术
出处:https://mp.weixin.qq.com/s/oG7jqA3px8wqb2epPUraUw