由于上周末的个人原因,这个博客的更新没有持续。
不过我也没有闲着,一直在想如何用一条线配上几个分支能把我脑袋里的那些东西屡清楚道明白。兴许某日国内的SCM大量需求的时候还能从这老文章上获得点启发。
在经过4天的休息日以及没事想想之后,我觉得还是得回到原点-----SCM存在的意义上来。就是为了满足“客户”的需求,这些需求有些是测试,有些是管理人员,有些是程序员,等等。
说白了,就从图表这个层面,来说一说道一道,从这个需求开始从上到下的贯穿整个SCM的流程和工具吧?我觉得不错。自上而下的。比较容易让人接受。
那么这次这个文章就简单说说,哪些图表是SCM需要的吧。下一步就是一步一步的怎么做这些图表,当然你会发现之前的那个基础框架是多么的有用。
哪些图表需要?
如果你在一个很大的公司那么这些会是你需要的指标,可能会用于考核SCM工作绩效:
- 每日、每周、每月的做包数量
- 每个包的整个时间(从程序员提交代码开始,到发布)
- 每个包的做包时间(从SVN触发开始到测试job开始)
- 做包的失败率、成功率
- 做包的自动化率
- 做包的每日分布图
这些是测试相关的:
- 每个包的测试情况
- 每个包的测试用例运行情况
- 每个包的测试运行时间
- 每个包的测试时间
- 每个包的排队时间
这些是开发的:
- 一个时间段内的代码行数
- 功能数
- 需求覆盖率
- 代码复杂度
- 测试覆盖率
- 技术债务
等等。。。
如果你在一个小公司,而且只有你一个SCM或者是半个:
- 每日、每周、每月的做包数量
- 每个包的整个时间(从程序员提交代码开始,到发布)
- 每个包的做包时间(从SVN触发开始到测试job开始)
- 做包的失败率、成功率
恭喜你,小公司一般没啥测试。
以上是我2分钟内条件反射能想出来的曾经、正在、未来可能要做的图表的名称以及用途。
我要剧透下,每个图表都能套用之前的那个基础框架,神奇不?

1362

被折叠的 条评论
为什么被折叠?



