[size=medium]粗略翻了一遍jolt大奖书籍《持续集成:软件质量改进和风险降低之道》,发现基本原则和我前面在做的并无差别,不过对方显然是百试不爽经验丰富,我在具体操作的过程中却停下了无数次,按照阳明先生的话来说,不能实践的知,实在不是真知,结合自己的认识,把读书后获得的一点小的总结放到后面,用来逐步改善自己的工作。
实现持续集成的第一个要点,简言之就是需要实现“一键构建”,展开来说那就是“在任何情况下,都能根据需要,从指定的服务上获得无二义性的一份材料来顺利完成这个构建过程”。这个讲起来有点抽象,不过拆开分为几层意思来说就明了了,要获得无二义性的构建材料,包括代码、配置等,那么肯定就需要版本管理工具的介入了,如集中式管理代码的svn,分布式管理代码的git,都是这类工具中的翘楚;获得了可靠的素材,构建还需要隔离环境或者配置变化带来的伤害,比如在开发者自己机器上运作构建,而不能运行到服务器上,那么就不是好的构建,这个时候需要通过一些配置项来调整平台或者其它构建环境的差别;第三个从这里引申出来的要点,那就是构建不能依赖于具体的IDE,因为这并非是所有环境都应该有的东西,这点我体会尤深。
持续集成的第二个要点,就是在上面第一点的基础上,需要在构建过程中,必须加入能够度量产品质量的一系列工具或过程。这点就很好理解了,持续集成不是为了持续的编译代码,或者说不只是。更多的是监控在变化的过程中,是否引入了复杂性、重复度、不好的代码风格、隐藏的bug。这些都是一个产品健康与否的关键指标,恰如一个人的身高体重血压,只有具备了这些过程,构建才能对产品形成一个客观的报告,在这方面我用过的工具就有sonar,pmd,checkstyle,findbug等,当然,这里有一个并非现成的工具,而需要开发者辛勤的去积累的一个东西,那就是对于产品的自动化测试代码,根据我的实践,在一个既有代码全无测试的工程里加入测试,背负的历史包袱不可谓不重,报告里对代码测试覆盖率极低的数据,又会成为开发者最终放弃做单元测试的理由,这个大概可以用“破窗理论”来解释,一旦开发者觉得无望处理遗留的代码,他就有可能转为顺从历史,也放弃写测试,进而导致这个洞越来越大。这事我觉得较为靠谱的或许就是由开发者坚持对新功能加测试,然后对于出现问题的老代码加上测试,逐步进行。
然后是持续集成的第三个方面,这个点可以很自然的从第二点推导而来,既然我们视集成构建是一件“有用”的事,而非一个玩具或者一种时髦,那么第二步加入的度量报告就必须受到严肃的对待,这些数据必须及时的通知到对应的人员并及时处理。简单的一些原则包括:必须尽快修复失败的构建;开发者争取建立自己的私有构建过程,避免提交不能构建的东西到版本库等。通知和展现这个目前持续集成的工具都做的比较好。我用过的hudson及其各种插件能满足大部分场合的应用,最要关心的反而是人的环节,必须有人对持续集成产生的报告做持续的跟进,并及时抛出一些需要团队注意的问题,这样才能规避一系列的开发风险,提高开发的质量和效率。[/size]
实现持续集成的第一个要点,简言之就是需要实现“一键构建”,展开来说那就是“在任何情况下,都能根据需要,从指定的服务上获得无二义性的一份材料来顺利完成这个构建过程”。这个讲起来有点抽象,不过拆开分为几层意思来说就明了了,要获得无二义性的构建材料,包括代码、配置等,那么肯定就需要版本管理工具的介入了,如集中式管理代码的svn,分布式管理代码的git,都是这类工具中的翘楚;获得了可靠的素材,构建还需要隔离环境或者配置变化带来的伤害,比如在开发者自己机器上运作构建,而不能运行到服务器上,那么就不是好的构建,这个时候需要通过一些配置项来调整平台或者其它构建环境的差别;第三个从这里引申出来的要点,那就是构建不能依赖于具体的IDE,因为这并非是所有环境都应该有的东西,这点我体会尤深。
持续集成的第二个要点,就是在上面第一点的基础上,需要在构建过程中,必须加入能够度量产品质量的一系列工具或过程。这点就很好理解了,持续集成不是为了持续的编译代码,或者说不只是。更多的是监控在变化的过程中,是否引入了复杂性、重复度、不好的代码风格、隐藏的bug。这些都是一个产品健康与否的关键指标,恰如一个人的身高体重血压,只有具备了这些过程,构建才能对产品形成一个客观的报告,在这方面我用过的工具就有sonar,pmd,checkstyle,findbug等,当然,这里有一个并非现成的工具,而需要开发者辛勤的去积累的一个东西,那就是对于产品的自动化测试代码,根据我的实践,在一个既有代码全无测试的工程里加入测试,背负的历史包袱不可谓不重,报告里对代码测试覆盖率极低的数据,又会成为开发者最终放弃做单元测试的理由,这个大概可以用“破窗理论”来解释,一旦开发者觉得无望处理遗留的代码,他就有可能转为顺从历史,也放弃写测试,进而导致这个洞越来越大。这事我觉得较为靠谱的或许就是由开发者坚持对新功能加测试,然后对于出现问题的老代码加上测试,逐步进行。
然后是持续集成的第三个方面,这个点可以很自然的从第二点推导而来,既然我们视集成构建是一件“有用”的事,而非一个玩具或者一种时髦,那么第二步加入的度量报告就必须受到严肃的对待,这些数据必须及时的通知到对应的人员并及时处理。简单的一些原则包括:必须尽快修复失败的构建;开发者争取建立自己的私有构建过程,避免提交不能构建的东西到版本库等。通知和展现这个目前持续集成的工具都做的比较好。我用过的hudson及其各种插件能满足大部分场合的应用,最要关心的反而是人的环节,必须有人对持续集成产生的报告做持续的跟进,并及时抛出一些需要团队注意的问题,这样才能规避一系列的开发风险,提高开发的质量和效率。[/size]