京东持续集成实践分享
在这篇分享中,我们可以看到京东在持续集成的历程是如何从无到有的。京东现在的持续集成设计的架构是什么样的?提供了哪些服务?解决了哪些痛点?以及在使用持续集成以后,给京东APP测试流程带来了哪些收益?
首先,让我们看一下京东在持续集成的历程。开发和测试是一对接的关系,所有的测试都是在开发的下游。测试必须等待开发工作全部完成后才能开始测试工作。这会产生一些问题,如测试团队各自为战,每个测试团队都会有自己的测试模块,测试模块对应不同的开发,造成的问题是每个测试团队都是各自为战的。
在这种情况下,测试团队会等待开发的包,开发这边如果说工作很忙,或者说本地代码出问题了,测试就只能等着。新bug,追溯源困难。测试过程中发现了一些BUG,但今天一天开发给你许多提测包,开发说这个BUG什么时候引发的,上午测试的时候有没有发现。那你只能根据你自己本地文件时间排序,大概找一下上午第几个包出问题,这个包引发的代码变更,包括一些东西你都不知道,你完全是一个黑盒的状态去开发那边拿包。
测试自己本地打包测试,熟悉成本太高。有的测试人员等不及了,我自己本地拉代码编译打包吧。肯定也有这样的测试,这种测试可能会插入一些自己需要的代码的测试插桩的东西,包括做一些埋点的东西。这样做测试的话,对测试要求比较高。特别是安卓和IOS的环境,IOS涉及到一些证书及配置的管理。测试同学如果对这块不是特别了解的话,会经常造成编译失败,编译失败的错误日志还看不懂,得找开发问这个错误是什么原因导致的,是不是某个编译的环境或者某一条编译的设置是需要改的。
模块1测试完了,模块2还没提测。我们某个测试团队已经完成测试了,但还有测试团队的包还没拿到,还没有测完,就会造成集成项目的delay。整个项目的集成就被另外一个模块拖住了。诸如此类还有很多的问题,都是因为分散测试管理模式导致的问题。
因此,我们期待怎样的改变?我们期待能够通过持续集成统一出日常提测包,这样就不需要找开发进行对接了。我们需要有一个统一的持续集成平台来拿到提测包。同时我们能够通过持续集成追溯哪个包或哪个构建的时候出的问题。我们也希望能够追溯到哪个开发者提交的代码变更,以便更好地追溯问题的来源。
在使用持续集成以后,我们可以看到,测试流程变得更加高效。我们可以更快地发现问题,并且可以更快地修复问题。同时,我们也可以看到,开发和测试之间的沟通变得更加顺畅。开发不再需要等待测试的反馈,而是可以实时地看到测试结果。测试也不再需要等待开发的包,而是可以实时地拿到提测包。
京东的持续集成实践分享告诉我们,持续集成可以解决很多问题,提高测试效率,提高开发效率,提高整个项目的质量和效率。