发布管理与配置管理之间的关系
 

2009-12-18 作者:生活之声 来源:生活之声的博客

 

前段时间在公司做项目的时候遇到了一点问题, 和大家来商量一下. 取点经......

项目大致被分为了配置管理, 变更管理, 持续集成, 质量管理, 发布管理这几个模块(说是模块不太恰当, 暂时这么叫吧).

之前的一种思想是这样的:

所有东西以配置管理为基础, 并实现与配置管理之间的交互。(鉴于项目的特殊性,只能写出基本思想)

其一:配置管理以SVN为配置管理库,制定配置管理计划等等。

其二:变更管理大致可以分为需求变更,设计变更,Bug等;工具有多种选择,BugZilla, Mantis等

其三:持续集成大致分成了干净与增量式的集成;工具使用的是Hudson + Ant + JUnit等等

其四:质量管理由CM组负责提供相应的工具,自动通知测试组版本的变化等。

其五:发布管理负责版本发布的管理等

之间的关系如下所描述(相信大家看完图就会很明确我们制定的各个模块之间的关系):

配置管理:

变更管理:

持续集成:

质量管理:

发布管理:

存在争议的地方:

就在发布管理这一块,就这样说吧,图一里面的从发布管理到配置管理那条线的存在是否有必要的争议。

发布方式从两种方式上来说:第一,主干发布;第二:分支发布

正方:认为有必要

理由:发布管理是以配置管理为基础的,不管何种发布方式,首先在发布之前应该找CM经理商量如何对配置库做变动,做分支也好,从主干发布也好。CM经理再制定相应的配置计划用做此次版本的发布。即发布管理与配置管理之间有直接的交互关系.

反方:认为没有必要

理由:发布管理主要负责版本的发布,至于发布方式在项目开始,从制定项目的配置管理计划时就应该考虑到这些,不管主干发布还是分支发布都应该有相应的配置策略。到真正发布时跟配置管理没有直接的交互关系。这个时候就应该要么走变更,要么走项目管理(没有在我们的模块之内)。如:要准备发布某个版本,这时候发布管理会 new 一个 task 出来进入到整个流程中,以变更为例。这个时候配置经理可以得到这个task,然后对配置库做调整,基于主干也好分支也好,都会在task里面有说明的。也不用再去生成配置计划等的东西,只需要按要求做就完成了。

这个地方是我们争议最大的地方,不知各位大虾米有没有更好的意见,或者你赞同哪一个观点并说明你的理由。

出处: http://blog.sina.com.cn/xiaoxiang7788

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。

资源网站: UML软件工程组织