分层

　　在大型团队(超过100人)中，扁平的开发组织结构是运行起来是比较困难的。常见的做法是按照特性，将团队划分为10人左右的小团队。一般来说，如 果团队数量超过10个，还会再增加一层架构。这时候，配置管理的策略也应当做出调整。常见的做法是为每个团队拉出一个分支，设置一个集成分支用于将各个特 性分支的内容整合在一起。需要注意的是，这里每个分支都应该具备所有代码的访问权限，也是所有分支是同根的、等价的。

　　测试分级

　　在实施持续集成的时对于测试的类型应该有比较明确的定义。一般来说，我们经常把测试分为三级——单元测试、集成测试和系统测试。这是一个很大的话 题，这里只是说明此处的单元测试并不是指针对函数的测试。虽然单元测试主要是函数基本的测试，但是每个单元测试应该针对的是特性或者对应代码在实现该特性 上所发挥的作用。

　　单元测试的运行速度通常非常快，应该在数秒到数分钟。单元测试应该覆盖绝大部分的特性需求。集成测试单个测试的运行速度通常会比单元测试慢一个数量 级，比如存在文件读写或者其他的IO和网络操作。集成测试主要用于保证系统的各个组件之间的调用是工作的。系统测试的运行速度一般会比集成测试慢，通常需 要将整个系统运行起来，比如Web开发中的selenium测试。系统测试主要用于测试系统的正确路径(Happy Path)可以工作。有的团队会开发很多基于整个系统的回归测试，也属于系统测试。场景的覆盖而言，单元测试>集成测试>系统测试，从运行 时间来看则相反。

　　3) 持续集成的成熟度评估

　　在帮助客户实施和推广持续集成的过程中我们逐渐总结出一些原则，帮助客户评估现状，分析和设计未来的目标。该评估方法借鉴了ThoughtWorks敏捷成熟度模型中有关配置管理、测试、构建等内容，并做了适当的简化。

　　构建：

　　级别

　　描述

　　3+：对外防御的

　　团队能够根据自己的需要，协调其他团队的持续集成，当依赖的其他团队的代码和组件或者第三方库和基础设施发生改变时自动进行构建。团队对于外部依赖的可靠性有信心。