③ 数据回填自动化
对于PMO来说 ， 之前很多数据难以收集 ， 有了关联关系之后 ， 我们会把这一次项目的发布数据 ， 包括发布的次数 ， 以及变更的行数等都自动回填 ， 相当于获取了这个项目整体的变更数据 。
④ 状态流转智能化
因为我的代码已经跟它关联起来了 ， 在开发中如果是提交到代码 ， 可以自动从项目已排期状态变成开发状态 。 当我做了一些Beta验证的时候 ， 就可以自动地流转到我现在是要提测了或是要发布了 ， 所以这个状态的流转实现了智能化 。 结合完整的方案 ， 我们就解决了各种开发被打断 ， 自动化手动操作过多的问题 。
这个是我们的架构 。
文章图片
相当于开发与应用关联的工具 ， 我们内部把它叫做Qodin ， 底层是DB ， Cache ， 其次是我们的数据存储 ， 然后各个工具平台会把自己执行的一些结果通过发送消息推送到我们的消息平台 。 Qodin通过消费这些消息 ， 通过外部的HTTP接口触发各种工具平台去执行 。 上层是我们通过js一些页面给用户提供一些查看入口、操作入口等等 。
3）效果
下面再来看一下我们实现的效果 。
文章图片
上图是我们的一个项目 ， 我们可以看到这个项目中到底变更了哪些内容 ， 首先是变更的一些质量的情况 ， 以及它的发布情况 。 其次是我们自动回填的数据 ， 可以看到包括研发阶段的市场自动计算 ， 项目总市场等 ， 线上发布的次数 ， 代码变更的一些信息 ， 同时我们在一些项目的关键节点 ， 根据时间计算关键节点的状态流转以及是否delay ， 这些都会有一个及时的项目提醒 ， 这样保证了开发和项目经理等都可以及时地关注到整个项目过程 ， 一旦有任何风险也可以及时地暴露出来 。
总结这一实践 ， 主要是通过规范化确定一个分支的命名规范来实现我们的应用跟项目的关联 ， 然后保证了我们项目整个流程的自动化与高效 。
2、多种手段+发布门禁助力质量保证
我们再来看一下速度有保证后如何保证质量 ， 这就是我们的第二个实践 ， 通过多种手段和发布门禁助力质量保证 。
1）背景
文章图片
我们先看一下理想 ， 理想的状态是开发修改完代码之后 ， 通过测试 ， 提交给QA ， 然后QA同学集成测试 ， 最后愉快地上线 。 但实际中常常会出现开发跟测试同学的相互抱怨 。
开发人员表示我测了 。 QA人员却说你这提交的是什么 ， 你自己测了没有？
QA人员常说为什么我测试了 ， 到上线还是会遇到问题 ， 其实总结起来主要是以下问题：
- 对开发人员来说 ， 首先测试条件是难保障的 。 开发人员做测试的时候 ， 其实有环境的依赖 ， 也有数据的依赖 ， 有一些前提条件的准备 。 但是这些常常会特别耗时间 ， 准备也非常困难 ， 导致测试不足的问题 。 其次修复成本高 ， 因为开发人员在前期的测试不足 ， 提交给QA人员之后 ， 通过QA人员发现了问题 ， 然后再反馈给开发人员 ， 反馈的周期就拉长了 。 开发人员这时可能已经进入到其他项目了 ， 从而又有一个切换成本 。
- 对QA人员来说 ， 没有办法让开发保证提测的质量 ， 更多的是依赖于自己的测试 ， 对其来说非常不友好 。 还有上线的质量也难以保证 ， 很多其实我测到了 ， 但是可能依旧带着问题上线了 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。