持续集成实践成熟度模型
作者:网络转载 发布时间:[ 2012/11/7 10:22:19 ] 推荐标签:
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脚本作为自动化构建开发脚本
新手:
代码签入后即运行包含自动化测试的构建过程
构建结果被有效通知团队
所有人都知道如何运行本地构建
基础构建过程不再有突出的环境问题
通过自动化构建脚本完成自动化构建任务。
专人维护构建环境。
中等
在本地和平台中运行自动化冒烟测试
在平台中运行功能测试全集和性能测试。
充分利用多台机器运行多个构建。
构建过程集成了详细的报告。
能够灵活配置各构建阶段的具体任务。
通过脚本同步及升级各个构建机器中的环境依赖
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11