百度持续交付案例—微信语音分享实录
2019-12-26
来源：百度敏捷教练
要靠Build cop这个角色去主动的推动相关红灯的修复，让这个红灯尽快的解决掉，并且他要去落实，让大家去改善我们代码提交的习惯，如提交频次等。
另外一个要跟大家分享的是，就是我们这个团队，刚才大家也看到团队规模很大，涉及到几百人的规模，这么一个规模去推广相关的工作。从推广模式来讲，其实也是有一些技巧的，我们首先选取了大概30%的团队做试点，然后逐步去或扩展它的规模，见效之后，让大家在逐步的全部去做持续集成、持续交付。
我们发现大规模推广有很多难点，比如涉及的范围如果很广的话，就会有大量的人员参与进来，就会涉及大量人员的习惯改变，那么各个合作本身基础是存在一些差异的，所以我们更需要说不光关注整体要关注细节，而且我们需要一个相对好的方式，相对量化的方式，去做这种整体的推进。
基于刚才我们所说的，我们会建立CI Dashboard，采用数据驱动改进的模式。我们把所有相关的数据做这种统一的收集，统一的加工和处理，做一些数据的运算，那么得出来以下这么几个关键的图表。
第一个图是我们整体项目推进的CI情况的总览和分团队的总览，我们把一些核心的指标，比如说构建的次数，构建成功率，构建的时长，构建的测试的覆盖率，平均的修复时长，部署的情况，部署的次数，部署的时长等等这些指标收集起来之后，绘制出一张趋势图，通过这张趋势图就可以整体去看，我们整个的改进的工作开展的效果怎么样？这个指标是上去了还是下来了，那如果下来了，那我们就要进一步做分析。
在第一张图的基础上，我们就得出了第二张图，数据的筛选和下钻，那么这个就可以去看到各团队本身的数据，各团队本身他的CI和CD开展的是不是足够好？那些指标是不是达标，我们要通过这张图去看。
第三张图就是我们对于核心的数据汇总，这是我们要看它的环比的变化的一个趋势，每周、每月、每季度这种数据是向好还是向坏。
最后一个图，关键点是我们要做异常分析，比如说某个模块有60%多的问题都是代码问题。首先我们认为这是一个比较好的数字，因为我们在发现问题，发现代码的问题，说明它是有效的。
我们回过来要想，这种代码的问题有没有可能在前面的过程中被发现和解决，比如说在L3级的测试，还发现这么多的问题的话，你在L2级的测试有没有可能通过自动化的补充、案例的完善，让这个问题能够提前发现？再比如说我们这种环境的问题，如果有很大量的环境问题，会影响你CI的这种成功率，那我们一定要去修复环境的问题，让您整个CI的过程中有效性做进一步的提升。
所以通过以上这个过程，我们对CI应该是分析的比较清楚了。同时，我们也阶段性统计出了一下最终的效果，比如说我们的测试周期，整体上缩短了40%以上；对线上的故障，尤其是程序类故障，减少了大概55%；在持续集成推广到一定程度后，我们测试周期有了明显的缩短，整个系统的质量也得到明显的提升。
但是，我们从端到端的角度来看还会有一些问题：
RD经常会反馈一个小的Feature，两天就开发完了，但各种环境、各个集群的上线加起来时间很长，某些情况下需要一周的时间。
运维人员操作的时候，会发现环境很多，而部署过程因为专业性很强，只能我们运维同学去操作，那这样话要等时间窗口、等排期，这个排期本身会使你整个周期拉长很多。
在部署过程中，会涉及到多的平台在切换，比如说在A平台去提交的一个代码，在B平台做
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
