Martin Fowler
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
我觉得可以这样简单理解:及早地将开发人员的代码集成起来,通过各种工具来及时地发现代码中存在的问题,以确保代码质量的稳定性和准确性,让Agile
下面我们按照Martin Fowler
1)Maintain a Single Source Repository
一般来说,工程都是以团队的形式进行开发的。一个工程的文件都是以千百计算的,如果需要手工去跟踪、同步这些文件,那无疑是天方夜谭。于是源代码管理工具应运而生。开源的源代码管理工具有CSV
2)Automate the Build
从拿到源代码到变成一个可运行的系统,这中间要经过一个复杂的过程。一个简单的过程大概有:编译/
3)Make Your Build Self-Testing
在传统的开发模式中,当build
集成很多时候是为了沟通,告诉其他开发人员自己已经做了那些代码的改动。及时的沟通在团队开发中的重要性是不容置疑的。所以我们要尽快地将自己代码的改动提交。但代码提交之前,一定要确保自己代码的正确性,至少让系统可以跑起来。而不是说代码一有改动,就不管三七二十一,把代码弄上去就行了,这样对整个团队来说,cost
5)Every Commit Should Build the Mainline on an Integration Machine
前面说到每天都提交代码,这就会带来一个问题:在提交代码之前,未必有去拿到最新代码,即使拿到最新代码,由于开发环境的不同,也可能没发现什么问题。于是代码上去了,另一位同事去拿最新代码,有可能整个系统都跑不起来。所以,我们还需要一个集成的机器,它负责在每次代码提交之后,去获取最新的代码,然后根据设置去运行相应的测试,看看这次提交的代码有没有什么问题。这样,便可以在下一个同事拿到新代码之前发现问题,并相应的owner
前面我们说了,持续集成就是为了更快、及早地发现问题。所以如果一次集成需要耗费几个小时,甚至一天(听说Microsoft
测试就是为了检查产品的使用情况,所以集成机器的环境搭建最好是跟最终产品的环境一致,比如说:相同的数据库,相同的服务器,相同的操作系统等等。
持续集成就是一种沟通,那我们应该让所有的人实时地、方便地看到持续集成的情况。一种比较简便的办法是安装一个JCCTray(
还有一种就是用一盏灯来显示,红绿黄的意思跟上面一样,具体可以看http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc
当拿到新代码,经过测试,发现没有问题,这时应该进行自动部署。比如自动部署到QA
前面按照Martin Fowler
后面应该会陆续就自己在使用持续集成的一些工具过程中的一些想法记录下来。