持续集成 持续集成监控平台:监控什么?

肖哥shelwin · July 29, 2019 · Last by 肖哥shelwin replied at July 30, 2019 · Last modified by admin 卡斯 · 1375 hits

在不久之前的一篇文章中,我讲到自己上半年最重要的工作是完成了一个持续集成(CI)监控平台的开发。文章发出来之后,不少同学私信与我联系,问的最多的一个问题就是这个CI监控平台到底在监控什么。今天就和大家聊聊这个话题。

CI是一个不间断运行的系统。这个系统持续产生大量数据。对CI系统的监控,一定不是"胡子眉毛一把抓",而是"有所为有所不为"。

那些对研发团队有帮助,对CI工作改进有意义的数据,才是我们需要重点监控的。在我看来,这些数据包括但不限于以下方面。

CI稳定性数据。稳定性是CI第一位的事情。对于开发者来说,他们最关心的就是CI有没有中断,是不是稳定。CI中断意味着CI失败率100%,团队研发工作彻底停摆。

实时的CI中断状态,决定了开发者能否提交代码;历史的CI中断次数,中断时间,中断部位等统计数据,能够帮助我们客观识别CI的薄弱环节,并对症下药予以改进。

100%失败率的CI是停摆的。100%成功率的CI也没有实际意义。实际情况通常介于二者之间,即CI*概率性失败*。由当前代码改动导致的CI失败,是可以接受的,也正是CI存在的意义。

然而,与当前代码改动无关的CI失败,却是我们需要留心的,因为它直接影响开发者体验和CI公信力。一般来说,真正会产生CI失败的代码改动是很少数的。CI的成功率数据,能够一定程度上反映CI是否稳定,我们需要监控它。

具体的CI不稳定因素,则可以通过统计主干上的CI失败情况(失败环节,失败用例,错误消息等)来大致识别。了解CI实时的成功率和当前已知的不稳定因素,对于开发者提交代码和分析CI失败是有帮助的。

CI效率数据。"天下武功,唯快不破"。对于CI,尤其如此。对于开发者来说,有两个数据很重要,一是在pre-merge CI阶段,从触发CI任务到获得CI结果的时间;二是在post-merge CI阶段,从代码改动合入主干到最后出包的时间。

我们需要监控这些数据。进一步,CI各个任务和阶段的执行时间,以及等待特定资源所消耗的时间,通常也是需要我们监控的。

CI质量数据。CI的中心任务是通过多个环节的检查和测试,在代码提交阶段尽可能发现更多软件缺陷。CI的质量,反映的是CI是真的能够发现代码改动带来的缺陷,还是仅仅在空转。如何度量CI质量是一个见仁见智的话题。

在我看来,CI各个测试环节的覆盖率数据,是反映CI质量的重要方面。这里的覆盖率主要是代码覆盖率,其次是需求覆盖率和缺陷覆盖率。通过监控测试覆盖率数据,我们能够了解CI各个测试阶段的有效性,以及识别没有或很少被覆盖的代码区域,并有针对性地改进。

研发效能数据。除了CI自身的稳定性,效率和质量数据之外,研发团队的相关数据也是我们可以监控的。这方面数据可以有很多,举例如下。

代码提交数据:监控每一个合入的代码改动数据,包括改动类型,提交者,合入时间等。基于时间维度进行统计,可以了解团队给定时间内的总体工作量;依据开发者维度进行统计,可以识别活跃的开发者。分析代码提交时间,甚至能够从侧面反映大家的加班情况。

代码评审数据:监控代码评审系统上的评论数据,包括评审者(Reviewer),被评审者,代码改动链接等。基于这些数据,可以统计项目代码评审情况,例如总的评论数量,零评论的代码改动占比等,也可以识别出对团队贡献较大的活跃评审者。

以上就是个人认为的CI监控平台需要重点关注的数据。需要强调的是,数据监控不是我们的目的,利用监控到的数据改进工作才是我们的目的。并且,工作是否真正得到改进,还需要基于后续监控的数据进行客观评判

感谢大家的阅读!另外,想看一些测试开发,持续集成,Python编程等领域原创文章的同学,欢迎关注我的个人公众号测试不将就同名博客,谢谢。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 6 条回复 时间 点赞

能讲下是如何实现的么?ELK如何?

挺好的,感谢大佬分享!

这不点赞那给什么点赞!

谢谢支持!

hanhero07 回复

实现层面是另外一个话题,大家感兴趣的话我可以另写一篇文章讲述背后的技术栈

STF 回复

感谢支持!!!

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up