持续集成理论和实践的新进展(3)

　　广义的持续集成及持续集成策略

　　当要把持续集成实践应用到团队的时候，有很多额外的技术或者非技术因素需要考虑。

　　组织结构

　　持续集成是一个重要的沟通工具，而开发过程中两个最需要紧密沟通的角色就是开发和测试。在我们常见的组织结构中开发和测试往往隶属于不同的部门，甚至这些部门隶属于不同的高级经理。这往往会给持续集成的推广带来很大的阻力。这是因为持续集成从环境搭建到运行维护都需要两种角色的通力合作。我们的经验是这类涉及到人力资源的事情除非某一级“共同的大老板”出面，否则是很难协调的。“借调”这样的方式往往不能保证效果。

　　流程

　　放到团队的角度看待流程应当更加关注于各个成员之间的配合。每个开发人员提交代码之前应当确保是经过本地构建的;开发人员在提交之前应该确认主线上的代码是通过了持续集成的;测试人员测试的版本应该是通过了某次持续集成的，并且有相应的具体版本信息。

　　为了保障流程的顺利执行，我们还经常采用持续集成看板、提交令牌等辅助手段。

　　环境

　　环境是指持续集成运行时所依赖的软件和硬件的集合。我们经常遇到的一个问题是，软件在一台机器上能够通过持续集成的验证，而在另一台机器上则不能通过。这通常是因为我们对持续集成环境的定义不明确造成的。所以在搭建持续集成和在组织内推广持续集成的时候，我们需要特别注意持续集成环境的标准化，明确指出持续集成运行时依赖哪些第三方库，机器配置如何，端口和网络状况如何等等。

　　我们经常采用将持续集成环境加入配置管理的方式来解决环境标准化的问题。

　　分层

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

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

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

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

　　构建：

　　测试：

原文转自：http://kb.cnblogs.com/page/109735/