模板
教程
环境
性能
功能
管理
持续集成实践成熟度模型(2)
有人工参与的提测过程。
自动化功能测试具备一定数量并起到了一定保障作用。
自动化功能测试全集频繁运行，不少于一天一次。
中等：
最小工作单元包含自动化测试工作。
不同层级的自动化测试发挥质量保障作用。
静态代码检查及相关举措
可以在构建中推荐提测版本
自动化提测
进阶：
普遍的单元测试，发挥良好效果。
自动化测试覆盖率较高，测试工作被有效分散在开发阶段。
手工测试大部分属于探索性测试。
疯狂：
100%单元测试覆盖率。
自动化测试提供信心十足的质量保证，构建成功后即自动部署。
通过下面问题进一步了解团队的构建现状：
有那些级别的测试，现状如何?
提测流程是怎么样的?需要多长时间?有多少人工参与?
集中的测试阶段占整个项目周期的比例?
QA和RD的合作流程是怎么样的?
有那些自动化测试，数量和质量分别如何?
自动化测试一般是什么时候写的，谁维护，怎么管理和运行的?
什么时间，如何做回归测试?
应用了那些静态代码检查，怎么用的?
单元测试的覆盖率如何?
什么时机，做那些人工测试?
如何选择对哪个构建做测试?
5 部署及发布维度
入门：
有辅助脚本支持的手工部署
依据文档的人工上线流程
新手：
完整的部署脚本支持
向测试环境的标准化部署
通过平台的半自动上线流程
中等：
选择指定的构建产出进行自动部署
可以推荐某个构建为上线候选版本
进阶：
向生产环境中一键发布，一键回滚。
向生产线部署后的自动化验证。
疯狂：
一键恢复生产环境
通过下面问题进一步了解团队的部署及发布现状：
上线流程是什么样的?
是否需要通过work文档，邮件或是一个在线系统传递上线步骤或参数?
如何监测部署的质量?
如何做回滚操作?
如何向开发环境部署?有那些步骤?需要多少人工参与?
如何向测试环境部署?有那些步骤?需要多少人工参与?
有那些用于部署的脚本?
团队成员各自的部署环境有什么区别?
如何选择合适的构建做部署?
6 团队习惯维度
入门：
至少有一个人随时知晓构建状态
阶段性代码提交习惯
专人维护持续集成平台和脚本
新手：
专人看护平台构建状态
最小工作单元完成后即时合并到目标分支
所有人知晓当前的构建状态
构建失败后被及时修复或回滚，失败期间没人提交与修复构建无关的代码。
签入前做本地自动化验证
团队成员签入代码前做相同的本地验证
失败构建不过夜
中等：
失败构建修复时间少于半个小时。
由提交人负责修复失败构建，每个人都关注构建状态。
团队成员都写较为全面的单元测试
每人每天向目标分支做至少一次对最小工作单元的有效提交。
团队清楚持续集成平台和脚本内容，每个人都可以维护。
进阶：
交付团队全员对持续集成平台的稳定构建负责。
交付团队全员负责持续集成脚本开发。
疯狂：
1小时左右向目标分支做一次对最小工作单元的有效提交，且很少发现构建失败。
通过下面问题进一步了解团队的部署及发布现状：
RD如何定义自己工作完成的含义?
团队签入代码的规范是什么?
是否在签入代码前运行本地构建?
如何确保失败的平台构建有人处理?是签入代码的人处理吗?
构建失败的频率是多少?
团队中谁维护自动化构建脚本?
团队中谁维护CI平台?CI平台有那些权限控制?
团队如何提高每个人的单元测试水平?
