【引言】

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

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

【技术教练团队】

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

【持续集成】

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

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

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

【哪些实践更加优先】

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

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

自动化编译是理所当然的高优先，没有这个余下一切免谈。
静态代码扫描是组织级容易推进的工程实践，最典型的例子是安装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自动化测试。技术教练团队值得考虑，但有难度，更重要的是提升工程实践氛围，值得收集并公开各种度量。

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

从规模化平台工程实践，我们学到了什么？
文|朵晓东(花名:奕杉 ) KusionStack 负责人蚂蚁集团资深技术专家在基础设施技术领域深耕,专注云原生网络.运维及编程语言等技术工作一.摘要本文尝试从平台工程.专用语言.分治.建模. ...
关于概率分布理论的原理分析的一些讨论，以及经典概率分布的应用场景，以及概率统计其在工程实践中的应用...
1. 随机变量定义 0x1:为什么要引入随机变量这个数学概念在早期的古典概率理论研究中,人们基于随机试验的样本空间去研究随机事件,也发展出了非常多辉煌的理论,包括著名的贝叶斯估计在内. 但是随着研究 ...
结合工程实践选题调研分析同类软件产品
在本次的工程实践中,我的选题为基于openGL的车载虚拟仪表的软件开发. 随着计算机技术的日益成熟,计算机的应用已渗透到各个领域,各种无人机装备也逐步向数字化.智能化方向发展.虚拟仪表在飞行仿真中 ...
5000 万行以上大型代码仓库工程实践
作者:marinewu,腾讯 PCG 工程效能平台部专家腾讯 PCG 工程效能平台部自 2020 年开始进行大仓基本能力建设,并在 2021 年与工蜂合作成立了代码大仓研效联合项目组.在此, 我们想 ...
《国家地理信息公共服务平台“天地图”的关键技术与工程实践》摘
2017年前辈们写的文章,今天读来依然感受颇深,文章介绍了国家天地图的建设背景. 关键技术.建设成果和工作展望,以及国家天地图在维护国家主权.支持政府决策管理和推动地理信息产业发展所做的努力.想想这些 ...
披荆斩棘：论百万级服务器反入侵场景的混沌工程实践
在繁杂的业务和网络环境下,在公司百万级服务器面前,要做到入侵发生时的及时检测,那么反入侵系统的有效性,即系统质量,是至关重要的. 洋葱系统是腾讯公司级的主机反入侵安全检测系统,它是实现了前端主机age ...
阿里云块存储团队卓越工程实践
作者:彭文文.石超.张小路 "我背上有个背篓,里面装了很多血泪换来的经验教训,我看着你们在台下嗷嗷待哺想要这个背篓里的东西,但事实上我给不了你们",实践出真知. 这是阿里云块存储 ...
字节跳动混沌工程实践之场景化主动实验
背景从 2010 年 Netflix 上线 Chaos Mokey 的第一个版本到现在,虽然混沌工程发展已历时十年,但其实只在少数大厂里面有较成熟的落地,对绝大部分研发同学来说,混沌工程还是一个比较 ...
入侵sf服务器技术_披荆斩棘：论百万级服务器反入侵场景的混沌工程实践
作者:[腾讯反入侵团队]jaylam 在繁杂的业务和网络环境下,在公司百万级服务器面前,要做到入侵发生时的及时检测,那么反入侵系统的有效性,即系统质量,是至关重要的. 洋葱系统是腾讯公司级的主机反入侵 ...

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

本文纲要