黑岩文学网
怀旧美文

如何做好持续集成

作者: 来源: 时间:2019-08-10

前段时间,老大说最近有好几个团队都有做持续集成的想法,建议我们就这两年积攒的经验(踩过的坑)给大家分享下。

什么是持续集成

说到持续集成,我们好多同学不由自主地就想起了Jenkins等平台工具,前几年和老大一起推行持续集成还开发了一套系统。

其实这些工具也好、平台系统也好,都是为了持续集成能够正常运转服务的。那什么是持续集成呢?我们可以分开来看:

  • 持续就是每完成一个完整的部分,就向下个环节交付,发现问题马上调整,不会放大到其他部分和后面的环节;

  • 集成就是软件个人研发的部分向软件整体部分交付,以便尽早发现个人开发部分的问题。

  • 总而言之,持续集成本质是一种思想,一种工作方式,强调开发人员提交了新代码之后,立刻进行构建、测试,以保证新代码和原有代码能正确地集成在一起。我们在推行持续集成时,千万不要本末倒置了,这件事最核心是培养大家的意识和工作习惯,而不是去推行什么工具平台。

    为什么要做持续集成

    在软件工程里,有一个指标叫做质量成本,即项目出现质量问题的修复成本。下图是各个阶段软件质量成本的评估:

    我们不难看出,随着时间的推移,质量成本以指数级趋势增加。所以我们做持续集成的根本目的就是为了尽可能早地发现、解决质量问题。

    怎么去做持续集成

    我们可以先从什么是持续集成来分析都要做哪些工作,主要有以下三个方面:

  • 代码提交的监控

  • 工程的构建以及测试的运行

  • 结果的反馈以及推进修复

  • 再从为什么要做持续集成来分析如何做好这件事。为了保证质量问题能够尽早地被发现和解决,还是从上面的上三个方面来说。

    监控代码提交

    现在各种持续集成的平台都提供监控代码库的功能,我就不详细介绍了。这里我想强调的是有些同学并不会在完成一个完整部分时就将代码提交仓库,有些喜欢憋大招,一次性给你整个几百上千行代码。所以这里强调必须让开发同学及时提交代码

    那怎么去控制,方法有很多。目前我们这边是通过Code Review机制以及一些规范约束来规避的。引入Code Review后,为了尽快能过审,大家都会尽快提交,同时一次性提交太多代码Review的成本也会很大,所以开发自己就会定一些流程规范去约束。当然Code Review的好处还远不止这些,强烈推荐,非本文主题这里就不详述了。

    工程构建和测试的运行

    持续集成是为了让整个项目运转更加健康高效,如果因为跑持续集成而拖慢了进度那就得不偿失了。所以这里须要保证工程的构建和测试运行足够高效,时间没有固定标准,但按照我们以往的经验,最好不要超过5分钟

    这里可能同学要说我们项目的测试5分钟实在跑不完怎么办?没错,这是很常见的问题,我们也不可能在5分钟内跑完所有的测试。所以这里就涉及到一个测试用例的筛选,主要可以从下面两个思路来考虑:

  • 用例的重要性和出现问题的概率。将一部分非常重要路径和容易出问题的用例筛选出来,每次持续集成只跑这部分测试用例,这样能保证大部分问题都能及时被发现。

  • 测试用例与提交代码的相关性。这个就是精准测试的思想,如果每次只跑与这次代码相关的测试用例是最好不过的。不过这个想做好也很难,因为相关性不好评估。现在大多数精准测试都是用代码覆盖率来做,不过这样一旦修改了底层代码,就有可能关联上所有用例,而且新代码的集成也可能会导致用例和代码的映射关系发生变化。


  • 综上,大家可以项目的需要和成本自己选择怎么去筛选测试用例,如果条件允许建议二者结合使用,同时建议定期(一般是每天)去跑全量的用例

    结果的反馈以及推进修复

    最后就是检查结果,如果有问题及时推进修复。这是整个过程中最重要也是最难做的一个环节,首先必须要保证结果的准确性,然后得让开发同学有及时处理的意识。第二件事事建立在第一件的基础上,如果你的测试结果老是误报问题,开发自然就会不积极去响应甚至忽视持续集成的结果。

    那么如何提高测试结果的准确率呢?主要有两个方面:

  • 测试代码的健壮性。当然健壮性不是指不管出现什么情况用例都能通过,那就没有意义了。这里是指对本用例测试点无关的点有足够好的健壮性。比如:测试输入法纠错算法的用例就不应该受到词库变动的影响。

  • 测试用例的专一性。同理,测试用例的设计也要保证足够专一,每个用例对应一个测试点。否则一旦用例失败了,查问题都不好查。


  • 当然,我们的集成测试肯定还有要有的,这里的测试用例的设计就非常关键了,必须要保证非常强的合理性。比如还是输入法纠错,如果要测试整个流程没有问题,我们就必须选择一个非常合理的Case,就是这条用例不按照我们说的做就是有问题,哪怕是词库数据修改导致的也说明你们数据修改的不合理。

    最后,结果的准确性还不止这些,除了不能误报问题,更不能漏报问题。误报了我们还可以花时间处理,漏报了那就是事故了。所以如何保证测试的覆盖度是我们工作的重中之重。这里集成级的测试还好,一般软件整体结构功能变化的还是比较少的,而且一旦有也是从结合需求,我们有足够的时间去补充修改用例。不过单元层次的就难说了,随时都有可能会增加或者修改函数,所以这一层测试建议最好由测试和开发同学一起来维护。

    总而言之,需要让测试结果具有十足的意义,强化团队对系统的信心,这样问题的修复甚至都不用我们去推进了。

    写在最后

    写了这么多,我完全没有提到任何测试工具和平台的使用,是这些都不重要吗?当然不是,只不过任何的平台和工具都是为解决问题服务的,只有想清楚了问题工具才能发挥最大的效果。反之亦然,想发挥出最好的效果具体工作还是要依靠各种平台工具,这也是为什么我懂了这么多,团队的持续集成还是一团烂摊子。


    1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源; 2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任; 3.作者投稿可能会经我们编辑修改或补充。

    相关文章
    • 西澳大利亚最震撼的15个国家公园深度盘点...

    • 如何拍出一张完美的裸照?

    • “产品+服务”双料齐下 哈弗CACSI评...

    • iPhone XR今开卖,面板良率问题1...

    • 还需进一步消化整理

    • 这个概念会是题材反弹的先锋!民企春天将至...

    • 《三国杀》出了一个50万的周边

    • 糟心!日照一小区垃圾散一地!规矩何在?