持续集成实践成熟度模型

  1. 云栖社区>
  2. 博客>
  3. 正文

持续集成实践成熟度模型

技术小美 2017-11-21 16:57:00 浏览1034
展开阅读全文

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)

本文首发于:百度测试技术空间http://hi.baidu.com/baiduqa/blog/item/73173aed4e2ab8f6cf1b3e6a.html
关注百度技术沙龙














本文转自百度技术51CTO博客,原文链接:http://blog.51cto.com/baidutech/743325,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小美
+ 关注