团队持续集成手记

早就想试试持续集成.终于有机会了.
刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.
hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.
我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.
在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.
之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.
之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.
此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.
其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!
hudson,很和谐!

早就想试试持续集成.终于有机会了.

刚开始用cruise-control但是免费版有使用限制,而且界面似乎也不是很友好.没用的信息比较多.所以在忍受了1周以后废弃,改用hudson.

hudson比想象中的简单.安装和配置过程不说了.没什么难的东西,多尝试几次即可.

我们的项目用到的是ivy和ant,据说如果项目使用了maven的话就更简单了.”因为hudson和maven的搭配几乎可以用天衣无缝来形容”.

在使用了hudson将我们的所有模块导入后,整个构建越来越稳定了.而且build fail总是可以在第一时间捕捉并消灭掉.团队初尝ci的好处.

之后我们在构建过程中加入了自动化单元测试和覆盖率工具,当我们发现项目中broken的测试时,团队成员居然自发的去修复他们.在引入单元测试和覆盖率工具3天后,所有单元测试都pass,测试通过率100%.但团队对覆盖率这个东东还不是很了解.似乎也没有多少动力去提高他.此时,覆盖率只有40%左右.

之后我们又引入了findbugs和PMD,发现代码中存在的大量坏味道.此时ci-game插件起了作用.因为每改一个相应的”bug”都会有相应的分数.整个团队掀起了”打怪”狂潮.甚至加班打怪的情况.1周后,我们消灭了90%的不良代码.期间虽然会出现一些改错的地方.但基本上通过持续的代码review(因为所有团队成员都在不停的review代码),即便少有的几次改错的地方也是在第一时间发现并纠正了.

此时,似乎没有什么”怪”可以打了,但ci-game的竞争仍然激烈.此时团队发起了覆盖率提升行动,通过将不同的模块划拨给不同的小组,然后设置一个预期的目标(比如让aaa模块的测试行覆盖率从50%提升到70%.并且每提升1%都可以有5分.ci-game再一次大显神威.覆盖率行动成功并按照计划达到目标.

其实所有这些自动化的事情都可以在每ci工具的情况做到,也可以有类似ci-game这样的机制来提高团队对提高代码质量的积极性.但hudson提供的对代码的”透明”,让所有人都可以随时看到代码有哪些问题,改进的如何,更重要的是意识到自己写的代码是会被别人看到的!

当基础模块部分基本稳定后,我们将应用模块也做到自动化构建和发布到开发集成环境.每小时进行一次发布.确保了我们集成开发环境始终都有最新的版本. 后续我们准备将自动化smoke test也做一些,也许不需要很彻底,只需要基本的接口可用即可.

hudson,不,持续集成,很和谐!

Comments are closed.