持续集成编译增量代码
㈠ 持续集成的工具都有哪些
目前市场上主流的持续集成工具很多
例如 CruiseControL，hudson ，jenkins，还有apache的Continuum 等 开源的持续集成工具,
CruiseControl ：简称 CC ，持续集成工具，主要提供了基于版本管理工具 ( 如 CVS、VSS、SVN) 感知变化或每天定时的持续集成，并提供持续集成报告、 Email 、 Jabber 等等方式通知相关负责人，其要求是需要进行日构建的项目已编写好全自动的项目编译脚本 ( 可基于 Maven 或 Ant) 。由于该工具配置以及部署很麻烦 且版本很久没有更新
hudson 但是由于被oracle收购 很多以前开源的东西 以后很可能被ORACLE私有化
Hudson是Jenkins的前身，是基于Java开发的一种持续集成工具，用于监控程序重复的工作，包括：
1、持续的软件版本发布/测试项目。
2、监控外部调用执行的工作。
㈡ 浅谈持续集成在软件项目管理中的作用
浅谈持续集成在软件项目管理中的作用
【摘要】：持续集成是极限编程12个基本原则之一，正在被越来越多的团队所采用。软件项目管理涉及到九大知识领域，贯穿于软件过程的始终，目的是为了让软件项目的整个软件生命周期(从分析、设计、编码到测试、维护全过程)都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。持续集成这种软件开发实践，对于软件项目管理的各个领域的管理有着积极的作用。
【关键词】：持续集成软件项目管理统一的代码库构建
一、引言
软件项目经理不但要用管理知识管理整个项目.还要为他们的团队选择更好的技术实践在软件开发的众多技术实践中持续集成已经被越来越多的团队所采用持续集成对于软件项目管理的各个领域的管理有着积极的作用，持续集成的使用会给开发尉队的管理带来很多的好处.做为管理者的项目经理以及团队成员都可以从中受益。
二、持续集成与软件项目管理
1、什么是持续集成
“持续集成”起源于极限编程开发.是它的12个基本原则之一”持续集成”是一种软件开发实践.它要求开发小组的每个成员频繁的集成他们的工作成果.这个频度通常是至少每天一次有时甚至每天多次开发团队的成员频繁的整合他们之问的工作.这种整合不是简单的组装软件每次的集成通过一个包含测试的构建去尽快的探测潜在的错误.保证软件现有的功能不被破坏，自动分析现有代码的状态f有无重复逻辑.代码的复杂度等)并发布相关的报告。通过快速反馈，开发人员可以了解软件集成的情况.对不成功的集成进行快速的修改.从而提高软件开发的效率和质量
2、什么是软件项目管理
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员(People)、产品(ProdU(2t)、过程(Protess)和项目fProject)进行分析和管理的活动。
为使软件项目开发获得成功.关键问题是必须对软件项目的工作范围、可能风险、需要资源(人、硬件/软件)、要实现的.任务、经历的里程碑、花费工作量(成本)、进度安排等做到心中有数.掌握整个软件的开发进程。
三、持续集成对软件项目管理的作用
l、对项目目标管理的作用
软件项目的目标是开发出可运行的、客户满意的软件系统持续集成有统一的代码库。要求开发人员定期地、不断地向代码库提交代码。新近提交的代码会经过编译与测试.与代码库中旧有的代码相整合，形成安全稳定运行的代码库.既软件系统。这样。能够在最快、最短的时问内形成结果代码.逐步实现项目目标。这样的代码提交形式对软件项目的目标管理有利.项目经理能够最快速度地得到项目的最新代码库.并且新提交代码的问题也会及早地暴露出来，在最短的时间内得到解决。持续集成已经被证明对于小到中型规模的项目目标的实现是有价值的，对于大的项目，仍然是有用的。
2、对项目时间管理的作用
生产力的发展过程是不断采用物化劳动取代人自身的劳动的过程，是不断自动化的过程。开发的构建过程中如果大量的采取手动过程不仅降低了团队的生产率.更严重的是它将许多不确定的因素引入到产品的构建过程.这使得发现以及解决问题变得异常困难。这样会更加地降低了团队的开发效率。持续集成的构建都是使用构建工具自动化地进行的通过使用持续集成工具将构建过程自动化.便于分析并找出问题。大大提高了团队的开发效率。
稳定而高效的开发效率保证了开发团队在一个轻松愉快的环境中工作.同时团队成员可以有更多的时问和精力学习新技术并将其应用在软件开发中.自动化测试.集成将开发人员从简单、繁琐的低级脑力劳动中解放出来，从而进行更高层次的思考持续集成的自动构建过程，极大的提高了软件的开发效率，对项目经理的项目时间管理有利。
3、对项目质量管理的作用
持续集成过程要求编程人员事先编写好很多的测试用例.在代码的提交过程中就对代码进行测试.这样的及早测试能够最快速地发现软件代码中的错误和缺陷.及时修改，从而提高软件的质量。
持续集成的测试包括：单元测试、功能测试、集成测试，进行部署等等持续集成要求有一个全面的单元测试验证集.使持续集成能够获得短集成周期。在一般的项目中，编写测试代码都至少会额外增加30%的工作量初看.在时间和资金上这也许是很大的开销，然而，在持续集成过程中，编写测试代码是必要的，而且这样也省去了人工测试的时间.确保了软件产品的质量.对软件项目的质量管理有利。
4、对项目风险管理的作用
持续集成过程通常在开发人员提交代码后开始.服务器自动更新代码.编译，运行单元测试、功能测试、集成测试，进行部署这个持续集成的过程可以帮助开发人员快速发现并解决问题(编译失败，测试失败等)。与开发人员的机器相比，持续集成服务器运行在相对稳定、干净的环境中f减小跟踪调试的难度)，持续集成过程的失败通常意味着最近一次更新破坏了软件现有功能或引入了新的缺陷。在持续集成过程结束后.除了构建结果(War，Jar等)，通常会生成代码分析报告(测试覆盖率等)，帮助项目管理人员更好的了解并改善项目。
这种快速反馈集成结果.并进行快速修改的工作方式.在第一时间消除了代码中的Bug.极大地减小了系统发生错误、不能在用户环境中运行、系统集成时涌现大量问题的风险。这样使整个的项目进度完全掌握在项目经理手中.减少了项目的风险.有利于项目经理的风险管理。
5、对项目人力资源管理的作用
软件开发过程最终表现为人与人之间各种形式的合作。安全感与信心是合作最基础也是最重要的部分通过使用持续集成工具.开发人员可以了解到新的代码是否引人了缺陷。管理人员可以通过使用各种形式的报告对项目进行评估。不断发布的构建结果.使测试人员得以自始至终的参与到整个开发过程中。而不是在软件开发的最后阶段才加入团队
持续集成所做的一切加强了团队成员的沟通.项目中的所有人都知道系统现在的状态.目前已经做了那些变动。沟通中最重要的一件事是主线的构建状态。使用持续集成服务器。这上面有个构建.它会告诉你构建的状态和上次主线构建的状态。将构建的结果反馈的形式很多.比如构建成功则绿灯亮.失败就出现红灯。还可以使用网站发布构建结果.这样那些不在一起工作的人也能看到目前项目的状态这样的工作方式使团队成员及时了解项目情况。得到及时、准确的沟通，可以增强团队成员的安全感和信心，使团队在一个好的氛围中工作。这样利于项目经理管理项目团队中的成员。
㈢ 如何理解持续集成、持续交付、持续部署
我们经常听到持续集成，持续交付，持续部署，它们是什么，联系和区别是什么?让我告诉你我的想法。
是什么
集成指软件作为软件的一部分的部分交付，以尽早发现个体开发部分的问题;
部署是能够尽早交付到运行的开发/测试部分的代码，以便尽早进行测试;
交付是指研究和开发尽快交付给客户，以便尽早发现生产环境中的问题。
我个人认为持续的集成，持续的交付，持续的部署是值得传播的。在开发过程中，对集成的最大恐惧导致返工，而持续集成、持续交付和持续部署可以及早发现并及早解决，从而避免了这个问题。
㈣ 为什么要持续集成
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需要项目内部互相合作，划 分模块这种传统的模式的弊端也越来越明显，由于很多 bug 在项目的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻找 bug 的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的情况，在这个阶段的除虫会议（bug meetings）特别多，会议的内容基本上都是讨论 bug 是怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。
持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。持续集成主张项目的开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库，并验证这些改变是否对项目带来了破坏，持续集成包括以下几大要点：
访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统）， 让所有人都能从这里获取最新的源代码（以及以前的版本）。
支持自动化创建脚本，使 创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。
测试完全自动化，要求开发人员提供自测试的代码，让 任何人都可以只输入一条命令就运行一套完整的系统测试。
提供主创建，让任何人都可以只输入一条命令就可以开始主创建。
提倡开发人员频繁的提交（check in）修改过的代码。
持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程都应该自动完成。对于一次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的一步是测试，只有最后通过测试的创建才是成功的创建。
在持续集成里面创建不再只是传统的编译和连接那么简单，创建还应该包括自测试，自测试的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试（源自 XP 的实践），将所有的这些自测试代码整合到一起形成测试集，在 所有的最新的源码通过编译和连接之后还必须通过这个测试集的测试才算是成功的创建。这 种测试的主要目的是为了验证创建的正确性，M cConnell 称之为冒烟测试，在 持续集成里面，这 叫做集成验收测试Build Verify Test，简称 BVT。BVT 测试是质量的基础，QA 小组不会感受到 BVT 的存在，他们只针对成功的
创建进行测试（如功能测试）。
BVT 测试应该尽量的详尽，详尽的测试才能发现更多的问题，而由此得到的反馈结果也更有参考意义，测试应该全部执行完毕，这样得到的反馈结果才是完整的，而不是遇到错误就放弃测试过程。
持续集成和日创建相比还有以下特点：
持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前推荐的最佳实践是每一个小时就集成一次。
持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续集成强调的是集成失败之后向开发人员提供快速的反馈，当 然成功创建的结果也是得到稳定的版本。
日创建并没有强调开发人员提交（check in）源码的频率，而持续集成鼓励并支持开发人员尽快的提交对源码的修改并得到尽快的反馈。
从上面列出的续集成和日创建相比的特点来看，很明显， 频率和反馈这两个词出现的特别多，持 续集成有一个与直觉相悖的基本要点，那 就是 经常性的集成比偶尔集成要好。Martin Fowler 认为对于持续集成来说，集成越频繁，效果越好 ，如果你的集成不是经常进行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶尔才进行一次（一周甚至一个月）， 等到集成阶段发现bug，然后找原因解决bug，会耗费你大量的时间与精力，而且这种方式有点象传统的集成模式，这违背了持续集成的初衷。
根据Martin Fowler 的观点，项目 bug 的增加和时间并不是线性增长的关系，而是和时间的平方成正比，两次集成间隔的时间越长，bug 增加的数量越超过你的预期，解决 bug 付出的工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一次性解决问题，结果 bug 产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的痛苦，就越将集成的时间推后，最后形成恶性循环。
因此如果集成的结果是让你感到痛苦，也许就说明你应该更频繁地进行集成。频繁的集成和及时的反馈鞭策着项目小组积极的面对问题，而 不是将问题推到最后来解决，如 果方法正确，更频繁的集成应该能减少你的痛苦，让你节约大量时间。
因为持续集成最终是通过测试来验证创建，所以你会发现对于持续集成的频率的要求跟Kent Beck 提出的测试驱动的开发方法里面测试第一的理念完全一致。需要注意的是从项目的一开始就引入持续集成可以尽早的发现 bug，但是并不代表持续集成可以帮你你抓到所有的 bug。持续集成的排错能力取决于测试技术，众所周知，无法证明已经经过测试的代码就已经找到了所有的错误。