|
|
| 三库（开发库、受控库、静态库）的概念及个人的理解 |
| 作者 流水先生 查看 18947 发表时间 2007/3/1 10:25 【论坛浏览】 |
记得第一次在国内的坛子里看到三库的讨论的时候，登时就晕了…… dycezzvyf
三库的概念被弄得挺严重，甚至被实现为物理上的多个库……dycezzvyf
dycezzvyf
这里，首先贴一下三库定义的原文、翻译，然后再谈谈个人的理解……dycezzvyf
dycezzvyf
==原文位置==dycezzvyf
（中国国家标准也有三库的定义。这里就不再给出了。这里给出的是CMMI的定义，若有其它国际上比较权威的定义，烦请熟悉的同志贴一下，谢!）dycezzvyf
dycezzvyf
CMMI V1.0 dycezzvyf
=> level 2 dycezzvyf
=> Configuration Managementdycezzvyf
=> SG 1 Estabish Baselines dycezzvyf
=> SP 1.2 Establish a Configuration Management Systemdycezzvyf
=> Subpractices 2. Store and retrieve configuration items in the configuration management system.dycezzvyf
dycezzvyf
==原文==dycezzvyf
dycezzvyf
Examples of configuration management systems include the following:dycezzvyf
dycezzvyf
Dynamic (or developer's) systems contain components currently being created or revised.dycezzvyf
They are in the developer's workspace and are controlled by the developer.dycezzvyf
Configuration items in a dynamic system are under version control.dycezzvyf
dycezzvyf
Master (or controlled) systems contain current baselines and changes to them.dycezzvyf
Configuration items in a master system are under full configuration management as described int ths process area.dycezzvyf
dycezzvyf
Static systems contain archives of various baselines released for use. dycezzvyf
Static systems are under full configuration management as described in this process area.dycezzvyf
dycezzvyf
==翻译==dycezzvyf
dycezzvyf
（感谢cmmi_cn@163.com等同志对CMMI的翻译工作！）dycezzvyf
dycezzvyf
CMMI V1.0 dycezzvyf
=> 第二级 dycezzvyf
=> 配置管理dycezzvyf
=> SG 1 建立基线 dycezzvyf
=> SP 1.2 建立配置管理系统dycezzvyf
=> 子实践 2. 在配置管理系统中存取配置项dycezzvyf
dycezzvyf
配置管理系统举例如下：dycezzvyf
dycezzvyf
动态（或开发者）系统，包含当前正在产生或修订的组件。dycezzvyf
它们在开发者的工作区，而且由开发者所控制。dycezzvyf
属于动态系统的配置项，在版本控制之下。dycezzvyf
dycezzvyf
主（或受控）系统，包含当前的基线和基线的变更。dycezzvyf
属于主要系统的配置项，在本过程域所描述的完全的配置管理之下。dycezzvyf
dycezzvyf
稳定的系统，包含已分发使用的各种基线的保存档。dycezzvyf
稳定的系统，在本过程域所描述的完全的配置管理之下。dycezzvyf
dycezzvyf
dycezzvyf
==个人理解==dycezzvyf
dycezzvyf
首先，三库仅仅是举例，在实践中，并不是一定要弄出三个库来。dycezzvyf
其次，三库是逻辑上的概念，在实践中，并不是要对应到物理上的三个库。dycezzvyf
根据定义，开发库可以大致映射为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。当然，对于稍大的任务，也可以映射为存储库里的一个任务分支。dycezzvyf
而受控库，则是开发工程师相互协作、交流最新工作成果的地方。大致上，可以映射为版本控制工具（svn/cvs/cc……）的repository(存储库)。这里，可能有不同的分支/目录做不同的用途，可能会打标签、基线。dycezzvyf
静态库，又称基线库，指的是那些重要的基线，这些基线标志着项目的重要里程碑，或者这些基线被Release（发布）给了“外界”。在比较简单的版本控制工具里，一般可以用特定标签命名规范来把它们从其他标签、基线中区别出来；在SVN中，可以设置一个特别的Tag目录。而在比较复杂的版本控制工具里，也可以用基线/标签的某种属性（质量级别）来表达。例如，当某条基线通过了系统测试后，就把它的质量级别promote（提升）到“通过系统测试”。dycezzvyf
对于静态库，再补充一点：对于这些基线，我们通常不仅要记录源代码，最好也保存一下编译结果/安装包。这样将来用起来会比较方便。编译结果/安装包一般就不要放到版本控制工具里去了，除非你受了商业宣传的蛊惑…… 在合适的机器上建个共享目录，设置合适的权限，来存储编译结果/安装包，一般就可以了。dycezzvyf
dycezzvyf
dycezzvyf
个人意见。大家拍砖吧^_^ |
| 序号 |
评论者 |
共有评论 93 【论坛浏览】 【发表评论】 |
评论时间 |
|
| 21 |
W.ff |
要看受控库为什么角色服务的话就要看受控库意义何在了,现在大家比较认同的观点就是受控库是开发工程师相互协作、交流最新工作成果的地方.那么服务的角色也就不言而喻了.
还有,既然是集成需要的软件,那么这个软件的来源是什么?项目组自身开发,第三方,重用?不管它从哪里来,都需要经过确认是一款成熟的,能保证集成质量的软件.那么这款软件肯定是从产品库提取的.
对软件应该从哪个库取到有异议其实还是因为对三个库的理解还有异议,当然我的理解也是个人观点.还望专家指正. |
2007/6/20 10:29 |
|
| 22 |
香飘何方 |
回复 #22 W.ff 的帖子
在这: 4:: W.FF啦！
[ 本帖最后由 香飘何方 于 2007-7-2 13:48 编辑 ] |
2007/6/20 14:10 |
|
| 23 |
W.ff |
呵呵,香飘兄太客气了,我只是提一点个人看法.
我想的话,不管是什么项目,现在集成一般采用迭代的方式,循序完成最终的集成.在循序的集成过程中,由于对集成顺序的安排,可能这个软件模块已完成,并投入到集成中,而下一个模块还在开发,那么对于整个软件来说就不清楚到底是在受控库还是在产品库.不知道我是不是理解到了香飘兄的意思,下面我就对我的观点作个解释.
其实,这个时候我们把基线的范围缩小就行了,基线毕竟是一个概念,只要是稳定的,能为后续版本作铺垫的,那么就可以进行基线控制,而不一定说在需求之后打条基线,在设计之后打条基线之类的硬性规定,灵活处理即可.
集成需要的软件肯定是一个经过正式评审确定的软件版本,那么版本肯定是存在于基线中的.所以我觉得这个时候可以把基线的控制缩小到模块的层面.因为软硬件集成的话也是一个模块一个模块集成的,集成前肯定也要进行一系列的测试.所以等到某个模块经过测试通过之后就直接纳入基线,而不需要等到最终软件成型之后再纳入基线了,这个时候集成所需的软件就是从产品库中提取的,保证是较稳定的.
而对于保证质量,除了测试,其实项目上所有的参与者的目的都是用来保证质量的,项目经理的项目管理,系统架构师的技术支撑,QA的质量保证,SCM的完整性保证,这些都是用于保证质量的,只是形式不一样而已.不过如香飘兄所说,测试确实是最见成效的,呵呵,肉眼看得见的.
还是那句话,个人观点,都快成座右铭了,呵呵,请赐教! |
2007/6/20 15:31 |
|
| 24 |
香飘何方 |
回复 #24 W.ff 的帖子
看了W.FF的观点，与我本人的理解基本相同，但还是觉得这些都是理想状态。在遇到问题时，请W.FF指教！请专家指教！
[ 本帖最后由 香飘何方 于 2007-7-2 13:49 编辑 ] |
2007/6/20 20:51 |
|
| 25 |
stico |
Good explaination, thanks. I feel it not so easy to relate to CMM |
2007/7/3 17:44 |
|
| 26 |
nemo |
受教！
我刚进入这行，觉得有好多东西都要学啊！ |
2007/7/4 10:07 |
|
| 27 |
yuannahui |
| 引用: | 原帖由 W.ff 于 2007-6-11 10:41 发表
对三库的理解比较赞同shuku 的观点，对三库的具体实现更赞同among的观点－－“通过基线，分支可以做到物理的单独一个库”。 |
|
“通过基线，分支可以做到物理的单独一个库” 那其实物理的存储还是分开的，只是通过一个库上不同的目录存放这些信息而已，对吧？
当然这个还是与纯粹的两个库有所不同。 |
2007/7/12 13:40 |
|
| 28 |
yuannahui |
我认为“三库”的理念非常好，可以很清晰的区分出基线前后的概念，想把这个引入到我们公司的配置管理规程里面，所以再次重新的看了上面所有的信息，想结合大家的看法制定出一个合适的目录结构，但是我发现了一个问题：
楼主对三库的理解其实和第8楼的理解是不一样的。楼主认为
1、开发库可以大致映射为开发工程师的个人工作空间，在开发工程师本机上，个人目录下。当然，对于稍大的任务，也可以映射为存储库里的一个任务分支。
2、受控库，则是开发工程师相互协作、交流最新工作成果的地方。大致上，可以映射为版本控制工具（svn/cvs/cc……）的repository(存储库)。
。。
但是shuku 认为：
1、动态库应该强调项目组成员日常的工作成果，比如日常开发的代码，为成形的文档，项目管理类的文档，配置库的使用应该也包括对这些日常工作成果的管理，当然这种管理应该是最低层次的管理，主要目的是为了保护他们的工作成果，当然还有也为度量之用。
（这个应该对应到楼主的第二条）
。。。
所以比较疑惑（我绝非咬文嚼字，主要是要根据这样的想法制定出一个目录结构，上面两种的看法制定出的目录结构其实是不一样的），不知道哪种理解才是正确的，或者说是无所谓对错，两种理解都对吗？ |
2007/7/12 17:23 |
|
| 29 |
fzh1013 |
受教受教,各位大虾让我收益匪浅 |
2007/7/20 11:33 |
|
| 30 |
SnowJin |
我不大赞同楼主对受控库的理解。楼主提到：“而受控库，则是开发工程师相互协作、交流最新工作成果的地方。”
我认为开发工程师相互协作、交流最新工作成果的地方恰恰是开发库（动态库）的概念。
而每个开发工程师自己的开发环境（本机）只是属于开发库的一部分。
能够提供所有开发人员协同工作的才是开发库。
受控库应该是有严格权限控制的库别，能够提交到这个库中的文档或者代码的角色应该是受限制的，而不是开放的。
这个库，同时也是开发组和测试协同工作的一个库别，要提交给测试组测试的代码和测试依据的文档都应该是从这个库别中发出的。
我觉得如果只有一个库的话，我使用过的配置管理工具（vss/cvs/svn）都不能很好地解决软件受控的处理。
配置管理员存取配置项得到受控库的工作我觉得单单用基线或者标签来实现的话，还是很困难的。
但是受控库和静态库倒是可以用用基线或者标签来区分的。因为这2个库都是相对稳定的库别。
3库可以用2库来实现倒是比较好理解一点。
[ 本帖最后由 SnowJin 于 2007-7-23 17:06 编辑 ] |
2007/7/23 16:49 |
共有评论数 93 每页显示 10
|
|
