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平台有那些权限控制？  团队如何提高每个人的单元测试水平？

(作者：wenjian)