查看完整版本: 代码级配置管理VS产品级配置管理

代码级配置管理VS产品级配置管理

[font=楷体_GB2312][size=4][color=blue][b]不知道有多少人在做代码级配置管理，又有多少人在做产品级配置管理？请大家举手！[/b][/color][/size][/font]
[b][font=楷体_GB2312][size=4][color=#0000ff][/color][/size][/font][/b]
[font=楷体_GB2312][size=4][color=blue][b]代码级配置管理和产品级配置管理的主要区别又是什么？大家可以从工作内容、工作强度、工作目的、与其它职位之间的关系等多个角度来说说！[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]我可以先抛砖引玉！[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]我现在做的属于产品级配置管理，与以前做的代码级配置管理相比，还是有很多细节不一样的，但是配置管理的方法与中心思想还是完全一致的！[/b][/color][/size][/font]
[b][font=楷体_GB2312][size=4][color=#0000ff][/color][/size][/font][/b]
[font=楷体_GB2312][size=4][color=blue][b]不同之处：[/b][/color][/size][/font]
[b][font=楷体_GB2312][size=4][color=#0000ff][/color][/size][/font][/b]
[font=楷体_GB2312][size=4][color=blue][b]1、产品级配置管理不对代码生成过程进行配置管理，只对Final版的代码进行配置管理，从Final版开始的任何需求变更都在产品级配置管理范畴内，其重点在Final版与衍生版本如何有效稳步发布给客户或做最终记录；代码级配置管理是对整个软件生命周期进行配置管理，从初始版本到最终版本，其所关注的更多是到一个稳定版本之前的与开发者息息相关的代码配置管理，与客户直接关系不大，因为毕竟还有PM来做最终决定；[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]2、从工作强度来看，产品级配置管理略轻松一些，代码级配置管理略繁忙一些；[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]3、产品级配置管理目的就是记录与控制所有交付客户版本的演变；代码级配置管理目的就是控制软件版本在最终成熟版本之前的演变；[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]4、产品级配置管理主要与PM、AM、Customer关系比较密切；代码级配置管理主要与PM、Developer、Tester关系比较密切；[/b][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][/color][/size][/font]
[font=楷体_GB2312][size=4][color=blue][b]5、就使用工具情况来看，产品级配置管理并不是很依赖工具，即使使用工具也无需最深入涉及；代码级配置管理虽然也不是一定要依赖工具，但是毕竟使用工具更能有效进行管理配置，就目前来看代码级配置管理还是比较依赖配置管理工具的，并且对使用配置管理工具的技术技能要求较深。[/b][/color][/size][/font]

[[i] 本帖最后由 青蛙王子 于 2007-9-11 13:06 编辑 [/i]]

大概看明白了楼主的意思

所谓产品级CM，关心的是在V1.0 -> V2.0 -> V3.0的升级过程中所产生的变更情况

而代码级CM，关心的V1.0 -> V2.0之间的整个开发过程，层面相对低一些

但我们的情况不太一样，并没有这种区别

我目前所在的项目，一次完整的release需要几年的时间，做这种划分不是很有必要

我所在的公司也没有分代码级和产品级，但这种划分实际的操作中又能找到模糊的影子。
如代码演进的过程是开发人员重点关注和控制的，而演进到里程碑点（如发布基线）则配置管理员执行配置管理行为。
这应该算是我这例子反映出来的代码级和产品级配置管理的一个区别——负责的人不同。同时我也推荐这样的不同。
但由于这之间没有明确的划分，所以要么双方会就职责范围发生冲突，要么双方推卸责任而产生盲区。
分清二者之间界线，能够促进双方更好的配合与写作。

同时在做代码级和产品级的配置管理工作

不管是build还是release，配置管理做的都是一件事情――保证版本有效稳步的发布出去，不管是给测试还是给客户。

我觉得若真要说代码级和产品级有什么明显不同的话，那就只有是面向配置管理的人员不同，单就我个人看来，配置管理注重的是变更的控制过程，注重的是如何将一个变更从提交到验收的中间过程，而变更是谁在提交，对于整个配置管理过程没有什么影响。

另外，对于一个产品不管是在受控库还是在产品库，就我个人而言，一个配置管理员就足够了。如何发现变更，如何修改变更，那本不是我们作为配置管理员所需要做的事情，我们要做的仅仅是定义并监督项目组遵循版本管理和变更管理这样一个过程，过程确定之后，不论是代码级还是产品级的管理，工作量的变化不会太大。

上面仅是个人的一点愚见，有不当之处还望指点。

这样的选项比较难以选择，觉得一般不会分得这么明确吧。这个应该不是属于非黑即白的论断吧。

谢谢

有一点明白了，那我现在是两者的结合，呵呵

基本上都是合着做的,我以前是项目级的配置管理员

我也是作项目的配置管理的。总的来说也算是产品管理。只管执行文件。其实只能说是产品的版本管理。对于变更只不过感觉起来记录而已。
     但我有个问题。比如你的几家客户使用你的产品，但可能每个客户机型什么的不一样，导致部份配置文件也不同。那这种情况下，各位是怎么管理呢？是把各家的软件独立管理，还是不管配置文件，到时候再改？

我个人觉得，客户不同＼基线不同，提供的相应版本也理所应当会不同，应该针对客户来进行版本的管理

学习了。谢了。老出差。都没时间来上网。

不同的时间来看这篇文章得到的体会果然不一样。。。

我原来一位的概念是项目级别配置管理概念还是组织级别配置管理概念，现在看来应该同样属于项目级别的配置管理，只不过我们关注的地开发的过程还是开发的结果。

不知道下次来看会有什么体会

我们做的是代码级配置管理。只是已基线来标识最后发布的代码版本。
但是集成的交付客户使用的应用程序是不计入配置库中的。

我们公司好像还没有产品级的配置管理，呵呵

我们公司是二者于一身的呢，有一个人统一管理对内的代码级配置和对外的产品级配置

不管是代码级配置管理还是产品级配置管理都只一个人在做

[[i] 本帖最后由 雨@天 于 2008-1-10 14:12 编辑 [/i]]

我认为配置管理还要涉及到编译问题，公司总不能把源码给客户吧。日常中也会有很多的测试版本，每次集成都是很费时间的。

两种都要做--都重要。

两种都要做。分产品库和开发库。两个库均包含代码和文档。开发库更新频繁，产品库更新较少。与用户相关的交互（版本/补丁）或者阶段性成果入产品库。产品库基线与开发库基线相一致。开发库大家使用，产品库由配置管理员独立管理。
对于周期性很长项目，开发库可能很大，可以考虑按产品点进行备份和卸载。

代码级与产品级主要分别是它所面对的配置项不同，不同的配置内容不同，处于软件生命周期的不同阶段。我们公司没有这样的区分。

我们部门也是一个人统一管理对内的代码级配置和对外的产品级配置．
二者的界限不明显，不过，因版本更新很快，代码级的配置管理事物更多．