工程实践规模化推进要点分析

Posted 2023-03-01 zhangmike

本文纲要

• 【引言】
• 【技术教练团队】
• 【持续集成】
• 【哪些实践更加优先】
• 【复杂的自动化测试】
• • L0自动化测试
  • L1自动化测试
  • L2自动化测试
  • L3自动化测试
• 【组织级工程实践氛围建设】
• 【小结】

【引言】

工程实践，也有称为技术实践，其推进在敏捷转型当中具有重要位置，有推算认为效能提升里面的至少一半来自于工程实践。由于不能严格的区分提升来自于哪里，以上推算难以证实，但也可以体会到工程实践的重要性。

当一位教练辅导10人团队时，可以与团队成员逐个结对，手把手传递，而在敏捷转型在超过100人的情况下，工程实践的推进就会遭遇规模化问题。而随着敏捷DevOps的深入，当前1000人级别的推进已经有很多了，到了千人级规模，显然逐个结对显然推进速度不够快，原先在10人团队的推进手段很难复制到千人级。本文试图来看看千人级工程实践推进。以下来探讨下工程实践规模化的要点。

【技术教练团队】

首先跟着上面例子，既然光靠1个技术教练逐个结对去推进显然不够，那么很自然的有个方案是建设技术教练团队和外围热情者，比如工程实践主题的CoP，比如TDD CoP，持续集成CoP。但是这个方案在业界采纳的比例不高，成建制的管理教练团队比较多见，成建制的技术教练团队相对很少，就算有，人数也有限。在规模化下工程实践氛围也许比有限的技术教练团队更加重要，而千人级工程实践氛围的带动得要有赖于组织刻意的推动，首选是持续集成。

【持续集成】

规模化工程实践首选的推进点是持续集成。通过持续集成工具，天然可以方便地以组织级视角来观察，也就是可以得到规模化展现和度量。比如可以看到哪些团队或者系统已经启用了CI（持续集成），具体样例指标有：

• 每个月进行多少次，
• CI成功率如何，
• CI里面的自动化测试用例数量，趋势是否增长
• 测试覆盖率趋势如何。

另外持续集成是组合实践，不同组织有不同侧重点，而且在理论上与持续部署存在交叉。从规模化推进角度，试图来识别持续集成里哪些实践更加优先。

【哪些实践更加优先】

招行去年2019年公布了其DevOps建设情况，里面给出了招行成熟度模型，成熟度分三级：一级包含了自动化编译、静态代码扫描、发布制品库三个工程实践。二级是在一级的基础上，增加了自动化部署。三级是在二级的基础上增加了单元测试和自动化测试。（引用自招行滕乐英老师分享的演讲实录丨招商银行DevOps实践及DevOps标准认证评估分享）
笔者的归纳与招行此模型大体一致，按优先顺序从高到低如下：

1. 自动化编译
2. 静态代码扫描
3. 发布制品库
4. 自动化部署
5. 自动化测试
   自动化测试这里与招行不一样，下文会说明。

自动化编译是理所当然的高优先，没有这个余下一切免谈。
静态代码扫描是组织级容易推进的工程实践，最典型的例子是安装SonarQube服务，提供给各一线团队使用。开始时可以降低门槛来切入，切实让广大一线团队感受到好处，然后可以迅速铺开，切实规模化的观测到组织整体代码质量情况。与此实践对照的是人工code review，code review需要一线团队主动的人工付出，其规模化推进就有较大困难，需要专项建设。
发布制品库为发布管理要点，确保投产版本准确并且可以回溯。
自动化部署在海量服务部署情况下显然也是高优先。

【复杂的自动化测试】

然后来到了复杂的自动化测试。首先的复杂来自于自动化测试这个词本身，自动化测试在不同组织语境下有不同含义，有些地方说的自动化测试是指启用诸如selinium的自动化测试，招行把单元测试和自动化测试并列，看起来单元测试好像不是自动化测试。

本文采用其字面意思，即是覆盖全部自动化测试，采用微软的自动化测试分类方法，按如下划分：

L0自动化测试

特征是无需部署安装也不依赖外部资源，这与经典单元测试高度重合。为什么不用单元测试这个提法？因为有些地方的单元测试超出了L0范畴，甚至覆盖到了L2，这与XUnit系列单元测试工具的强大有关，无论如何，单元测试这个词目前存在不同理解，啰嗦一些的L0自动化测试更加精准。

L1自动化测试

特征是无需部署安装但依赖外部资源，也类似于单元测试，一般所用工具就是XUnit系列。

L2自动化测试

特征是无UI界面基于接口/API的测试。仍然可以使用XUnit系列工具，当然也可以使用专门接口测试工具。

L3自动化测试

特征是UI界面自动化测试。常见使用Selinium。

微软公布的实例里面说明当前微软目前现有大多数测试都是L3级，而招行的情况是接口测试占据多数，招行精益敏捷类对接口测试覆盖率要求达到100%，也就是在以上的L2级。

招行将其测试组合形容为测试橄榄球型，这与笔者之前所提出的纺锤形是一回事。

对于微软实例说L3最多，这也许与微软产品特征有关，尤其是其Office系列，这样的话是冰淇淋形。笔者猜想微软测试冰淇淋形组合是特例。而招行测试橄榄球形更加代表了规模化测试推进的样例。

测试金字塔理论上以L0为基础，数量最多。但从性价比上不是最经济的，在规模化角度上，跨团队接口联通更加优先。

因此自动化测试里面优先推进建设以接口/API测试为特征的L2自动化测试，然后L0，L1。而基于界面的L3测试更加排在后面。

【组织级工程实践氛围建设】

个别一线团队会自动自发地建设持续集成，但如果在千人规模上考虑这个问题，就不能够指望自动自发。因为这里面存在至少2重困难：

1，持续集成建设本身存在难度；

2，对如何实践是否带来高效率没有统一认识。

因此要培养工程实践氛围，值得利用持续集成工具特性来开展组织级工程实践度量，建立标杆，引领更多团队前进。
对于指标样例，有如下列推荐

• 测试用例数量，比如月度新增数量，起始时，不在于绝对数量，关键在于持续增加，如果总运行时间过长，那么分多级运行，比如区分白天晚上
• 执行频率，比如月度执行次数，执行频率越高越好
• CI成功率，比如自然月成功率，100%成功意味着没有充分利用CI，甚至为了100%反而耗费了额外的工作量，推荐各组织摸索一个恰当到成功率区间
• 测试覆盖率，比如月度比例趋势，这又是一个微妙的指标，不能够下降，但并不是越高越好，需要各组织摸索一个合适的区间

【小结】

持续集成是工程实践规模化的核心实践。其中的自动化测试推荐优先以基于接口/API的L2自动化测试。技术教练团队值得考虑，但有难度，更重要的是提升工程实践氛围，值得收集并公开各种度量。