标签:电脑 测试环境 访问权限 小问题 迭代 记录 支持 案例 参数
2019年08月09日,上海受台风利奇马的影响,晚间狂风大雨。
临下班,合作渠道WB在微信群里报告线上生产事故问题:赶快扒日志看记录,日志显示一切正常,看不出bug在哪里,WB声称并未接收到我方CI的回调请求。晚七点多,肚子已经饿了,给WB说,看日志CI没啥问题,先撤了。
在出公司大楼经过一个拐角的时候,隐隐感觉这情形代码里的配置项会不会有问题,心里很是忐忑,冒雨又折回。重新打开电脑,再捋一遍代码的时候,bug像一道匕首直刺心头:卧槽,这个路径竟然还是测试环境 的路径!项目组是公司敏捷开发团队,每周五都会有生产版本发布,赶快给负责版本控制的同事打招呼,等一下,搭个顺风车。
在确定了配置路径有问题之后:亟待明确的是服务间调用是走内网还是走外网,要不要NG转发,走不走esb,是不是要申请通信权限。简单描述一下WB的该次请求:WB请求CI的NG--------》NG转发到CI的Mule服务----------》Mule服务调用Gateway----------》Gateway转发至应用微服务Application ---------》Application服务响应之后执行异步回调Mule服务---------》Mule服务请求WB接口地址 。中间涉及的防火墙和权限就暂且忽略,目前的问题点是:Application服务响应之后执行异步回调Mule服务,这个Mule服务内部接口地址规范是什么,会负责系统维护的同事一番确认后,决定走内网Mulef5,这个时间点负责维护配置中心的同事已经下班了,当务之急硬编码的方法先上了。
九点多回到家,觉得有必要复盘一下为什么会遗留这种bug,2018年11月份进入CI公司的敏捷开发团队。刚入司时对敏捷开发基本不了解,后来才发现这是一种近乎流水线的开发模式。作为开发可以说是一个不停机的多线程,从一个合作业务开发要介入需求沟通、网络申请、防火墙权限申请、配置维护、数据维护、多环境测试联调、线上支持。每天被各种合作群微信轰炸,有时候盯着开发文档和需求分析文档去盘问需求的正确性 ,有时候也不得不去应答一些需求和业务上的问题,开发思路很容易中断。对于单个的合作渠道追求对接速度快,省略了各种文档和单元测试,缺少代码的复核和管理。快速迭代,线上支持,这种公司层面的情况是短期没办法改善的,在这种工作模式下,应该梳理出标准的工作流程模式,严格按照流程模式在上线之前去复核,才能避免易忽视的小问题。
以WB案例来说:
阶段一:谈合作阶段
前期CI分公司业务人员与WB达成合作意向,确定合作产品方向。
阶段二:谈需求阶段
CI需求人员介入,通过沟通和场景分析,参考WB合作接口文档,分析CI接口映射关系、业务字段关联,草拟一份需求分析文档供开发测试用。
阶段三:方案确定阶段
此阶段开发人员已经开始开发,开发对需求分析文档中的一些问题会和WB方开发和CI方需求及业务人员确认,此阶段开发人员主要解决加密解密、加签验签,测试环境申请。CI业务人员明确WB合作方案和WB合作机构信息,CI业务人员同步方案和机构信息至测试系统。
阶段四:开发者开发阶段
此阶段大致分三板块:第一,Mule开发;第二,应用开发;第三,配置项维护。
阶段五:测试联调阶段
此阶段开发负责环境双方网络权限,Ng转发路径,Api访问权限的开通,相关数据维护。测试人员介入进行本地测试,本地测试通过,WB方介入联调。
阶段六:生产环境准备阶段
测试环境和生产环境在网络权限和防火墙控制有很大差别,主要是权限和参数维护。应按流程梳理各个环节权限是否开通,各参数和WB提供生产参数是否有出入。确认无误,进行上线。
标签:电脑 测试环境 访问权限 小问题 迭代 记录 支持 案例 参数
原文地址:https://www.cnblogs.com/slowcity/p/11330012.html