回顾我经历的持续集成实践的不足

       过去了5年了，现在再来回顾当初做的持续集成实践似乎有些晚了，我的确脱离开发太久了。

暴经历：

       09年公司刚开使推行持续集成时，我作为刚接触IPD流程不久的小白，对持续集成一无所知;同时作为组内的急先锋匆匆忙忙就上阵了。等到10年底持续集成即将在全公司推广的时候，我却离开了，可谓虎头蛇尾。

 

==============================

这里谈不足，主要是回顾持续集成实践一年多的时间里，我所做的工作的不足。

       公司所用CI工具是CruiseControl的二次开发版本，基于ant做build。而此时我们的java 项目还是依赖于eclipse的手工归档（这里不得不吐槽：先编译成class，手工统计更改的 java 类，再手工把对应的class用rar拖入上一版的jar包，土到家了）。

首先要面临的问题：如何自动打包归档。

当时还是太保守了，本着线上安全大于一切的原则，将之前的手工操作，用shell+ant来代替。 因为项目不是处于时刻能发布的状态，给后面的集成测试环境自动部署带来不小麻烦。 当时实际应该协调测试部进行全量测试后，一次性的解决“随时可发布”问题，一个人搞，在协调工作和沟通工作没有做到位。

接下来是代码规范和bug清零：findbug清零，checkstyle检查和pmd的圈复杂度。

由于自动UT的缺失，在bug清零和降低圈复杂度上推进很困难，原因就在于：无法确定修改代码的正确性，pmd的圈复杂度始终降不下来。

最困难的是UT：代码覆盖率

除新代码的UT用例外，还要补充老代码的UT，还要不影响项目进度。大大增加了开发人员的工作量，在合作团队里造成一些抵触。还有老代码很少考虑测试性，与DB ，第三方耦合过紧。当时相当于放弃了UT测试（不再测试方法），而直接针对业务流程的正确性做UT。 这样的好处是少量的测试代码能显注的提高代码覆盖率，但却失去了UT的本义。当时是有些急功近利了（CI报告好看）。

 

        当时的感觉是“一个人在战斗”，与公司其它CI负责人的交流很少。自已的沟通能力不足是一方面，另一方面公司缺少这种跨部门交流的氛围。我觉得应该是考核导向的原因，持续集成各项指标达标以后，关注CI的精力大大减少了。虽然QA保持每月对CI报告进行通报，但稳定的CI报告下面究竟隐藏着多少问题呢？

 

      与持续集成相符相成的敏捷开发，在我看来一直都流于开晨会这种形式，无法真正敏捷起来（缺少持续集成的保护），很失败。抛开缺少敏捷基因的原因，我觉得和项目环境关系很大。

      首先电信项目，是传统的甲方乙方这种的IT外包项目。项目从实施到开发都没有敏捷的动力：客户追求的是稳定，项目组追求的是低成本。对于只增加工作量，不增加效益的工作天生就是抵触的。这种抵触情绪会传遍整个项目组，本身外包团队就缺少技术氛围，这下使得团队更加的拒绝变化。这一特点在回到河南（客户第一线）来以后更是明显：成员（包括我）本能的通过裁剪开发流程（丢弃开发规范）来适应快速变化，而不是提高开发效率，基本上和一些小公司作坊式的开发一样，没有规范，没有文档，更没有持续集成，客户也习惯了这种方式。 使刚从总部回来的我，有些不适应。

        

        

评论

4 楼 paladin1988 2014-08-20  

我一直觉得HS的IPD流程很牛逼的了，当天的代码提交，findbugs， checkstyle，单元测试，每天持续的build，第二天早上关注各自的问题列表并进行整改。。。至于你说的圈复杂度降不下来，我估计是版本发布的周期太长了，而且桌前检查的推进力度不够，一般情况下都可以处理的吧。UT也是实在没有办法的事，HW很多项目都在赶，尤其到了交付的时候，大不多都是直接走业务了。。CI，就看在谁的手里用，用这东西的是谁，用得到的不仅可以提升项目的质量，提高开发效率，用得不好的，仅仅只是个工具而已。。

3 楼 white_crucifix 2014-08-09  

一看是电信项目就理解楼主的苦衷。
一句话，环境本身不具备这样的基因，就必然做不了这样的事

2 楼 james_lover 2014-08-08  

java_web_hack1 写道

没有必要一位的追求代码覆盖率
有些人为了追求代码覆盖率，连set、get方法都写UT，没有必要

因为CI报告是考核KPI，持续集成已背离了初衷。

1 楼 java_web_hack1 2014-08-08  

没有必要一位的追求代码覆盖率
有些人为了追求代码覆盖率，连set、get方法都写UT，没有必要