Navigation menu
在整个软件研发体系中，研发测试环境是重要的支撑，研发测试环境管理的好坏，与研发效能紧密关联。不同于生产环境，研发测试环境具有版本质量不稳定、版本部署频繁、环境需求多、测试流量混杂等特点，开发人员要求灵活、高频率的版本迭代，而测试人员则要求环境保持稳定，以便更好测试，二者需求是矛盾的，特别是大型业务系统的研发，不同应用系统及不同角色分散在不同的团队，协作链进一步加长。如何在如此复杂的情况下，取得灵活与稳定之间的平衡，是研发测试环境运维管理成功与否的关键。
中国工商银行软件开发中心（以下简称开发中心）以持续提升一线开发测试人员的工作效率和幸福感为目标，积极探索协同、高效的运维模式，打造易用、好用的研发测试环境。
不同开发人员在开发环境调试时，服务间相互干扰大，并且缺乏稳定的依赖服务，导致上下游调用连通性差,自测开展困难，如为每套开发环境配备全量的下游依赖服务，资源投入成本高。在版本自测不充分的情况下，直接提交到集成测试将影响集成环境的质量。
频繁的版本部署导致测试中断增多，而不稳定的版本部署进一步加剧环境的不可用。同时，由于应用间服务相互依赖大，单个应用环境的不稳定，将会影响关联的上下游应用业务测试，导致整体环境体验差。
在日常测试过程中，环境异常、程序代码问题、测试数据不合理等均可能导致交易失败，由于涉及的上下游应用多，不同的应用分布在不同的研发测试和运维团队，往往需要涉及的应用开发、测试、运维人员共同分析排查，协作链条加长，问题排查效率低。同时，随着信创转型、分布式架构转型、单元化改造不断推进，系统架构以及应用复杂度急剧增加，问题排查和分析难度大，问题解决效率低。
开发中心积极应行内应用系统架构转型的挑战，通过在版本部署前、部署时、部署后三个环节的加强，保障测试环境质量稳定可控。
（一）深化环境分层建设，推进测试前移，建设单元小环境，将不稳定的测试场景从集成环境剥离。
以个人或者应用维度为单元独占自测小环境，每个开发人员在各自的单元小环境进行自测，里面只包含自己的应用服务，任意调试、随时上下线，不同单元小环境相互隔离，不同开发人员互不干扰，涉及的技术基础服务如注册中心、网关等作为可选组件按需快速分配，不同的开发人员或者应用需要联调时，可快速合并相互连通，对于依赖的下游应用服务，由更加稳定的集成环境提供，但不会暴露服务到集成环境，避免影响集成测试的正常开展。
①以测试需求作为最小单元生成独立的小环境，可以为单个开发本机、单应用测试、单项目测试、单特殊测试场景等；
②所需的基础技术平台支撑，部署在云端作为可选部件，以最小需求快速供应，包含集群资源、注册中心、服务网关，软负载均衡等。
③每个小环境只部署涉及改造或测试的服务节点，不同单元环境相互隔离，互不干扰，对于自测场景，只需将本地自测项目的服务暴露到自己的申请的小环境即可；
④使用测试工具在自己的小环境下自测，任意调试、随时上下线，不影响别人测试；
⑤对于依赖的下游应用服务，通过更加稳定的公共环境提供，公共环境可以基于现有集成主测环境或其他稳态环境，公共环境服务稳定可用，随时在线；
⑥不同应用、项目、需求需要联测时，可快速组合成更大的单元环境，相互连通。
基于云原生的弹性伸缩能力，新版本升级时快速生成新的副本，在新副本完全就绪前，旧节点不会下线，保证服务不中断，当新副本升级后，同步进行技术验证和业务验证，验证通过后对外暴露服务并将旧版本节点下线，避免质量门禁未达标的版本直接部署到集成环境影响环境的可用性。
②当需要升级为v2版本时，基于云原生的弹性伸缩能力，快速生成v2版本的容器，此时，v1版本节点正常对外提供服务，v2版本未验证完成不对外暴露服务；
③V2版本的服务节点启动完成后，自动化进行技术验证和业务验证，如验证不通过，即中断部署；
④验证完成并通过后，v2版本服务节点对外提供服务，v1版本服务节点下线，升级完成，整个部署过程均由持续集成流程线自动化完成。
进一步丰富技术监控以及业务监控的覆盖面，使问题能够快速被发现，同时，预定义问题自动分析的规则和流程，当问题出现时，快速定位问题原因，对于能够自动处理的问题，通过预定义修复脚本自动恢复，无法自动处理的问题，根据问题类型分发到对应角色人员介入分析解决，加快问题解决效率，从而提升环境的可用率。
①问题检测。问题的检测包含技术检测和业务检测，技术检测主要实现对系统资源、应用节点、应用服务等环境对象探活，业务检测主要实现对业务案例的冒烟，基于检测结果，快速发现环境异常。
②多渠道接入。制定统一的检测结果返回标准，各个检测渠道基于统一的标准将检测结果结构化上送，实现多个渠道检测结果整合，使问题能够更好地被识别。
③问题分析。基于预先定义的问题分析规则和流程，对检测结果进行分析，定位问题发生的节点以及原因，并对问题分类，包含环境异常、数据问题、版本问题、配置问题等类型。
④问题处理。基于预先定义的问题处理脚本和流程，对于能够自动处理的问题类型执行修复。
⑤问题分发。对于无法自动处理的问题，根据问题类型分发给不同角色处理，应用版本问题分发给开发人员、测试数据问题分发给测试人员，环境异常问题分发给运维人员。
⑥问题可视化。用户基于统一视图快速查看当前环境问题明细、问题原因、问题类型。
⑦配置可视化。用户基于统一视图自助配置环境检测点、问题分析规则和流程、问题处理脚本和流程，通过检测点、分析规则、处理脚本的不断丰富和迭代，提升问题排查和处理的自动化能力。
通过在版本部署前、部署中、部署后三个环节的优化提升，为一线开发、测试人员提供了好用、易用的测试环境。
一是实现本地服务加入联测，极大提升自测的效率。开发人员本地独占环境，任意更新代码、设置断点、上下线服务，不影响其他人使用，无需等待漫长的流水线部署，需要的依赖服务随时在线、稳定可用，就像整个测试环境在本地运行一样，让开发人员验证自己开发的软件功能变得更加容易，深化质量内建，让开发人员将质量牢牢把握在自己手中，避免未充分自测的版本直接提交集成测试影响环境的稳定性。
二是实现版本迭代过程中服务不中断，极大提升业务测试的连续性。各应用可以按照自身项目的研发节奏进行版本迭代，相互间不受影响，同时，未符合质量门禁准入标准的版本无法在集成环境上线，提升版本测试的质量。
三是实现问题的快速发现、精准定位、高效处理，极大加快问题解决的效率。一线开发、测试、运维人员通过统一的视图查看当前环境存在的问题及问题的原因、处理进度，自助配置检测点、分析规则、自动化修复脚本，实现问题排查自助化、问题处理自动化，通过案例的不断丰富，加快问题解决效率，进一步提升环境可用性。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
清北2022年在全国各省录取人数出炉：广东280人，河南424人，北京550人
直指Model Y！小鹏G6“低价”入市，何小鹏：小鹏汽车的iPhone4来了
“ 孩子，是妈妈害了你！”8岁女孩骨龄老3年，再难长高！医生怒骂：近3成的孩子，都是“吃”出来的
网传高考677分的学霸作息表，有人看过表示很佩服，有人直呼：窒息得要死！