绝知此事要躬行-Omega特性环境

e

的配置文件

目录

1.问题分析

    1.1 稳定环境初始化难

        1.1.1 骨干链路配套缺乏

        1.1.2 原有环境并存冲突

    1.2、特性环境易用性差

        1.2.1 创建环境过程繁琐

        1.2.2 理解泳道概念复杂

        1.2.3 缺乏最佳实践缺失

    1.3、特性环境可靠性低

        1.3.1 中间件初始化条件严苛    

        1.3.2 中间件本身不支持泳道 

        1.3.3 复用中间件数据错乱

2.解决方案分析

    2.1、 稳定环境初始化难

        2.1.1 忽略环境隔离问题

    2.2、特性环境易用性差

        2.2.1 优化特性环境创建流程

        2.2.2 部署自有服务进行模拟实践

    2.3、特性环境可靠性低

        2.3.1 编写测试用例

        2.3.2 修复现存异常

        2.3.3 编写使用文档

3.解决方案实践

4.实践思考沉淀

    4.1、稳定环境究竟应该对接哪些中间件？

    4.2、特性环境部署成功，需要哪些条件？

    4.3、特性环境部署成功后，如何使用？

    4.4、特性环境与原有环境比起来，优势有什么？

5.后记

背景：

     业绩流行的「测试泳道设计」目前在自如网中经由基础架构中心自研的发布系统「Omega」落地了，名为「特性环境」，但在推行业务线使用过程中实际效果并不理想。为深层次解决此问题，我们将进行调研与实践。

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) 若存在跨多应用的需求，无需启动全量应用覆盖测试链路了，有益于降低业务线测试的测试链路部署的成本。