第一种方式相对独立灵活;第二种方式稳定、高效，但是对于配置管理工具有依赖。

　　后果：

　　个人构建中心节省了大量的计算资源，同时也容易使得中心服务器成为单点失败的源头。一旦中心服务器出现问题，可能会导致团队的流程受到较大影响。

　　提交令牌

　　问题：

　　在实施本地构建的时候，向目标分支的提交应该是串行的，以避免构建被破坏后难以定位问题来源。但是团队往往缺乏一种有效的机制来保证这种串行。

　　上下文：

　　有些团队试图通过技术的手段来解决这个问题，比如通过配置管理上的锁机制，这种方式和乐观锁模式有较大冲突。有些团队通过团队内部沟通的方式解决， 比如谁提 交之前都会通知别人，或者通过持续集成监视器来了解当前的构建状态，以决定自己是否可以提交。这些方式各自有各自的适用情形，较容易理解。

　　解决方案和实现：

　　使用一个实物作为令牌，准备提交的代码的人首先取得令牌，当代码提交完成(包括相应的提交构建)之后，将令牌交还。令牌要醒目，并且移动方便。小型奖杯、毛绒玩具、较大的头饰(如下图)都是不错的令牌。

　　分阶段构建

　　问题：

　　在某些团队中完整构建所花费的时间可能很长，如果每次提交都运行完整的构建会浪费很多时间。

　　上下文：

　　随着持续集成的日益完善，我们往往会发现验证所花费的时间越来越长，而大部分验证趋于稳定，失败的情况很少见。通过技术手段缩短构建时间是解决问题的根本办法，但是缩短构建时间是一个耗时耗力的工作，很难短期内见效。

　　解决方案和实现：

　　将构建分为几个阶段执行，在本地构建中仅执行速度比较快、可信度比较高、出错概率比较大的验证。利用晚上或者其他合适的时间执行全面的验证——我们这次构建称为全量构建。需要注意的是，这种情况下仍然要保证提交构建和本地构建的一致性。