一、前言
毕业之前想的是做开发工作,结果阴差阳错的被分在了测试部门,分都被分了,那就从测试开始干起吧。
工作也快两个月了,这两天第一次接触到源代码管理这一名词,那就从这谈起吧
源代码管理也称为软件配置管理(Configuration Management),是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。
常见的软件配置管理工具有:VSS、SVN、Clearcase,因为笔者也是初学者,以前在学校做项目,因为项目规模不是很大,对代码的管理(合并、删除、版本)只是采用copy,兼具使用日期(比如今天要完成一个功能,就会将以前的代码copy一份,并在原有的基础上开发信的功能,并且以今天的日期140808来命名)命名的方式所进行的,从来没有接触到代码管理的概念,显然这样的方式对于规模比较大,代码量大的项目来说肯定是行不通的。
通过这两天的培训,第一次接触到代码管理的概念,进而觉得对代码的管理师很有必要的。因为培训课程讲的是Clearcase,那我们就从Clearcase开始我们的代码管理过程吧。
二、Clearcase简介
Clearcase是由Rational公司开发的,后来Rational公司被IBM收购后,现在人们一般说Clearcase是一款IBM出的源代码管理工具。
ClearCase通过TCP/IP来连接客户端和服务器。
ClearCase拥有的浮动License可以跨越UNIX和 Windows NT平台被共享。
ClearCase主要应用于复杂产品的并行开发、发布和维护,它可以提供:
其功能划分为四个范畴:版本控制(Version Control)、工作空间管理(Workspace Management)、构造管理(Build Management)、过程控制(Process Control)。
图1 Clearcase四大功能
Clearcase分为两大模式:Base和UCM,这两种模式各有各的好处,但是现在大多数用的是UCM(这里只是个人感觉)
2.1 Clearcase基本对象
VOB是一个特定的数据库系统,其可以①存储有版本的数据;②可以被mount的文件系统;③存储数据的历史版本;④防止数据被非法修改;⑤可以存储数据的类型包括:文件 、目录
VOB中存放的内容都具有版本的概念,这方便用户可以回溯到以前的任何版本进行相关操作
一个项目可以跨越多个VOB,多个项目可以共享同一个VOB
element包括文件和目录(都具有版本的概念)
Version是一个element的其中一个版本,多个版本一起就组成了这个element的版本树
图2 VOB、element、version三者之间的关系图
view是开发者用来访问VOB的视图工具
view可以形象的理解为:照相机的镜头(或者滤镜)
view通过某种规则来获取VOB中元素的某个版本,并组成了操作系统中的目录结构
view其实是“开发者的工作空间”
图3 view的功能图解
view分为动态view和静态view(也称为快照view),各自的优缺点如下:
动态视图,是动态的将CC服务器中的内容同步到开发人员的机器中,这就要求开发人员一直与服务器保持连接。
静态视图,是将CC服务器中的视图内容拷贝到开发人员的机器中,开发人员需要经常与服务器同步以保持数据的一致性,快照视图的好处在于开发人员不必一直通过网络与CC服务器保持连接;但是如果要与服务器同步必须update view。
branch是在某个元素的某个版本处拉出的一个枝干,其主要用于开发人员的并行开发以及Bug的修复(bugfix)
套创建branch实例之前,必须创建branch类型
Label是在某个元素上用具有一定意义的字符串来标识某个特定版本的,以便开发人员(或Leader/Manager)检索和组织软件代码和文档
一个元素可以生成多个版本,label打到特定的版本上,你取到的代码就是唯一的
图4 branch与Label图示
PVOB是UCM(Unified Changed Management,统一变更管理模式)是在base的基础上新增的,用于存储 UCM 所需要的一些特殊的信息,如Proejcts,Stream,Activity及Change Sets等,一个PVOB可以包含多个Project的信息,Project的信息必须保存在PVOB中
stream也是UCM新增的,其分为集成流(Integration stream)和开发流(Develop stream)
Integration stream可以理解为项目的主干,通常也称为干流,每个开发流都是集成流的一个分支
在一个项目的Integration stream上可以拉出许多子流,开发人员可以再这些子流上开发相应的功能,开发完成后,将开发成果再提交到集成流上去,在集成流上集成管理员根据提交的内容进行编译,测试以后在集成流上打上基线(baseline),等所有的测试通过以后可以推荐基线
Project是也UCM在base的基础上新增的,包含了配置管理所需要的一些配置信息,如果Component、Baseline,Stream等,每个Project都有一个Integration Stream
config spec就是view中所讲到的某种特定规则
config spec有三种原则:①从上到下;②从左到右;③回滚;
Component也是UCM新增的,可以理解为一些代码、文档等按一定的目录结构组织成的完成某些功能的可以重用的集合
既然Component是一组文件的集合,则其有三种形式:①一个vob就是一个Component;②一个vob下的根目录就是一个Component;③虚拟存在的;
Activity也是UCM新增的,通过变更集(Change Set)跟踪完成一项开发任务所引起的所有配置项的变更
在UCM模式下所有的Check Out、Check In等引起配置项发生变化的操作必须关联到一个Activity
Baseline也是UCM新增的,基线标识了一个组件或多个组件中所有元素的某一个版本和这些元素的活动
简单理解为就是打在多个相关元素上的某一版本的集合
可以从基线生成开发流或者为一个已有的开发流基线更新(Rebase),一个基线是一个构件在一个特定时刻的一个快照
2.2 小结
从软件产品组成角度:
从软件如何开发角度:
注:参考博客 http://blog.csdn.net/hhg208/article/category/693450
我的测试生涯(1)——开篇《Clearcase简介》,布布扣,bubuko.com
原文:http://www.cnblogs.com/kkdd-2013/p/3900340.html