4、效果
建立生态之后 ， 看一下我们现在基于生态实现的效果 。

文章图片

这几个数字是基于月均的数字统计 。 我们现在每月平均有3000＋项目发布 ， 15万次＋部署 ， 涉及到2000＋应用 ， 1000＋开发测试运维 。 由此来看 ， 我们的体量还是相当庞大的 。
值得一提的是 ， 在这3000＋的项目发布中 ， 有很大一部分是开发自测自发 ， 即完全没有测试人员的参与 。 这完全依赖于我们 DevOps生态建设对开发测试进行赋能 ， 也因此 ， 我们的开发同学自测自发不仅保证了质量 ， 同时也保证了我们的交付速度 。
二.核心领域实践
在了解我们的生态之后 ， 下面来具体地看一下我们在一些核心领域的落地实践 。
1、规范化助力开发提效
上述分享的方法论中有一步很关键 ， 那就是规范流程 。 那么规范流程有什么意义呢？
1）背景
下面我们来看一个具体的案例 ， 看它如何助力我们的开发提效 。

文章图片

在我们公司 ， 可能其他公司也相同 ， 在开发项目过程中一个核心资源就是开发资源 ， 我们的理想状态就是要实现开发资源利用最大化 ， 理想状态就是开发人员只需专心投入写代码即可 。
但是现实情况是开发同学被各种角色干扰 。 主要有以下几个问题 。

• 对开发来说 ， 频繁的被打扰导致其时间碎片化 ， 在各种任务之间切换导致效率无法保证 。
• 对项目经理来说 ， 无法得知项目的实时进度 ， 项目是在开发过程中 ， 还是在测试过程中 。 因此只能去跟开发进行去人为沟通 ， 这不仅导致了开发被打断 ， 也使项目经理无法掌控整个项目过程 。
• 对QA来说 ，QA最终要为质量负责 ， 但是QA不知道项目的这次需求变更了什么内容 ， 这就会导致变更靠人为的梳理很容易被遗漏 ， 从而导致上线出故障 。 我们有很多血淋淋的教训 ， 因为没有更新DB ， 或者是一个配置忘记更新了 ， 上线出现过很多次故障 。
• 对PMO来说 ， PMO要收集整个项目过程的数据 ， 通过数据去确定我们的改进优化分析 ， 分析优化改进 。 但现在我们项目的所有数据全都依赖人工去填写 ， 很难保证数据的准确性 ， 从而给改进优化带来困难 。

通过上述分析 ， 我们可以发现 ， 我们对于整个过程的跟踪是基于项目去跟踪的 ， 但是这个项目变更的内容又是应用维度的 ， 所以导致我们没有办法被跟踪 ， 人为操作多 。 核心问题就是我们的应用跟项目没有建立关联关系 ， 所以我们要去建立这一关系 ， 从而解决这个过程中的问题 。
2）方案
那如何建立关系？依靠规范化 。 看看我们是怎么做的 。

文章图片

① 分支命名规范化
我们对分支进行了命名规范的要求 ， 分支名必须包含一个PMO标识 。 这样当分支被创建、被push的时候 ， 就自动将其关联到项目上面 ， 建立了应用跟项目的关联关系 。
② 质量检查可视化
知道了项目变更了哪些内容 ， 变更的时候每次提交都可以去自动的触发一些相应的检查 ， 相应的检查结果报告就可以展示在这个项目上面 。 对于QA人员来说 ， 可以直观的了解项目当前的质量状况；对于项目经理来说 ， 可以比较直观地了解这个项目的状况 ， 从而去控制风险 。