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