三库（开发库、受控库、静态库）的概念及个人的理解
作者 流水先生   查看 18948   发表时间 2007/3/1 10:25  【论坛浏览】
记得第一次在国内的坛子里看到三库的讨论的时候，登时就晕了…… fhopx
三库的概念被弄得挺严重，甚至被实现为物理上的多个库……fhopx
fhopx
这里，首先贴一下三库定义的原文、翻译，然后再谈谈个人的理解……fhopx
fhopx
==原文位置==fhopx
（中国国家标准也有三库的定义。这里就不再给出了。这里给出的是CMMI的定义，若有其它国际上比较权威的定义，烦请熟悉的同志贴一下，谢!）fhopx
fhopx
CMMI V1.0 fhopx
=> level 2 fhopx
=> Configuration Managementfhopx
=> SG 1 Estabish Baselines fhopx
=> SP 1.2 Establish a Configuration Management Systemfhopx
=> Subpractices 2. Store and retrieve configuration items in the configuration management system.fhopx
fhopx
==原文==fhopx
fhopx
Examples of configuration management systems include the following:fhopx
fhopx
Dynamic (or developer's) systems contain components currently being created or revised.fhopx
They are in the developer's workspace and are controlled by the developer.fhopx
Configuration items in a dynamic system are under version control.fhopx
fhopx
Master (or controlled) systems contain current baselines and changes to them.fhopx
Configuration items in a master system are under full configuration management as described int ths process area.fhopx
fhopx
Static systems contain archives of various baselines released for use. fhopx
Static systems are under full configuration management as described in this process area.fhopx
fhopx
==翻译==fhopx
fhopx
（感谢cmmi_cn@163.com等同志对CMMI的翻译工作！）fhopx
fhopx
CMMI V1.0 fhopx
=> 第二级 fhopx
=> 配置管理fhopx
=> SG 1 建立基线 fhopx
=> SP 1.2 建立配置管理系统fhopx
=> 子实践 2. 在配置管理系统中存取配置项fhopx
fhopx
配置管理系统举例如下：fhopx
fhopx
动态（或开发者）系统，包含当前正在产生或修订的组件。fhopx
它们在开发者的工作区，而且由开发者所控制。fhopx
属于动态系统的配置项，在版本控制之下。fhopx
fhopx
主（或受控）系统，包含当前的基线和基线的变更。fhopx
属于主要系统的配置项，在本过程域所描述的完全的配置管理之下。fhopx
fhopx
稳定的系统，包含已分发使用的各种基线的保存档。fhopx
稳定的系统，在本过程域所描述的完全的配置管理之下。fhopx
fhopx
fhopx
==个人理解==fhopx
fhopx
首先，三库仅仅是举例，在实践中，并不是一定要弄出三个库来。fhopx
其次，三库是逻辑上的概念，在实践中，并不是要对应到物理上的三个库。fhopx
根据定义，开发库可以大致映射为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。当然，对于稍大的任务，也可以映射为存储库里的一个任务分支。fhopx
而受控库，则是开发工程师相互协作、交流最新工作成果的地方。大致上，可以映射为版本控制工具（svn/cvs/cc……）的repository(存储库)。这里，可能有不同的分支/目录做不同的用途，可能会打标签、基线。fhopx
静态库，又称基线库，指的是那些重要的基线，这些基线标志着项目的重要里程碑，或者这些基线被Release（发布）给了“外界”。在比较简单的版本控制工具里，一般可以用特定标签命名规范来把它们从其他标签、基线中区别出来；在SVN中，可以设置一个特别的Tag目录。而在比较复杂的版本控制工具里，也可以用基线/标签的某种属性（质量级别）来表达。例如，当某条基线通过了系统测试后，就把它的质量级别promote（提升）到“通过系统测试”。fhopx
对于静态库，再补充一点：对于这些基线，我们通常不仅要记录源代码，最好也保存一下编译结果/安装包。这样将来用起来会比较方便。编译结果/安装包一般就不要放到版本控制工具里去了，除非你受了商业宣传的蛊惑…… 在合适的机器上建个共享目录，设置合适的权限，来存储编译结果/安装包，一般就可以了。fhopx
fhopx
fhopx
个人意见。大家拍砖吧^_^

序号 评论者 共有评论 93   【论坛浏览】  【发表评论】 评论时间
11 netjs 谢谢大家的指导，特别感谢流水先生把我提的问题进行详细讨论

“逻辑上独立，物理上一起”

现在基本明白了，还要在以后实践中继续体会		 2007/3/22 12:08
12 chenjingxian 谢谢大家的见解，使我对于三库的抽象概念与现实的配置环境有了更好的对应，从而对三库有了更深刻的理解。 2007/4/28 10:41
13 jkdragon 三库是逻辑上的概念，那么分支则应该是物理上的概念吧？ 2007/5/23 15:19
14 sidenf_cvs 也是受益不少，我的确也是产生误解的一员。不管是几个库，最终都是要提管理效率和保存产品成果和工作记录。 2007/5/24 18:16
15 bin800 个人观点

三库的概念，要根据项目组或各公司的情况而定，不能一概而论。

个人比较同意8楼的说法

我们公司的三库是这样的，开发库-〉开发人员的活动空间

受控库-〉经过申请后提交的东西，已经有scm人员进行管理了。

产品库-〉最终提交到客户的东西。客户已经正在使用的东西。		 2007/5/24 18:41
16 yjg021 :4:: 楼上各位同任都讲的很细,仔细学习一下,在实践中也按这总标准操作! 2007/5/30 14:37
17 Snow1 个人观点：
是否采用物理三库，还要根据team的实际情况而定。
1、如果产品的稳定性和产品质量较高，版本发布后补丁和修正较少，可以采用物理三库。
2、如果产品成熟度不高、质量不高，就一定不要采用物理三库了。建立采用逻辑三库。否则修订文件在三库之间的转换将是非常繁琐和容易出错的工作。事实上对产品质量也是隐患。		 2007/5/30 15:04
18 tuohz 条条大路通罗马....我的理解! 2007/6/9 02:13
19 W.ff 对三库的理解比较赞同shuku 的观点，对三库的具体实现更赞同among的观点－－“通过基线，分支可以做到物理的单独一个库”。

[ 本帖最后由 W.ff 于 2007-6-20 11:36 编辑 ]		 2007/6/11 10:41
20 香飘何方 回复 #1 流水先生 的帖子
三库的概念基本可以这么理解，但还是有一点不能确定，请教一下：软件受控库到底是为什么角色服务的，可能这样表达不是很清楚，换句话说，对于嵌入式软件，当为了调试软硬件集成产品而在生产线上要使用的软件，应该从哪个库提取（目前在没有利用工具之前，三库是物理分开的，分属于不同部门来管理，工具正在启动中）？有人认为可以从受控库提取，有人认为必须从产品库提取（我也是如此理解的），目前没有一个可以明确的答案（当然各个库均是受控的），请问谁能给解答一下？		 2007/6/19 20:49
 共有评论数 93  每页显示 10
页码 2/10  |<  <<   1 2 3 4 5 6 7   >>  >|