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

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

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

　　组织结构

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

　　流程

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

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

　　环境

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

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

　　分层

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

　　测试分级

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

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

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

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

　　构建：

　　级别

　　描述

　　3+：对外防御的

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

　　3：对内防御的

　　构建是自动的。由测试和检查来保证团队内部的开发质量。持续集成的修复具有最高的优先级。团队对持续集成的结果有信心。

　　2：频繁的

　　构建是自动的，而且构建的速度较快。构建的触发条件是明确的，通常每次代码提交都会触发构建。团队中的每个人都会触发构建，并且了解构建的状态。

　　1：重复执行

　　构建是自动的，但是执行的不够频繁。构建的触发是随机的或者频率是非常低的(低于每天一次)。构建的速度通常非常慢，比如一次构建超过半个小时。

　　0：可重复的

　　主要依赖于手动的方式构建软件，但是每次构建的方式都是相同的或者相似的。通常有相关的文档的指导。经常团队指定某个人负责构建软件，虽然大部分人都能够做这件事情。

　　-1：手动的

　　主要依赖于手动的方式集成软件。每次集成的方式可能不一样。经常团队中只有个别人能够将软件集成起来。

　　测试：

　　级别

　　描述

　　3+：全面集成的

　　全团队对测试负责。测试驱动整个开发过程。测试与构建完全集成。

　　3：测试驱动的

　　业务分析人员和开发人员均参与测试。测试在构建过程中自动执行。开发人员实践测试驱动开发。

　　2：集成的

　　开发人员参与测试。部分测试集成在构建过程中执行。大部分测试在软件开发过程中执行。

　　1：共享的

　　开发人员参与测试。测试并未集成在构建过程中。部分测试在软件开发过程中执行，大部分测试在软件开发结束后执行。

　　0：审查的

　　测试由专门的测试人员负责。有部分测试是在软件开发过程中执行。但大部分测试在软件开发结束后执行。

　　-1：独立的

　　测试由专门的测试人员负责。仅在软件开发结束后执行。

原文转自：http://www.wangyuxiong.com/archives/51243