持续集成之路

晨曦之光 发布于 2012/03/09 12:11
阅读 370
收藏 2

    去年的公司从上至下全力推行持续集成, 各大部门, 各小部门, 个项目组, 强推持续集成, 汇报工作的第一句话: “你们的持续集成报表在哪? 发给我了吗?”, 经过cruisecontrol集成过后的ICP-CI 成为一道亮丽的风景。 各个部门委派代表参加公司的持续集成, 最后的我们部门的景观是:三个小部门公用了一个持续集成环境, 持续集成的部署者只有一个, 小部门很多人还没有弄清楚持续集成是什么的情况下, 将代码统统交给部署者进行CI——不管是已经完成的项目, 还是正在进行的项目, 都倾巢而出.最后, 领导对持续集成关心程度降低, 唯一的CI部署者的退出, 整个部门的持续集成彻底完蛋。

 

1. 持续集成的目的是提高代码质量. 但仅仅是手段, 没有重视代码质量的高素质团队, 持续集成最终会成为花架子.

 

2. 持续继承关注的指标需要有重点.  首推的是代码重复的问题, 其次是单元测试, 后续的指标如圈复杂度, 代码风格, CCT之类的, 应该缓行.

 

3. 持续集成, 是由团队成员掌控, 不应该交给第三方, 团队成员应该比领导更关注持续集成. 这样才可进行下去.

 

 

目前自己在团队中推行持续集成, 并将实践的进展逐步公布, 经过和团队的讨论, 持续集成的流程如下:

 

1. 形如Cruisecontrol的思路, Ant脚本是管理持续集成的不二方法

 

2. 项目组属于平台性质的项目组, 项目繁多, 并且每个项目都涉及十来个插件工程, 各插件工程相对独立. 解耦合是关键, 每个工程配备独立的xml脚本, 在项目的维度上, 配备一个全局的xml, 定制各个需要的工程的xml.

 

3. 先compile, 后junit, 然后simian. 若无必要, 其它的不再作为持续集成的指标

 

4. 综合cuisecontrol的其它配置工具, 如发送报表, 发送邮件, svn等功能, 持续优化持续集成环境.  个人觉得, 一个好的计划, 永远是原型+ 持续优化. 就好比盖房子, 先搭房子的框架, 最后才是装修.  框架即原型, 装修即优化. 始终要有一个坚定的认识: 过早优化是万恶之源.

 

未完待续.

 

 

 

 

 

 

 

 

 

 

 

 


原文链接:http://blog.csdn.net/ostrichmyself/article/details/5551616
加载中
返回顶部
顶部