持续集成实践成熟度模型（Good）
laofo -
持续集成实践成熟度模型
转自：http://hi.baidu.com/baiduqa/blog/item/73173aed4e2ab8f6cf1b3e6a.html
1 概述
持续集成从“配置管理”、“构建”、“测试”、“部署及发布”及“团队习惯”5个纬度考察其成熟度，每个维度都有5个级别，分别是“入门”、“新手”、“中等”、“进阶”和“疯狂”。目前在各个维度上，行业的平均水平集中在“入门”和“新手”两个级别。
评估时各级别之间不能越级，就是说即使“新手”中个别条目已经做到了，但如果“入门”中有条目没有做到，也只能评为“入门”级。
该模型的主要目的是为了更好地帮助团队认识现状，同时了解改进的方向。该模型是对持续集成主要维度的简单衡量，背后可能有一些并不适合团队的假设，且并未对每个条目做细致解释，为获得团队持续集成工作的有针对性的全面评估，请联系PMO部门。
由于技术和项目的差异性，不同团队达到同一级别需要付出的努力可能差异很大，获得的收益也有区别，因此不适宜利用此模型在团队间进行比较。
2 配置管理维度
入门：
使用版本管理工具
使用私有分支
功能测试Case在本地管理
生产代码被版本管理
每天提交代码，并写Comment。
新手：
应用在最小工作单元完成后即可集成的分支策略
所有构建、测试及部署脚本都被版本管理
所有测试代码和数据被集中管理
测试环境中的应用配置被版本管理
代码签入的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平台有那些权限控制？
团队如何提高每个人的单元测试水平？