持续集成实践成熟度模型

1 概述
持续集成从“配置管理”、“构建”、“测试”、“部署及发布”及“团队习惯”5个纬度考察其成熟度，每个维度都有5个级别，分别是“入门”、“新手”、“中等”、“进阶”和“疯狂”。目前在各个维度上，行业的平均水平集中在“入门”和“新手”两个级别。
评估时各级别之间不能越级，就是说即使“新手”中个别条目已经做到了，但如果“入门”中有条目没有做到，也只能评为“入门”级。
该模型的主要目的是为了更好地帮助团队认识现状，同时了解改进的方向。该模型是对持续集成主要维度的简单衡量，背后可能有一些并不适合团队的假设，且并未对每个条目做细致解释，为获得团队持续集成工作的有针对性的全面评估，请联系PMO部门。
由于技术和项目的差异性，不同团队达到同一级别需要付出的努力可能差异很大，获得的收益也有区别，因此不适宜利用此模型在团队间进行比较。
2 配置管理维度
入门：
 使用版本管理工具
 使用私有分支
 功能测试Case在本地管理
 生产代码被版本管理
 每天提交代码，并写Comment。
新手：a
 应用在最小工作单元完成后即可集成的分支策略
 所有构建、测试及部署脚本都被版本管理
 所有测试代码和数据被集中管理
 测试环境中的应用配置被版本管理
 代码签入的Comment清楚达意，含有必要的Metadata，比如Bug号等。
 RD使用完全标准的开发环境，没有仅供自己使用的脚本、数据或测试环境等。
中等：
 测试代码与生产代码同源
 生产环境中的应用配置被版本管理
 持续集成平台运行的脚本被版本管理，无需登录平台修改脚本。
 每次构建均有版本追溯，无需重新从源码构建历史版本。
 Qa使用标准的开发测试环境
 数据库被版本管理
 功能测试数据被版本管理
进阶：
 没有仅在团队成员本地保存的任何项目资产。
 RD和QA使用一致的开发测试环境。
疯狂：
 开发、测试、生产环境被版本管理，可以一键克隆。
 所有测试数据被版本管理

通过下面问题进一步了解团队的配置管理现状：
 使用何种分支管理策略？
 团队成员签入代码的频率和内容，Comment的质量如何？
 一个RD在全新的机器上建立完整的工作环境要经历那些步骤？
 一个QA在全新的机器上建立完整的工作环境要经历那些步骤？
 RD和QA的工作环境有什么区别？
 RD之间的工作环境有什么区别？
 Qa之间的工作环境有什么区别？
 测试数据是怎么管理的？
 RD是否在沙盒中开发？如果不是，有那些依赖？
 本地和平台构建脚本是如何管理的？
 测试环境和生产环境的应用配置是如何管理的？
 测试工具和测试Case是如何管理的？
 测试运行的环境依赖有那些？是否每个人在自己的工作环境中都可以方便运行？
 所有团队成员是否使用相同的脚本做本地构建？
 团队成员有那些私有的代码，脚本和预先部署的环境？
3 构建维度
入门：
 有帮助脚本分别执行各构建步骤
 阶段构建，例如Nightly Build或Weekly Build。
 Shell脚本作为自动化构建开发脚本
新手：
 代码签入后即运行包含自动化测试的构建过程
 构建结果被有效通知团队
 所有人都知道如何运行本地构建
 基础构建过程不再有突出的环境问题
 通过自动化构建脚本完成自动化构建任务。
 专人维护构建环境。
中等
 在本地和平台中运行自动化冒烟测试
 在平台中运行功能测试全集和性能测试。
 充分利用多台机器运行多个构建。
 构建过程集成了详细的报告。
 能够灵活配置各构建阶段的具体任务。
 通过脚本同步及升级各个构建机器中的环境依赖
进阶
 构建步骤被充分优化
 构建过程可以对报告做分析，并记录关键指标的趋势，并进行改进。
 充分利用多台机器做单个构建任务。
 在全新的开发环境中签出项目，通过一个脚本即可构建完整的开发和测试环境并成功产出部署包。
疯狂
 运行时间超过限制即失败。

通过下面问题进一步了解团队的构建现状：
 如何管理编译依赖？
 如何管理模块版本依赖？
 编译的时间是多长？
 每个人的构建环境和方法是否一致？
 自动化构建的具体步骤？
 自动化构建失败的主要原因是什么？
 是否使用了Build Grid？如何用的？
 如何管理Grid中的各台机器？如何同步和更新环境？
 本地构建的内容？什么时候运行？要多长时间？
 使用那个CI平台？如何配置的？
 如何调整构建中包含的内容？
