持续集成持续集成的原则

持续集成的工具都有哪些

目前市场上主流的持续集成工具很多 例如 CruiseControL，hudson ，jenkins，还有apache的Continuum 等 开源的持续集成工具, CruiseControl ：简称 CC ，持续集成工具，主要提供了基于版本管理工具 ( 如 CVS、VSS、SVN) 感知变化或每天定时的持续集成，并提供持续集成报告、 Email 、 Jabber 等等方式通知相关负责人，其要求是需要进行日构建的项目已编写好全自动的项目编译脚本 ( 可基于 Maven 或 Ant) 。

由于该工具配置以及部署很麻烦 且版本很久没有更新 hudson 但是由于被oracle收购 很多以前开源的东西 以后很可能被ORACLE私有化 Hudson是Jenkins的前身，是基于Java开发的一种持续集成工具，用于监控程序重复的工作，包括： 1、持续的软件版本发布/测试项目。

2、监控外部调用执行的工作。

持续集成的好处？

1)快速发现错误，每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易 2)防止分支大幅偏离主干，如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成 3)更快速的发布更新，持续集成可以帮助团队更快速、更积极的发布程序和更新程序。

在发布时可自动完成大量重复的工作、节省人力 黑马程序员的软件测试课程里详细的讲解了持续集成的相关技术。

持续集成Hudson/jenkins 能不能根据不同权限组显示不同 job

可以的。

1.先在jenkins --->系统管理--->插件管理里面安装权限策略role-strategy.jpi插件，再注册几个用户。

2.在系统管理--->Configure Global Security里统一用户权限配置，在这里配置的权限针对所有job有作用。

3.也可以在job 配置里面单独授权给用户。

在这里配置的权限针对当前job有作用。

比如这图上可以看到admin和zhangxxx有权限，那么当用wangxxx登录时，这个job就不会显示，视图上就看不到。

如何搭建持续集成分布式测试

如何搭建持续集成分布式测试 是不能从DLL里导出C++类和成员函数，如果你想让MSVC的用户也可以调用它。

好吧，那不完全属实。

你的DLL能导出C++类，但是MSVC不能使用它们。

原因就是C++成员函数名被编译器改编（mangled）。

这个改编的名字结果了DLL。

为了调用在DLL里被改编的函数，你必需知道被改编的是哪个函数。

Borland和Microsoft使用了不同的名字改编方案。

结果是，MSVC不能恰好看到Borland编译的DLL里的C++类和成员函数。

持续集成：什么应该自动化？

通俗一点儿说，就是指对于开发人员的每一次代码提交，都自动地把Repository中所有代码Check out到一个空目录，并且自动运行所有Test Case。

如果成功则接受这次提交，否则告诉所有人，这是一个失败的Revision。

更具体的解释可以参考Martin fowler的Continuous Integration 。

二、持续集成的价值与成本有句时髦的话，叫做“存在即为合理”。

既然持续集成已经存在了这么长的时间，而且没有消失的迹象，那就是有价值的东西。

那么它的价值何在？有人概括如下：(1) 减小风险；(2) 减少手动过程；(3) 生成构建结果；(4) 安全感。

而持续集成的成本在于对持续集成代码的维护成本和集成的时间成本。

因为随着项目进行，软硬件环境会越来越复杂，成品代码也会不断膨胀。

此时，需要团队而修改或增加原有的测试代码，以适应这些变化，同时，每次集成所需时间也会变长，这就是持续集成的成本。

某个blog中提道：“这种集成是如此的频繁，多少次的代码Commit就有多少次持续集成。

前提是集成的成本很低，或者说是完全自动化的。

” 三、持续集成应该自动化什么呢？我们要以尽可能少的成本来获得尽可能多的价值。

这就要考虑哪些自动化是必要的啦。

Jez Humble提到至少有六点要做到自动化，它们分别是(1)自动化的运行测试；(2) 自动产生可部署的二进制成品；(3) 自动将成品自动部署到近似生产环境；(4) 自动为CodeBase打上标签；(5) 自动运行回归测试；(6)自动生成度量报告。

四、持续集成服务器的选择在进行持续集成实践前，应当正确的选择并配置持续集成服务器。

比较成熟的持续集成服务器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。

CruiseControl作为开源产品，以其对于各种SCM以及构建工具的广泛支持而被许多开发团队所接受。

而开发自动化专家 Duvall 采用一致的评估标准和很多说明性示例，介绍了一些开源 CI 服务器，包括 Continuum、CruiseControl 和 Luntbuild。

并指出“要根据 自己的 具体技术和政策需求对工具进行分析”。

并用以下五个指标来评估CI工具，它们分别是：(1) 特性；(2) 可靠性；(3) 寿命；(4) 目标环境；(5) 易用性。

结果如下表： 五、只有持续集成服务器是远远不够的正如Jez Humble所说，CruiseControl和其它的CI工具本质上只不过是一个定时器，时间一到，做你让它做的事情。

所以，必然要有其它工具与其结合，方显持续集成的本色。

这些工具又是什么呢？想测试的话，你就要用一些测试工具，如JUnit，JWebUnit，Selenium等等；想检查代码标准的话，你就要用checkstyle等代码规范检查工具；想要了解测试覆盖率的话，你可能就要用到JCoverage啦。

当然，想得到二进制文件，就要用到Ant，Make之类的工具啦。

六、最重要的事：实践与反思 也许这些东西大家都知道，而且有些人可能已经实践过啦。

无论这些实践的结果是怎样的，一定不要忘记总结和反思。

如果这些实践成功了，不要把它归功于这个工具，而是要总结一下为什么会成功，如果你愿意的话，还可以和大家分享一下。

持续集成的原则

1. 所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。

2. 开发人员每天至少向版本控制库中提交一次代码。

3. 开发人员每天至少需要从版本控制库中更新一次代码到本地机器。

4. 需要有专门的集成服务器来执行集成构建,每天要执行多次构建。

5. 每次构建都要100%通过。

6. 每次构建都可以生成可发布的产品。

7. 修复失败的构建是优先级最高的事情。

8. 测试是未来，未来是测试