浅谈敏捷开发之如何提升持续集成效率

发布日期:
2017-10-06

浏览次数:

敏捷开发的优秀实践中非常重要的一个实践就是持续集成(Continuous integration)。持续集成通过每日至少一次的自动构建,完成代码编译,自动执行自动化测试用例,构建完成后自动输出构建报告。在敏捷开发的迭代开发过程中坚持持续集成,可以将集成工作进行分散并提前,通过逐步合入通过功能验证的代码,既能在早期就发现和解决问题,降低问题解决成本,提高问题解决效率,同时也有效避免了在产品最终集成时问题的集中爆发。

在某公司的敏捷开发项目中,持续集成库大部分时间都是处理构建失败的状态。无论是管理者还是研发人员,都对此抱怨不断,却没有好的办法来应对。管理者认为持续集成工具不好,开发人员能力也不够,持续集成库没有起到应有的作用。少部分研发人员认为持续集成已经是象征意义大于实际作用,作用不大,不过大部分研发人员还是认为持续集成是个很好的工具,就是应用很麻烦,上代码成了一件苦差事,为了每天的代码能通过持续集成,每天都要加班到很晚才能回去,感觉很累,对持续集成也产生了一丝迷茫。

为何一个好好的实践不仅没有起到应有的作用,反而遭到了大家的质疑,甚至成了工作的阻碍因素,降低了工作效率?通过对其他敏捷开发项目的调研,发现都存在类似问题。经过分析总结,大致可以分为以下几个方面的问题:

·         持续集成构建失败的原因定位困难,责任难以区分。代码定位信息少,开发人员拿到构建失败错误信息难以迅速确认问题根源所在,甚至难以定位出错模块,各模块互相推拖责任

·         代码/用例集中上库。平时持续集成库大部分时候处于失败状态,开发人员一般不能把代码合入,只能在迭代接近结束需要验证时才集中将代码/用例上库,然后按照构建失败信息依次攻关解决问题。同时由于不是及时上库,上库时出现漏合代码,或者用例没有同步合入

·         修改代码异步上库问题。有些问题的修改涉及多个模块,问题修改责任人汇总各模块修改代码,在本地构建通过,与各模块修改人约好上库时间后代码上库,但其他模块因为某种原因代码没有及时上库

·         整体责任意识不够。部分人员把持续集成当成了测试工具,在未经过本地充分验证的情况下就把代码和用例上到集成库

·         代码配合问题。修改接口函数,没有通告相关使用人员,导致其他模块调用该接口失败

·         代码被覆盖问题。代码上库了,当时构建成功,但晚上再次构建或者隔天构建时却发现构建失败,经过代码排查发现前面修改的代码被其他开发人员合入时覆盖掉了

·         自动化用例质量不高。对单元/集成测试用例脚本质量重视不够,用例点覆盖不够全面,或者用例构建不能涵盖场景,在本地验证时未能发现问题,在上升到系统集成层面问题才突然爆发出来

那么该如何才能将持续集成的作用真正发掘出来,使之成为开发人员提高效率、提升质量的利器呢?

首先应该从管理上重视起来,持续集成的通过与否与应该放到一个比较高的层次来看待。及时修复失败的构建。这需要作为团队最高优先级的工作,团队成员必须在最短时间内响应并修复,不能定位的需要尽快求助

其次应该建立起持续集成配套的保障措施,强化开发人员一次性做好事情的意识

·         持续集成状态可视化,报告信息全面。这样可以及时跟踪持续集成状态,在构建失败的情况利用状态报告以及日志等信息来协助研发人员快速定位构建失败原因

·         建立分层分级的持续集成环境。逐层逐级进行构建,提高构建效率

·         建立有效的产品代码/用例合入管理规范。保证代码/用例及时、准确合入持续集成库

·         建立完备和准确的自动化单元测试和集成测试脚本。这是持续集成的质量保障

相关推荐