4 测试维度
在其它纬度中也有一些与测试相关的条目，可参考。
入门：
 有部分自动化功能测试
 在项目后期集中测试
 利用缺陷跟踪系统管理缺陷
 仅有少量的单元测试，尚未发挥明显作用。
新手：
 最小工作单元包含手工测试。
 积累一定量的单元测试，团队已从中受益。
 构建时运行自动回归测试。
 有人工参与的提测过程。
 自动化功能测试具备一定数量并起到了一定保障作用。
 自动化功能测试全集频繁运行，不少于一天一次。
中等：
 最小工作单元包含自动化测试工作。
 不同层级的自动化测试发挥质量保障作用。
 静态代码检查及相关举措
 可以在构建中推荐提测版本
 自动化提测
进阶：
 普遍的单元测试，发挥良好效果。
 自动化测试覆盖率较高，测试工作被有效分散在开发阶段。
 手工测试大部分属于探索性测试。
疯狂：
 100%单元测试覆盖率。
 自动化测试提供信心十足的质量保证，构建成功后即自动部署。

通过下面问题进一步了解团队的构建现状：
 有那些级别的测试，现状如何？
 提测流程是怎么样的？需要多长时间？有多少人工参与？
 集中的测试阶段占整个项目周期的比例？
 QA和RD的合作流程是怎么样的？
 有那些自动化测试，数量和质量分别如何？
 自动化测试一般是什么时候写的，谁维护，怎么管理和运行的？
 什么时间，如何做回归测试？
 自动化验收测试、性能测试以及安全性测试现状？
 应用了那些静态代码检查，怎么用的？
 单元测试的覆盖率如何？
 什么时机，做那些人工测试？
 如何选择对哪个构建做测试？
5 部署及发布维度
入门：
 有辅助脚本支持的手工部署
 依据文档的人工上线流程
新手：
 完整的部署脚本支持
 向测试环境的标准化部署
 通过平台的半自动上线流程
中等：
 选择指定的构建产出进行自动部署
 可以推荐某个构建为上线候选版本
进阶：
 向生产环境中一键发布，一键回滚。
 向生产线部署后的自动化验证。
疯狂：
 一键恢复生产环境

通过下面问题进一步了解团队的部署及发布现状：
 上线流程是什么样的？
 是否需要通过work文档，邮件或是一个在线系统传递上线步骤或参数？
 如何监测部署的质量？
 如何做回滚操作？
 如何向开发环境部署？有那些步骤？需要多少人工参与？
 如何向测试环境部署？有那些步骤？需要多少人工参与？
 有那些用于部署的脚本？
 团队成员各自的部署环境有什么区别？
 如何选择合适的构建做部署？
6 团队习惯维度
入门：
 至少有一个人随时知晓构建状态
 阶段性代码提交习惯
 专人维护持续集成平台和脚本
新手：
 专人看护平台构建状态
 最小工作单元完成后即时合并到目标分支
 所有人知晓当前的构建状态
 构建失败后被及时修复或回滚，失败期间没人提交与修复构建无关的代码。
 签入前做本地自动化验证
 团队成员签入代码前做相同的本地验证
 失败构建不过夜
中等：
 失败构建修复时间少于半个小时。
 由提交人负责修复失败构建，每个人都关注构建状态。
 团队成员都写较为全面的单元测试
 每人每天向目标分支做至少一次对最小工作单元的有效提交。
 团队清楚持续集成平台和脚本内容，每个人都可以维护。
进阶：
 交付团队全员对持续集成平台的稳定构建负责。
 交付团队全员负责持续集成脚本开发。
疯狂：
 1小时左右向目标分支做一次对最小工作单元的有效提交，且很少发现构建失败。

通过下面问题进一步了解团队的部署及发布现状：
 RD如何定义自己工作完成的含义？
 团队签入代码的规范是什么？
 是否在签入代码前运行本地构建？
 如何确保失败的平台构建有人处理？是签入代码的人处理吗？
 构建失败的频率是多少？
 团队中谁维护自动化构建脚本？
 团队中谁维护CI平台？CI平台有那些权限控制？
 团队如何提高每个人的单元测试水平？

(原文：http://hi.baidu.com/baiduqa/blog/item/73173aed4e2ab8f6cf1b3e6a.html 作者：wenjian)