Subversion实践案例——配置管理和缺陷跟踪的整合
2009-07-08 00:01
316 查看
基本信息
用户单位:某制造业软件研发企业
用户规模:100人以上
组织过程水平:中等
CMMI评审等级:3级
Subversion使用时间:2年
客户需求
由于公司开发的产品在交付每个不同客户的时候都进行了较多的定制开发,所以当项目进入开发后期以及交付客户后的初期,缺陷的修复便成了开发团队的一个主要工作。根据公司制定的相关流程,在相关软件已经提交客户后,为了保证开发主线上代码质量的稳定性,因此所有的缺陷都必须在独立任务分支上完成,验证通过后由专人负责进行相关的合并操作。
公司原先采用开源的缺陷跟踪工具(BugZilla)来对缺陷进行跟踪和管理,从该软件本身的功能上来说基本能够满足缺陷跟踪的所有需求。但由于该软件和Subversion的操作无法进行整合,版本库内大量的操作(如创建任务分支、授权及合并操作等)都需要手工来完成,在缺陷提交相对频繁的时候,无论是对相关人员的工作量还是相关操作的准确性都是一个不小的考验。
另外,对于部分相关的人员(如负责质量保证的QA等)希望以在线的方式(而非检出到本地)对缺陷修复的相关代码进行审查,这也是BugZilla当前无法完成的。
综上所述,客户对缺陷跟踪的相关需求可以归纳为:
1、需要从主配置库中分离部分内容创建用于在异地开发的远程配置库
2、远程配置库的访问权限能够直接从主配置库中直接获取
3、可以对远程配置库进行单独的授权控制和管理
4、当派出团队回到公司总部时需要对两个配置库的内容进行同步
5、派出团队在异地时也需要用非在线的方式(如邮件、即时通信工具、FTP等)对两个配置库进行数据的同步。
问题解析
从客户的相关需求可以得出以下结论,BugZilla对于缺陷跟踪本身是可以满足要求的,而不足之处主要的是在和Subversion的操作整合上,由于Bugzilla本身是一个独立的软件,要通过对其进行扩展使其和Subversion完全整合无疑是一个非常困难的工作。因此,结合各种因素和现有的资源,我们最终选择了直接开发一个和Subversion完全整合的缺陷跟踪系统,从而来彻底满足客户的相关需求。
我们的解决方案
我们所提供的解决方案如下图所示:
![](http://p.blog.csdn.net/images/p_blog_csdn_net/microke/563798/o_%E7%BC%BA%E9%99%B7%E8%B7%9F%E8%B8%AA_thumb.jpg)
首先,提供一套功能和BugZilla相当的缺陷管理系统,在和Subversion的整合方面提供以下功能:
a、在分配任务的时候自动创建相应的任务分支并自动完成相关的授权。
b、缺陷完成验证后,自动由任务分支向主开发线合并代码并(在合并成功后)关闭任务分支
c、提供以在线方式(通过浏览器)查看缺陷相关的每个提交版本的代码内容以及相关的差异比较,并对该调阅功能提供授权控制。
参见:SmartChange事务跟踪模块
用户单位:某制造业软件研发企业
用户规模:100人以上
组织过程水平:中等
CMMI评审等级:3级
Subversion使用时间:2年
客户需求
由于公司开发的产品在交付每个不同客户的时候都进行了较多的定制开发,所以当项目进入开发后期以及交付客户后的初期,缺陷的修复便成了开发团队的一个主要工作。根据公司制定的相关流程,在相关软件已经提交客户后,为了保证开发主线上代码质量的稳定性,因此所有的缺陷都必须在独立任务分支上完成,验证通过后由专人负责进行相关的合并操作。
公司原先采用开源的缺陷跟踪工具(BugZilla)来对缺陷进行跟踪和管理,从该软件本身的功能上来说基本能够满足缺陷跟踪的所有需求。但由于该软件和Subversion的操作无法进行整合,版本库内大量的操作(如创建任务分支、授权及合并操作等)都需要手工来完成,在缺陷提交相对频繁的时候,无论是对相关人员的工作量还是相关操作的准确性都是一个不小的考验。
另外,对于部分相关的人员(如负责质量保证的QA等)希望以在线的方式(而非检出到本地)对缺陷修复的相关代码进行审查,这也是BugZilla当前无法完成的。
综上所述,客户对缺陷跟踪的相关需求可以归纳为:
1、需要从主配置库中分离部分内容创建用于在异地开发的远程配置库
2、远程配置库的访问权限能够直接从主配置库中直接获取
3、可以对远程配置库进行单独的授权控制和管理
4、当派出团队回到公司总部时需要对两个配置库的内容进行同步
5、派出团队在异地时也需要用非在线的方式(如邮件、即时通信工具、FTP等)对两个配置库进行数据的同步。
问题解析
从客户的相关需求可以得出以下结论,BugZilla对于缺陷跟踪本身是可以满足要求的,而不足之处主要的是在和Subversion的操作整合上,由于Bugzilla本身是一个独立的软件,要通过对其进行扩展使其和Subversion完全整合无疑是一个非常困难的工作。因此,结合各种因素和现有的资源,我们最终选择了直接开发一个和Subversion完全整合的缺陷跟踪系统,从而来彻底满足客户的相关需求。
我们的解决方案
我们所提供的解决方案如下图所示:
![](http://p.blog.csdn.net/images/p_blog_csdn_net/microke/563798/o_%E7%BC%BA%E9%99%B7%E8%B7%9F%E8%B8%AA_thumb.jpg)
首先,提供一套功能和BugZilla相当的缺陷管理系统,在和Subversion的整合方面提供以下功能:
a、在分配任务的时候自动创建相应的任务分支并自动完成相关的授权。
b、缺陷完成验证后,自动由任务分支向主开发线合并代码并(在合并成功后)关闭任务分支
c、提供以在线方式(通过浏览器)查看缺陷相关的每个提交版本的代码内容以及相关的差异比较,并对该调阅功能提供授权控制。
参见:SmartChange事务跟踪模块
相关文章推荐
- Subversion实践案例——配置管理和缺陷跟踪的整合
- 使用配置方式进行ssh的整合以及管理员管理的案例(二)
- Subversion实践案例——以只读方式实现对配置库内容的调阅
- Subversion实践案例——合并跟踪
- 使用配置方式进行ssh的整合以及管理员管理的案例
- 缺陷管理工具bugfree快速安装配置
- SSH框架整合-使用XML方式配置事务管理
- Subversion实践案例——精细化的访问控制(二)
- 使用开源软件 Mantis 实施缺陷跟踪的成功实践
- 【TFS权限管理】配置 Team Foundation Server 团队权限最佳实践
- Linux系统管理实践(6):系统登录配置
- Linux系统管理实践(8):网络配置 (续)
- 2950实践2---理解什么叫管理vlan与业务VLAN,理解DTP及trunk的配置
- 缺陷管理平台Mantis配置步骤
- disconf实践(二)基于XML的分布式配置文件管理,不会自动reload
- 通过案例掌握Spring 管理事务的步骤及配置
- java.util.logging无配置文件全局日志管理案例
- Linux系统管理实践(8):网络配置 (续)
- Linux系统管理实践(7):网络配置
- Linux系统管理实践(10):PPPoE上网配置