模板
教程
环境
性能
功能
管理
持续集成理论和实践的新进展(4)
配置管理：
| 级别 | 描述 |
| 3+：企业级的 | 企业有统一的配置管理策略。 |
| 3：跨项目的 | 配置管理在多个项目之间协调。 |
| 2：自动的 | 配置管理策略与持续集成策略紧密结合，团队成员有频繁提交的意识。一般采用乐观锁策略，原子提交。 |
| 1：集成的 | 版本管理下的内容是受控的。通常在版本管理中的代码是可以编译的。开发人员能够访问到自己工作所需要的代码。开发人员按照一定的规则访问配置管理工具和提交代码。一般采用悲观锁策略。版本管理工具和构建过程集成在一起的。 |
| 0：基本的 | 有基本的版本管理。但版本管理下的内容不全面，或者不足以支撑团队的开发。 |
| -1：无配置管理 | 没有配置管理。或者使用方式完全错误。 |
常用实践和工具
持续集成看板7
问题：
我们需要让整个团队能够方便快捷的了解持续集成的状态。
上下文：
在完成了基本的构建基础设施的搭建之后，我们需要让团队成员及时获得持续集成的状态信息。传统的邮件方式可能会使人厌烦，或者错过重要的构建信息。
解决方案和实现：
安装一个显示器，将构建的状态信息以简明的方式展示在显示器上。将显示器放置在团队所有成员都能够很容易看到的地方。
个人构建中心
问题：
在某些情况下，构建环境的成本很高，而我们需要每一个开发人员提交之前完成一次个人构建。
上下文：
有些测试是依赖于设备的，而这些设备非常昂贵，并且配置复杂，所以无法给每个开发/测试人员一套构建环境。我们发现根据本地构建的理论模型，每个人的提交应该是串行的，这样我们实际上可以做到让这些人共享一套环境，但是从逻辑上就像是每个人有一套自己的环境一样。
解决方案：
在运行个人构建的时候将本地的代码同步到一台共享的机器上执行构建，构建完成后结果反馈给提交这次个人构建的人。
实现：
个人构建中心的实现有很多种方案。这些方案的区别主要在于如何将代码同步到个人构建中心服务器上。两种常见的方式：一个是使用rsync或者类似方式同步;另一个是使用分布式配置管理工具如git/hg同步。其拓扑结构如下：
第一种方式相对独立灵活;第二种方式稳定、高效，但是对于配置管理工具有依赖。
后果：
个人构建中心节省了大量的计算资源，同时也容易使得中心服务器成为单点失败的源头。一旦中心服务器出现问题，可能会导致团队的流程受到较大影响。
提交令牌
问题：
在实施本地构建的时候，向目标分支的提交应该是串行的，以避免构建被破坏后难以定位问题来源。但是团队往往缺乏一种有效的机制来保证这种串行。
上下文：
有些团队试图通过技术的手段来解决这个问题，比如通过配置管理上的锁机制，这种方式和乐观锁模式有较大冲突。有些团队通过团队内部沟通的方式解决，比如谁提交之前都会通知别人，或者通过持续集成监视器来了解当前的构建状态，以决定自己是否可以提交。这些方式各自有各自的适用情形，较容易理解。
解决方案和实现：
使用一个实物作为令牌，准备提交的代码的人首先取得令牌，当代码提交完成(包括相应的提交构建)之后，将令牌交还。令牌要醒目，并且移动方便。小型奖杯、毛绒玩具、较大的头饰(如下图)都是不错的令牌。
问题：
在某些团队中完整构建所花费的时间可能很长，如果每次提交都运行完整的构建会浪费很多时间。
上下文：
随着持续集成的日益完善，我们往往会发现验证所花费的时间越来越长，而大部分验证趋于稳定，失败的情况很少见。通过技术手段缩短构建时间是解决问题的根本办法，但是缩短构建时间是一个耗时耗力的工作，很难短期内见效。
解决方案和实现：
将构建分为几个阶段执行，在本地构建中仅执行速度比较快、可信度比较高、出错概率比较大的验证。利用晚上或者其他合适的时间执行全面的验证——我们这次构建称为全量构建。需要注意的是，这种情况下仍然要保证提交构建和本地构建的一致性。
iAnalysis是一款轻量级的持续集成报告工具。该工具的核心思想是将持续集成构建过程中产生的数据以趋势和对比的方式展示出来。正如前文所说，我们在2009年的ThoughtWorks Away-Day上讨论了敏捷度量的话题，大家最后一致认为，数据有两种最基本的用法——横向对比和纵向对比。横向对比就是不同的人、不同的团队之间对比;纵向对比就是现在和过去对比。iAnalysis正是这种思想的体现。
原文转自：http://kb.cnblogs.com/page/109735/
