2）方案
所以该如何避免上述情况呢？来看一下我们的实践 。
文章图片
① 多种手段保证效果
首先我们采用的第一个方法是先用多种手段保证效果 。 我们的手段包含以下几种：
- 代码review（code review） ， 即人工的review ， 现在我们公司已经建立起了较好的code review文化 ， 大家都已经形成了这种习惯 。
- 静态代码检查sonar ， 这个地方sonar不只是sonar ， 在我们公司的话 ， 主要技术栈是Java ， 所以我们会在 Sonar里边会做一些java规则的检查 ， 比如说非法的包名、重复类、然后依赖多版本等检查 ， 同时也会把一些原数据的信息记录下来 ， 例如记录变更的内容 ， 变更的依赖等 。 除此之外也会做sonar本身的一些规则级检查 ， 我们这个规则也会定期做review 。
- 接口自动化 ， 接口自动化我们分了两部分 ， 第一部分是我们的线上回归测试 ， 所用回归的工具我们叫灭霸 ， 它会在每次开发提测时自动执行 ， 把线上现在存量的一些接口做回归验证 。 如果你是新增的业务接口的话 ， 我们也会有一个自动化测试平台叫Qunit ， 它是基于unit的 ， 去做一个新的业务的验证 。
- 代码覆盖率检查 ， 我们sonarqube等各种的自动化工具 ， 都可以看到当前的测试的覆盖度 。 测试覆盖度这块大家其实一直有一个疑问 ， 那就是我测试的时候就是代码百分百覆盖 ， 也不能保证上线完全没有问题 。 但是反向也有另外一种说法 ， 起码百分之百覆盖了 ， 还是会增加一定程度信心的 ， 所以覆盖率是非常重要的 。
手段多样是有前提保证的 ， 尤其接口自动化有环境依赖 ， 如果没有环境做接口自动化或者没有这个环境管理 ， 接口自动化、执行接口自动化的可行性或速度都是没有办法保证的 ， 所以我们又有一个环境管理平台 ， 通过这个环境管理 ， 我们可以快速的交付一套环境 ， 这个环境中包括了自己的应用以及它的依赖 ， 为自动化的可行性提供了保障 。
③ 报告消息反馈结果
自动化的可行性有了 ， 多种手段也有了 ， 最后的这些报告信息怎么通知给开发人员？我们做了多维度的报告展示 ， 包括项目维度 ， 个人维度 ， 还有组织维度等 ， 同时我们也会通过内部的Im消息精准的通知到具体的开发人员 ， 这样方便他可以快速地解决问题 ， 相当于质量阻力左移 ， 降低了问题修复的成本 。
④ 质量门径预防蔓延
我们会结合我们的项目管理系统、发布系统等去做质量卡点 ， 如果不通过 ， 我们就会去做一个拦截 ， 然后避免带着问题上线 。
上面说了我们具体的方案 ， 下面让我们简单地看一下多种手段 ， 我觉得在现在这个阶段 ， 大部分公司都会有这几方面的保证 ， 我这个地方只简单介绍我们公司的一些特色点 。
文章图片
- 在CodeReview方面 ， 我们是基于开源工具phabricator实现的 ， 我们会做到分支创建后自动同步仓库 ， 同时代码push的时候自动去创建更新diff ， 这样就避免了人工去创建以及后续操作 。 同时我们支持两次提交diff的变更 ， 这是为了解决发现问题并修改重复提交后的全量diff问题 。 不需要全量的再次diff ， 只需要看这两侧的一个变更 。 当然如果影响范围较大的话 ， 还是建议全量的再diff一次 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。