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

cu_Cbear

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

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

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

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



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

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

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

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

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

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

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

配置管理：



变更管理：



持续集成：



质量管理：



发布管理：



存在争议的地方：

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

发布方式从两种方式上来说：第一，主干发布；第二：分支发布

正方：认为有必要

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

反方：认为没有必要

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

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

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