- 浏览: 806129 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (488)
- struts1 (4)
- spring (13)
- extjs (36)
- mysql (3)
- sqlserver (2)
- oracle (37)
- 杂谈 (11)
- 面试相关 (35)
- Java基础知识总结 (5)
- Java重要知识点 线程和io流知识点 (6)
- 服务器相关 (1)
- 生活 (1)
- jsp (7)
- servlet (2)
- junit (3)
- struts2 (9)
- 开发必备 (4)
- 使用开发工具总结的知识 (4)
- ibatis (12)
- ajax (2)
- dwr (2)
- jquery (1)
- 设计模式 (4)
- Lucene的学习 (5)
- 经验总结 (19)
- mysql全文搜索相关 (7)
- hibernate (33)
- Sphinx (1)
- log4j的总结 (1)
- 敏捷开发 (9)
- 持续集成 (15)
- UML使用总结 (1)
- Scrum (1)
- OO(面向对象编程) (1)
- struts1和struts2总结 (1)
- 数据库加密 (1)
- 多线程和Socket编程 (6)
- PowerDesigner (2)
- 权限相关 (1)
- ant应用总结 (4)
- 面试必知知识点总结 (6)
- io流与nio流总结 面试相关 (1)
- 敏捷管理工具的使用 (7)
- hsqldb相关 (1)
- svn源码相关 (2)
- debug调试技巧总结 (1)
- hibernate和ibatis对比相关 (6)
- eclipse mylyn 插件的使用总结 (2)
- fisheye使用总结 (2)
- java泛型总结 (1)
- ssh整合总结 (10)
- SpringSide的学习总结 (1)
- JPA学习总结 (2)
- RoR 总结 (2)
- 模型驱动 总结 (1)
- Oracle SQL优化技巧 (4)
- 数据库相关资料 (1)
- oracle练习相关 (4)
- PowerDesigner 使用总结 (2)
- Struts实现国际化相关 (2)
- 权限框架 Spring Security (1)
- freemarker使用总结 (1)
- jsp servlet总结相关 (3)
- Java NIO总结 (1)
- 自己学习必须 (3)
- 蝴蝶容器相关 (2)
- eclipse插件的使用 (1)
- myeclipse的使用 (1)
- flex相关 (1)
- javaeye重生后总结的知识点 (2)
- 公司学习总结 (3)
- JAXB 相关 (1)
- ECSide (1)
- EdoJs 企业ajax框架 (1)
- RSA加密算法 (1)
- jbpm相关 (1)
- JMF原理 (1)
- MyEclipse使用总结 (1)
- Funsion Charts 相关总结 (3)
- 常用知识2011 (2)
- Flex与Java整合 (1)
- IBM WebSphere相关 (1)
- jQuery使用技巧 (2)
- 2011年面试相关知识点总结 (2)
- sqlserver开发相关 (8)
- eclipse 打jar相关 (2)
- Oracle/Mysql/SqlServer比较 (1)
- WebService Axis1.4开发相关 (4)
- 进制数的转换 总结 (1)
- WebService Axis2.0开发相关 (0)
- iteye Struts2 Spring Hibernate整合相关 (3)
- iteye osgi资料相关总结 (1)
- iteye ifos相关相关 (1)
- iteye 国际化相关 (1)
- iteye Hibernate缓存机制 (4)
- iteye Struts2 总结 (1)
- iteye Struts标签总结 (0)
- iteye web配置文件大全 (6)
- iteye Efs 框架总结 (1)
- iteye sql优化 (2)
- iteye 大数据量高并发的数据库优化 (1)
- iteye 开发相关 (1)
- iteye s1sh 和 s2sh整合中的问题以及解决 (1)
- iteye s1sh整合实例 (1)
- iteye s2sh整合实例 (1)
- iteye 面试相关 基础篇 (1)
- iteye Android相关 (1)
- iteye 面试相关 Web篇 (1)
- iteye Sql Server相关 (0)
- iteye struts1与struts2比较 (1)
- iteye jquery 和Struts2 (0)
- iteye struts2与其他插件整合 (0)
- iteye jquery 开发相关 (1)
- iteye eclipse结合spket(Ext,Jquery)开发相关 (0)
- iteye myeclipse 使用技巧相关 (0)
- iteye Memcached 缓存系统相关 (0)
- iteye 常用软件相关 (0)
- iteye 最新技术预览 AjaxSwing (0)
- iteye struts上传下载相关 (0)
- iteye 新技术相关 (0)
- test (0)
- iteye 开发Java游戏相关 (0)
- iteye Java反编译 (0)
- iteye XML解析相关 (0)
- iteye 压缩ZIP相关 (0)
- iteye 面试相关 (0)
- iteye Android开发相关 (4)
- csdn (0)
- e-inoc (0)
- iteye http错误码对应说明 (0)
- iteye 面试扩展知识点 (0)
- iteye oracle面试相关 存储过程,触发器,游标等 (0)
- iteye english study (0)
- iteye starflow工作流引擎 (0)
- iteye IBM WebSphere Application Server Toolkit使用相关 (0)
- iteye spring3 (0)
- iteye mybatis (0)
- iteye js技巧总结 (0)
- iteye SEO优化相关 (2)
- iteye QUI网页界面集成框架 (1)
- iteye AjaxAnywhere (1)
- iteye Nutz相关 (1)
- iteye ibatis技巧 (0)
- iteye dwz (0)
- 128个ajax/javascript框架 (0)
- iteye 2012 Java Swing教程 (1)
- iteye 码头集装箱相关 (1)
- iteye swing (2)
- 兼职工作 (0)
- 2012 新总结的面试相关知识点 常用知识点 (1)
- 淘宝网店相关 (0)
- oracle 常用函数 2012新总结 (1)
- 我的时尚潮流屋 (0)
- 2012 年 面试新总结知识 (1)
- 技巧 (1)
- 2013总结 (1)
- 2015工作相关 (3)
- springmvc (5)
- EasyPR-Java (1)
- java (2)
- editplus 4.0 注册码 (1)
- android (1)
- oracle连接数据库相关 (1)
- 编程资料总结 (2)
- 20160808 (1)
- visio 2013 (1)
最新评论
-
drew926:
泛型的类型参数可以有多个?这是java哪个版本支持的?
java泛型总结 -
listenan:
赞!非常感谢。
Scrum总结 -
cwscwj:
写的很深刻,谢谢,看了一遍,过段时间打算再看一遍。
Scrum总结 -
hwedwin:
w
Struts 2中的OGNL\EL的使用总结 -
lanni2460:
不错 很好 支持……
sqlserver三个驱动包下载
持 续集成在目前大多数的公司里都会有这样或者那样的使用。有的会选择一些Open Source的工具,如CruiseControl,Hudson,LuntBuild等等等等,有的会购买有更好服务,更强功能的商业产品,如 TeamCity,QuickBuild等等等等,而有的会选择自己实现,如Cron+Ant/Maven/Make等等。那么使用下来效果如何呢?真得 达到了预期的效果吗?我想来恐怕未必吧,否则也就不会有这么多的讨论了。
持续集成与敏捷编程
在敏捷领域中,测试驱动和持续集成被称为敏捷编程的两大基石,于是乎,很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际 上,早于敏捷编程概念的提出,持续集成作为一个best practice就已经被很多公司采用了,只不过作为一个概念,则是由Martin大叔为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种 practice,并不被什么开发模型所限制,在任何一种开发模型中都可以采用,也可以运行得非常理想。
持续集成还是阶段集成
有很多人说,我不做持续集成,照样工作的很好。因为我们一个(小)阶段出一个版本,照样控制得非常好。我得恭喜你,首先持续集成也好,阶段集成也罢,你做了,做了就好,比没有做要好很多,也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。
那么究竟那种方式更加理想,更加符合项目的开发和管理呢?其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete》(代码大全)里有过回答了。他说:对于一个微型 程 序来说,阶段式的集成或许是最佳方法。何谓微型程序,他说就是那种两三个类的程序,而你又很走运的话,那么阶段式集成就可以是你的最佳方法了。当然,这位 老兄是个老美,我们也都知道老外嘛,都比较笨一点,不会转弯一点,所以呢,他说微型程序,对于我们拥有5000年文明的中国人说,可以再扩大点吧,对于一 个小型项目,就是那种二三十个类的项目,也许使用阶段集成也不会出啥子问题吧。不过,你要真的是懒到连个阶段集成都不愿意做的话,那么你至少也该到庙里点 支香,求求佛祖保佑你的项目一切顺利。
为什么要做持续集成
很多人肯定非常不苟同我的看法,他们认为即使没有做持续集成,甚至没有做阶段集成,但是项目一样按时的完成,甚至提前完成,而且照样完成的非常理 想,老板满意,客户满意,夫复何求?而做持续集成,无非就是动不动收到一封邮件,说这个build成功了,那个build失败了,不过就是一持续编译罢 了,我自己打个命令编译一下,不就知道了吗?要做个daily build,我还要颠颠的去set up,还要花力气去配置,效果也不见得好到什么地方去。
对于这样一些问题,我想首先我们还得搞清楚,究竟为什么我们要去做持续集成,持续 集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了,对于持续集成(在书中,Steve McConnell使用Incremental Integration的术语)有以下几点好处:
易于定位错误。 也就是当你的持续集成失败了,说明你新加的代码或者修改的代码引起了错误,这样你很容易的就可以知道到底是谁犯了错误,可以找谁来讨论。
及早在项目里取得系统级的成果。 因为代码已经被集成起来了,所以即使整个系统还不是那么可用,但至少你和你的团队都已经可以看到它已经在那了。
改善对进度的控制。 这点非常明显,如果每天都在集成,当然每天都可以看到哪些功能可以使用,哪些功能还没有实现。如果你是程序员,你不用在汇报任务的时候说我完成了多少百分比而烦恼,而如果你是项目经理的话,那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。
改善客户关系。 理由同上。
更加充分地测试系统中的各个单元。 这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。
能在更短的时间里建造整个系统。 这点恐怕要你实施以后才能得出结论。就我们而言,持续集成并没有为每个项目都缩短时间,但却比没有实施时,项目更加可控,也更加有保证。
随着时间的推移,持续集成带来的更多好处,也逐渐被认识到了,比如说:
有助于项目的开发数据的收集 。比如说,项目代码量的变化,经常出错的Tests,经常出错的source code,等等。
与其它工具结合的持续代码质量改进 。如与CheckStyle, PMD, FindBugs, Fxcop等等等等的结合。
与测试工具或者框架结合的持续测试 。如与xUnit,SilkTest, LoadRunner等等的结合。
便于Code Review 。在每个build里,我们都可以知道与前一个build之间有什么改动,然后针对这些改动,我们就可以实施Code Review了。
便于开发流程的管理 。比如说,要把一个开发的build提交给测试组作测试,测完满意了,再提交到发布组去发布。
还有很多很多的其它的好处,也许你可以告诉我吧。
怎么做持续集成
持续集成有很多很多的好处。可是持续集成要做好的话,本身就有很多的讲究。从持续集成工具的选择到持续集成具体实施,每一点都可能影响到你使用持续集成的效果。持续集成不是持续编译,也不是仅仅用来发发邮件的工具而已。
工欲善其事,必先利其器。首先选择一个好的工具很重要,在我另一篇帖子《持续集成工具的选择》中,我已提到过了,这里不再多说。用下来,我觉得QuickBuild真得很不错。
工具选好了,具体怎么做呢?这个没有什么标准可以遵循,每个项目都是不一样的,我谈谈我们这里的具体过程吧。
首先,我们对编码有一些规范需要遵从,所以我们制定了一系列的FindBugs和PMD的规则用于检查代码。
其次,我们使用Cobertura作为我们的代码覆盖(code coverage)工具。
再次,我们使用JUnit作为我们的unit test工具
基于上述几点,我们编写了我们的Ant脚本,这个脚本有一系列的task,基本上就是:
compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts
这个,也是Java领域中经常使用的一个完整的过程。
有 了这样一个脚本以后,我们开始配置我们的项目到QuickBuild中去,在QuickBuild中,我们配置一个configuration,然后设定 我们的SCM repository,对应于我们的ant task,我们配置了一系列的step,用于完成整个过程。由于我们的测试需要跨平台,所以对应与同一个unit test的task,我们使用QuickBuild的分布式的step功能,使之在不同平台上可以进行测试,这一点也是使用CI Server的一个好处吧。
对应于这个configuration,我们配置了四个子configuration,分布是 Development Configuration, QA Configuration,Integration Configuration和Release Configuration。这几个configuration分别对应于我们开发过程的四个阶段,我们的每日构建都是在Development configuration上的,所以我们配置为每日一次,而对于其它三个则不做自动的构建。因为我们是通过Promote来做的。对于 Development Configuration,我们没有对SCM自动打Label,而对于其它的,我们则对每一个Build自动对SCM进行打Label。
有 了这些以后,开发工作开始了,我们每天的代码在下班前都提交到subversion里去,第二天,Development Configuration就自动的编译完成了,并且发送通知给我们。我们通常会会开一个Morning Meeting,首先我们会到在QuickBuild的页面上,看到昨天有哪些个改动,测试的状况,比如说哪些测试修正了,哪些测试还没有被修正,哪些 source code没有通过代码检查。然后我们会点到具体的报告中去分析,这些报告都可以很容易的打开source code,我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。
经过这样开发之后一段时间,我们的功能很多 已经就绪,就可以提交给QA作test了,由于当日的构建可能失败,或者不是我们特别想给QA的,那么我们会选择之前几日的一个好的build做 Promote,这个promote就会自动触发QA Configuration去做build,QA Configuration的build做完以后,就会发送一个邮件通知QA Lead,这封邮件里QuickBuild会把所有与上一个QA build的changes都列出来,这样他就知道我们这个版本里增加了什么功能,修正了什么bug。
再如此经过几个迭代后,我们开发组和QA组 一致认为功能基本实现了,bug也不多了,于是就由QA的Lead做一个Promote,触发Integration Configuration不build一个大版本交给客户,做VOC (Voice of Customer),听却客户的意见,如果客户没有什么易见的话,那么就会在Integration Configuration上做一个Promote到Release Configuration上去。
通过这样做,我们基本上可以很容 易的知道每一个版本之间有什么变化,甚至我们可以很容易的重新build出任何一个时间点上的版本。而且,我们基本上无需操心什么时候给SCM打什么样的 Label,因为对于我们而言,我们需要看到的只是每一个版本的build。而如果用subversion来管理的话,也许你也可以通过命令来列出在 SCM中各个版本的变化,但是如果有一天,你头昏忘记打label的话,或者打错label的话,也许要找到这个问题就不是那么容易了。又也许,你可以通 过一系列的命令来完成这里提到的所有功能,但是我是懒惰的,而且很容易做错事情,所以我觉得如果机器可以完成的话,就让机器去做吧。
这些都只是我们在持续集成上的一点实践,也许你有更好的方式,也许你有更多别的点子,那么也请告诉我吧。
还有很多很多关于持续集成的事情可以说,多到可以写一本书了,如果你有兴趣的话,我觉得那本《Continuous Integration: Improving Software Quality and Reducing Risk》的书可以好好看看,非常详细。
持续集成与敏捷编程
在敏捷领域中,测试驱动和持续集成被称为敏捷编程的两大基石,于是乎,很多人的概念里就是持续集成是为了实现敏捷编程的。这是一个错误的认识。实际 上,早于敏捷编程概念的提出,持续集成作为一个best practice就已经被很多公司采用了,只不过作为一个概念,则是由Martin大叔为了推进敏捷所倡导并由此风靡起来。持续集成本身只是一种 practice,并不被什么开发模型所限制,在任何一种开发模型中都可以采用,也可以运行得非常理想。
持续集成还是阶段集成
有很多人说,我不做持续集成,照样工作的很好。因为我们一个(小)阶段出一个版本,照样控制得非常好。我得恭喜你,首先持续集成也好,阶段集成也罢,你做了,做了就好,比没有做要好很多,也使你的项目管理上了轨道了。这两者之间的区别仅是频率而已。
那么究竟那种方式更加理想,更加符合项目的开发和管理呢?其实这个问题Steve McConnell在他那本获得Jolt大奖的书《Code Complete》(代码大全)里有过回答了。他说:对于一个微型 程 序来说,阶段式的集成或许是最佳方法。何谓微型程序,他说就是那种两三个类的程序,而你又很走运的话,那么阶段式集成就可以是你的最佳方法了。当然,这位 老兄是个老美,我们也都知道老外嘛,都比较笨一点,不会转弯一点,所以呢,他说微型程序,对于我们拥有5000年文明的中国人说,可以再扩大点吧,对于一 个小型项目,就是那种二三十个类的项目,也许使用阶段集成也不会出啥子问题吧。不过,你要真的是懒到连个阶段集成都不愿意做的话,那么你至少也该到庙里点 支香,求求佛祖保佑你的项目一切顺利。
为什么要做持续集成
很多人肯定非常不苟同我的看法,他们认为即使没有做持续集成,甚至没有做阶段集成,但是项目一样按时的完成,甚至提前完成,而且照样完成的非常理 想,老板满意,客户满意,夫复何求?而做持续集成,无非就是动不动收到一封邮件,说这个build成功了,那个build失败了,不过就是一持续编译罢 了,我自己打个命令编译一下,不就知道了吗?要做个daily build,我还要颠颠的去set up,还要花力气去配置,效果也不见得好到什么地方去。
对于这样一些问题,我想首先我们还得搞清楚,究竟为什么我们要去做持续集成,持续 集成究竟可以给我们带来什么好处。同样在《Code Complete》里提到了,对于持续集成(在书中,Steve McConnell使用Incremental Integration的术语)有以下几点好处:
易于定位错误。 也就是当你的持续集成失败了,说明你新加的代码或者修改的代码引起了错误,这样你很容易的就可以知道到底是谁犯了错误,可以找谁来讨论。
及早在项目里取得系统级的成果。 因为代码已经被集成起来了,所以即使整个系统还不是那么可用,但至少你和你的团队都已经可以看到它已经在那了。
改善对进度的控制。 这点非常明显,如果每天都在集成,当然每天都可以看到哪些功能可以使用,哪些功能还没有实现。如果你是程序员,你不用在汇报任务的时候说我完成了多少百分比而烦恼,而如果你是项目经理的话,那么你也不再烦恼程序员说完成了编码的50%到底是个什么概念。
改善客户关系。 理由同上。
更加充分地测试系统中的各个单元。 这也是我们常讲的Daily Build与Smoke Test相结合带来的绝大好处。
能在更短的时间里建造整个系统。 这点恐怕要你实施以后才能得出结论。就我们而言,持续集成并没有为每个项目都缩短时间,但却比没有实施时,项目更加可控,也更加有保证。
随着时间的推移,持续集成带来的更多好处,也逐渐被认识到了,比如说:
有助于项目的开发数据的收集 。比如说,项目代码量的变化,经常出错的Tests,经常出错的source code,等等。
与其它工具结合的持续代码质量改进 。如与CheckStyle, PMD, FindBugs, Fxcop等等等等的结合。
与测试工具或者框架结合的持续测试 。如与xUnit,SilkTest, LoadRunner等等的结合。
便于Code Review 。在每个build里,我们都可以知道与前一个build之间有什么改动,然后针对这些改动,我们就可以实施Code Review了。
便于开发流程的管理 。比如说,要把一个开发的build提交给测试组作测试,测完满意了,再提交到发布组去发布。
还有很多很多的其它的好处,也许你可以告诉我吧。
怎么做持续集成
持续集成有很多很多的好处。可是持续集成要做好的话,本身就有很多的讲究。从持续集成工具的选择到持续集成具体实施,每一点都可能影响到你使用持续集成的效果。持续集成不是持续编译,也不是仅仅用来发发邮件的工具而已。
工欲善其事,必先利其器。首先选择一个好的工具很重要,在我另一篇帖子《持续集成工具的选择》中,我已提到过了,这里不再多说。用下来,我觉得QuickBuild真得很不错。
工具选好了,具体怎么做呢?这个没有什么标准可以遵循,每个项目都是不一样的,我谈谈我们这里的具体过程吧。
首先,我们对编码有一些规范需要遵从,所以我们制定了一系列的FindBugs和PMD的规则用于检查代码。
其次,我们使用Cobertura作为我们的代码覆盖(code coverage)工具。
再次,我们使用JUnit作为我们的unit test工具
基于上述几点,我们编写了我们的Ant脚本,这个脚本有一系列的task,基本上就是:
compile, source code analytics, unit test, generate reports, generate javadoc, package artifacts
这个,也是Java领域中经常使用的一个完整的过程。
有 了这样一个脚本以后,我们开始配置我们的项目到QuickBuild中去,在QuickBuild中,我们配置一个configuration,然后设定 我们的SCM repository,对应于我们的ant task,我们配置了一系列的step,用于完成整个过程。由于我们的测试需要跨平台,所以对应与同一个unit test的task,我们使用QuickBuild的分布式的step功能,使之在不同平台上可以进行测试,这一点也是使用CI Server的一个好处吧。
对应于这个configuration,我们配置了四个子configuration,分布是 Development Configuration, QA Configuration,Integration Configuration和Release Configuration。这几个configuration分别对应于我们开发过程的四个阶段,我们的每日构建都是在Development configuration上的,所以我们配置为每日一次,而对于其它三个则不做自动的构建。因为我们是通过Promote来做的。对于 Development Configuration,我们没有对SCM自动打Label,而对于其它的,我们则对每一个Build自动对SCM进行打Label。
有 了这些以后,开发工作开始了,我们每天的代码在下班前都提交到subversion里去,第二天,Development Configuration就自动的编译完成了,并且发送通知给我们。我们通常会会开一个Morning Meeting,首先我们会到在QuickBuild的页面上,看到昨天有哪些个改动,测试的状况,比如说哪些测试修正了,哪些测试还没有被修正,哪些 source code没有通过代码检查。然后我们会点到具体的报告中去分析,这些报告都可以很容易的打开source code,我们可以直接在上面对各个改动做code review。通常这个工程耗时约30分钟结束。
经过这样开发之后一段时间,我们的功能很多 已经就绪,就可以提交给QA作test了,由于当日的构建可能失败,或者不是我们特别想给QA的,那么我们会选择之前几日的一个好的build做 Promote,这个promote就会自动触发QA Configuration去做build,QA Configuration的build做完以后,就会发送一个邮件通知QA Lead,这封邮件里QuickBuild会把所有与上一个QA build的changes都列出来,这样他就知道我们这个版本里增加了什么功能,修正了什么bug。
再如此经过几个迭代后,我们开发组和QA组 一致认为功能基本实现了,bug也不多了,于是就由QA的Lead做一个Promote,触发Integration Configuration不build一个大版本交给客户,做VOC (Voice of Customer),听却客户的意见,如果客户没有什么易见的话,那么就会在Integration Configuration上做一个Promote到Release Configuration上去。
通过这样做,我们基本上可以很容 易的知道每一个版本之间有什么变化,甚至我们可以很容易的重新build出任何一个时间点上的版本。而且,我们基本上无需操心什么时候给SCM打什么样的 Label,因为对于我们而言,我们需要看到的只是每一个版本的build。而如果用subversion来管理的话,也许你也可以通过命令来列出在 SCM中各个版本的变化,但是如果有一天,你头昏忘记打label的话,或者打错label的话,也许要找到这个问题就不是那么容易了。又也许,你可以通 过一系列的命令来完成这里提到的所有功能,但是我是懒惰的,而且很容易做错事情,所以我觉得如果机器可以完成的话,就让机器去做吧。
这些都只是我们在持续集成上的一点实践,也许你有更好的方式,也许你有更多别的点子,那么也请告诉我吧。
还有很多很多关于持续集成的事情可以说,多到可以写一本书了,如果你有兴趣的话,我觉得那本《Continuous Integration: Improving Software Quality and Reducing Risk》的书可以好好看看,非常详细。
发表评论
-
持续集成
2010-09-07 10:47 785持续集成 原文链接:http://martinfowler ... -
持续集成实践
2010-08-18 17:22 1224CC的项目配置: Xml代码 1. < ... -
通过持续集成尽早发现缺陷
2010-08-18 16:17 1101通过持续集成尽早发现缺陷 http://www.xp163. ... -
cruisecontrol、ant、svn持续集成
2010-08-18 16:14 1862自己两个多星期以来对持续集成的概念和应用有了一些了解。下面主要 ... -
持续集成 java手册
2010-08-18 10:24 1078持续集成 java手册 一、概念 martin fowle ... -
浅谈CruiseControl的部署
2010-08-18 09:45 2285浅谈CruiseControl的部署 ... -
持续集成
2010-08-17 09:53 867谈到持续集成,不如先 ... -
不进行持续集成的理由
2010-08-17 08:43 888不进行持续集成的理由 ... -
如何进行持续集成?
2010-08-17 08:41 889如何进行持续集成? 在进行持续集成实践前,应当正确的 ... -
持续集成(第二版)
2010-08-17 08:33 1060持续集成(第二版) ... -
持续集成:什么应该自动化?
2010-08-17 08:24 868持续集成:什么应该自动化? 一、什么是持续集成(Contin ... -
持续集成和Scrum相关
2010-08-16 18:56 864持续集成和Scrum相关 -
持续集成和Scrum相关
2010-08-16 17:53 727持续集成和Scrum相关 -
持续集成总结
2010-08-16 17:43 1592一、什么是持续集成( ...
相关推荐
持续集成持续集成持续集成持续集成持续集成持续集成持续集成
持续集成例子,仅供大学参考........
持续集成持续集成持续集成持续集成持续集成持续集成
对持续集成中数据库集成的经典的xml配置文件
持续集成php hudson 做增量发布 Selenium_IDE
智能运维:浅谈持续集成( CI)、持续交付(CD) 和软件测试.pdf智能运维:浅谈持续集成( CI)、持续交付(CD) 和软件测试.pdf智能运维:浅谈持续集成( CI)、持续交付(CD) 和软件测试.pdf智能运维:浅谈持续集成( CI)、...
企业IT持续集成与持续交付实践.pdf
持续集成工具 cruisecontrol 配置文件
CI持续集成CI持续集成 很难学哦
持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试持续集成与自动化测试
持续集成从“配置管理”、“构建”、“测试”、“部署及发布”及“团队习惯”5个纬度考察其成熟度,每个维度都有5个级别,分别是“入门”、“新手”、“中等”、“进阶”和“疯狂”。目前在各个维度上,行业的平均...
“持续集成”起源于极限编程开发.是它的12个基本原则之一,”持续集成”是一种软件开发实践.它要求开发小组的每个成员频繁的集成他们的工作成果.这个频度通常是至少每天一次有时甚至每天多次开发团队的成员频繁的...
使用 Hudson 持续集成 ppt
持续集成文档,介绍了利用Maven等工具搭建持续集成测试环境。
Jenkins持续集成从入门到精通.pdf
阿里云,阿里云持续集成,介绍了阿里云持续集成相关的经验
初创公司如何做好持续集成和部署,对不同服务的管理。
主题:持续集成及CruiseControl技术交流 在提升软件质量、降低研发风险、拒绝浪费方面,处于敏捷实践领域的持续集成(Continuous Integration,CI)起到重要作用。持续集成能够解决研发工作中的80%任务(日常),...
该ppt详细介绍了持续集成工具jenkins的介绍以及安装步骤
持续集成、交付和部署:对方法、工具、挑战和实践的系统回顾.pdf