模板
教程
环境
性能
功能
管理
持续集成实践成熟度模型
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 测试维度
在其它纬度中也有一些与测试相关的条目，可参考。
入门：
有部分自动化功能测试
在项目后期集中测试
仅有少量的单元测试，尚未发挥明显作用。
新手：
最小工作单元包含手工测试。
积累一定量的单元测试，团队已从中受益。
构建时运行自动回归测试。
