背景
之前公司内部沟通使用的是企业微信，今年以来迁移到了飞书，在使用这两个工具的时候感觉机器人通知的功能还是很不错的，可以起到提醒和快速引导的功能。
基于机器人，公司已经做了各种待办通知、流程通知，在此基础上，团队也思考着结合机器人通知机制做了一些工具和平台。
问题跟踪平台
项目需求阶段经常会遇到待确认事项，目前都是通过在群里，或者口头找人确认，导致问题结果很难公开，仅有小部分人知道，同时部分问题会没及时答复容易跟丢现象。所以就想到了做一个平台去沉淀项目中待确认的问题，然后通知对应的人进行确认，进行状态流转。更长远看，这些问题数据可以沉淀下来用作问题分析和左移分析。
基本的功能模块首先就是项目的登记，需要填入项目信息或者问题名称
通过配置的机器人key以及设置的时间，可以按指定时间对于未关闭的问题进行提醒
目前这个工具已有几十个项目使用，总体反馈还不错。
失败用例通知到人
公司的持续集成流程里，集成测试跑的是基于testNg的自动化工程，订阅了集成测试结果通知，运行完成后会通知你成功或者失败
点开链接就会看到自动化工程的执行结果
这样似乎能够满足我们感知和修复集成测试的需求。但当自动化用例由多个人编写和维护的时候，如何划分维护范围以及找到用例维护人就是个很头痛的问题，之前的做法就是使用表格维护或者打开工程看下是谁写的代码，比较麻烦。用例及时维护一直是个痛点，如何快速找到责任人是用例快速修复的基础。
现在的做法，通过testNg的listener监听用例失败的消息，通过git blame命令找到失败用例的提交人，精准的进行通知，这样集成测试的发起者也知道失败找哪些人确认失败的原因。
日志告警通知到开发
既然失败用例可以通知到人，自然而然的想到，线上的错误日志，也能通过类似的方法找到代码行最近修改的开发，根据日志中的错误信息和打印出的异常栈。
线上问题通知的玩法和维度可以更多一些，比如针对错误类型进行分类展示和通知（如NPE），根据提交时间判断是否是最近项目发布造成的进行区别提醒等
不得不说，飞书的话题群很适合这种类型信息的同步，对于错误信息相关开发定位排查后可以回复错误的原因。
最后
以上都是团队在工作过程中思考想出的一些提高效率的方式，不算很难，很多都是一些小点的优化，但效果还是很OK的。如果大家都能不断优化和改进自己的工作，那么个人能力就会得到成长，团队效能就能得到提高。
标签：集成,事情,通知,机器人,问题,用例,失败,提效 来源： https://www.cnblogs.com/opama/p/16108961.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。