本文介绍了UCM配置管理系统的基本概念，包括component、activity、baseline、stream及project等核心要素，并阐述了它们在软件项目管理中的应用。
ucm学习（1）
学习UCM要从基本的概念理解。其中最主要的几个基本概念是
pVOB库
component
activity
change set
baseline
stream（分为集成流和开发流等）
project
ucm学习1.1-component
先说一下base模式的开发吧，在base模式下，所有的文件在导入到vob库后，所有的文件都是一个独立的对象，打标签是对每个文件都打的，在选取文件版本的时候一般我们通过选取标签来选取版本的，但是对于UCM就不是这样的，ucm提出了一个comonent的概念，目的是把一组文件看成一个对象来管理。所以打基线（相当于base的打标签）是对comonent打的基线。例如在一个项目中，我们把不同模块的代码放在不同的文件夹中，我们可以把每个模块的文件夹划分成一个component。这样以后在管理项目模块基线时，只要维护该comonent的基线就行了。整个项目的基线就是由项目模块所有的comonent的基线构成
既然一个comonent是一组文件，那么它可以把一个普通的vob库构成component，也可以把一个VOB库的某个文件夹看做component，但是必须是vob库的一级目录
具体的构建方法我们可以在后续的内容中说明
ucm学习1.2-activity
本次我主要是想对activity做一个说明，UCM的开发模式在开发人员进行一项工作之前，例如checkout ，要和一个活动（activity）绑定，也就是明确你的目的，当然该活动记录着你这次操作对那些文件产生产生了新的版本，包含在一个活动的所有版本的变化我们称之为变更集（change set）。这样是不是对活动和变更集有了一个认识了？
ucm学习1.3-baseline
base模式下是通过打标签的方式产生一条基线，然后大家根据打的标签（也称基线）继续新的开发，我们所说的基线实际就是一个标签，但是在base下CC库没有基线的概念。只有在UCM下CC才有基线（baseline）的概念，baseline在UCM下的功能和BASE下的标签的功能基本上是一致的，基线有双重的身份（我个人认为），大家可以在下图我画的简略图中发现一条基线 从compoent的角度看它是属于某个comopent的基线，如果从流的角度看，基线是在某个流中产生的基线，我们有一点要记住，基线的产生是通过流创建的，但是我们从隶属的角度上看他是属于某个component的基线。
基线包含什么内容呢？基线包含活动activity,活动（activity）包含着变更集change set ,变更集包含着一个个版本变化。baseline通过这样的方式把一个个的版本变化包含进来。
当开发者在开发流上提交活动到集成流的时候，系统自动会开发者的开发流上打上基线，名字是以deliver开头的基线。先说这么多吧。
ucm学习1.4-stream
UCM提出了一个project和stream的概念，我们在上一帖子中提到component的概念，compoent是一组文件的一个集合，对应到具体的工作环境中就是一个软件项目的一个模块，一个项目可能有多个模块，项目就是把多个和项目有关的compoent组合在一起，就构成了一个项目，但是他还包含了其他另外的东西，例如stream。那么stream是一个什么样的概念呢？我们在具体的开发环境中，可能有多个小组对一个项目进行并行开发，为了不相互干扰，在一个项目的干流上（UCM称之为集成流）可以拉出很多的子流，这些子流根据不同的需要安排不同的人员在上面开发。（如此看来stream和base模式的branch作用一样的），每个子流开发到一定程度以后可以把子流上的开发成果提交到集成流上去，在集成流上集成管理员根据提交的内容进行编译，测试以后在集成流上打上基线（baseline），等所有的测试通过以后可以推荐基线，也就是要发出一个新的版本，这是开发人员只要在自己的开发流上更新自己的基线就可以过渡到新的版本上来了，也不用去编写config spec了。
ucm学习1.5-project
UCM学习1.5
现在大家对理解的怎么样了？这次我们打算聊聊pvob和项目project，pvob和一般的VOB是不太一样的，一般的VOB我们说主要是用来存放源代码的，但是PVOB一般不用来存放数据，是用来管理UCM中的项目信息的，他包含着PROJECT COMPONENT,Baseline stream，activity等对象的信息。project是基于compoent创建出来的，一个项目project创建后就有一个集成流，类似我们的main分支，但是和分支是不同的两个概念，从集成流上可以产生出子流来，让某个开发者在子流上工作，开发到一定程度可以把它deliver到集成流上去。从而完成一次开发任务。
ucm中的project 是对comopnent的重新规划，可以实现代码的重用，因为项目中的component许多是公用的，根据项目的需要可以在创建项目的时候，选定我们需要的comopnent，也可以在选定的compoent中规定哪些compoent是可写的，哪些Component是只读的。同时我们还可以对project做一些策略，如deliver 策略 项目之间的dilever策略等等
UCM项目的创建可以是根据comopnent的某条基线创建，也可以是根据已有项目的某条基线创建。[@more@]
学习UCM要从基本的概念理解。其中最主要的几个基本概念是
pVOB库
component
activity
change set
baseline
stream（分为集成流和开发流等）
project
ucm学习1.1-component
先说一下base模式的开发吧，在base模式下，所有的文件在导入到vob库后，所有的文件都是一个独立的对象，打标签是对每个文件都打的，在选取文件版本的时候一般我们通过选取标签来选取版本的，但是对于UCM就不是这样的，ucm提出了一个comonent的概念，目的是把一组文件看成一个对象来管理。所以打基线（相当于base的打标签）是对comonent打的基线。例如在一个项目中，我们把不同模块的代码放在不同的文件夹中，我们可以把每个模块的文件夹划分成一个component。这样以后在管理项目模块基线时，只要维护该comonent的基线就行了。整个项目的基线就是由项目模块所有的comonent的基线构成
既然一个comonent是一组文件，那么它可以把一个普通的vob库构成component，也可以把一个VOB库的某个文件夹看做component，但是必须是vob库的一级目录
具体的构建方法我们可以在后续的内容中说明
ucm学习1.2-activity
本次我主要是想对activity做一个说明，UCM的开发模式在开发人员进行一项工作之前，例如checkout ，要和一个活动（activity）绑定，也就是明确你的目的，当然该活动记录着你这次操作对那些文件产生产生了新的版本，包含在一个活动的所有版本的变化我们称之为变更集（change set）。这样是不是对活动和变更集有了一个认识了？
ucm学习1.3-baseline
base模式下是通过打标签的方式产生一条基线，然后大家根据打的标签（也称基线）继续新的开发，我们所说的基线实际就是一个标签，但是在base下CC库没有基线的概念。只有在UCM下CC才有基线（baseline）的概念，baseline在UCM下的功能和BASE下的标签的功能基本上是一致的，基线有双重的身份（我个人认为），大家可以在下图我画的简略图中发现一条基线 从compoent的角度看它是属于某个comopent的基线，如果从流的角度看，基线是在某个流中产生的基线，我们有一点要记住，基线的产生是通过流创建的，但是我们从隶属的角度上看他是属于某个component的基线。
基线包含什么内容呢？基线包含活动activity,活动（activity）包含着变更集change set ,变更集包含着一个个版本变化。baseline通过这样的方式把一个个的版本变化包含进来。
当开发者在开发流上提交活动到集成流的时候，系统自动会开发者的开发流上打上基线，名字是以deliver开头的基线。先说这么多吧。
ucm学习1.4-stream
UCM提出了一个project和stream的概念，我们在上一帖子中提到component的概念，compoent是一组文件的一个集合，对应到具体的工作环境中就是一个软件项目的一个模块，一个项目可能有多个模块，项目就是把多个和项目有关的compoent组合在一起，就构成了一个项目，但是他还包含了其他另外的东西，例如stream。那么stream是一个什么样的概念呢？我们在具体的开发环境中，可能有多个小组对一个项目进行并行开发，为了不相互干扰，在一个项目的干流上（UCM称之为集成流）可以拉出很多的子流，这些子流根据不同的需要安排不同的人员在上面开发。（如此看来stream和base模式的branch作用一样的），每个子流开发到一定程度以后可以把子流上的开发成果提交到集成流上去，在集成流上集成管理员根据提交的内容进行编译，测试以后在集成流上打上基线（baseline），等所有的测试通过以后可以推荐基线，也就是要发出一个新的版本，这是开发人员只要在自己的开发流上更新自己的基线就可以过渡到新的版本上来了，也不用去编写config spec了。
ucm学习1.5-project
UCM学习1.5
现在大家对理解的怎么样了？这次我们打算聊聊pvob和项目project，pvob和一般的VOB是不太一样的，一般的VOB我们说主要是用来存放源代码的，但是PVOB一般不用来存放数据，是用来管理UCM中的项目信息的，他包含着PROJECT COMPONENT,Baseline stream，activity等对象的信息。project是基于compoent创建出来的，一个项目project创建后就有一个集成流，类似我们的main分支，但是和分支是不同的两个概念，从集成流上可以产生出子流来，让某个开发者在子流上工作，开发到一定程度可以把它deliver到集成流上去。从而完成一次开发任务。
ucm中的project 是对comopnent的重新规划，可以实现代码的重用，因为项目中的component许多是公用的，根据项目的需要可以在创建项目的时候，选定我们需要的comopnent，也可以在选定的compoent中规定哪些compoent是可写的，哪些Component是只读的。同时我们还可以对project做一些策略，如deliver 策略 项目之间的dilever策略等等
UCM项目的创建可以是根据comopnent的某条基线创建，也可以是根据已有项目的某条基线创建。[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/91888/viewspace-1005793/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/91888/viewspace-1005793/
扫一扫
4760
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
