软件配置管理方法.docx

软件配置管理方法.docx

《软件配置管理方法.docx》由会员分享，可在线阅读，更多相关《软件配置管理方法.docx（13页珍藏版）》请在冰点文库上搜索。

软件配置管理办法

1软件配置管理基础

1.1软件配置管理简介

随着计算机应用范围的日益广泛，应用软件的规模及复杂度日益广泛深入，应用软件的规模和复杂程度日趋大型化，复杂化，这就导致软件开发的方式越来越强调团队的协作开发。

而在这种开发方式下，会遇到很多问题，例如：

需要将整个软件的版本恢复到以前的某

时间的状态，限制随意修改程序，或者控制某一程序在同一时间内只能一个开发人员修改等等。

为了解决这些问题，提高软件产品和软件项目的质量及软件开发过程中的管理水平，好地为以后的软件开发工作提供有效的服务，必须采用先进的管理手段，实现软件产品和软件项目源码的科学管理。

1.2软件配置管理工具

软件配置管理工具有很多，例如：

Starteam、PVCS 、ClearCase、VSS 和 CVS 等。

Starteam、

PVCS 和 ClearCase 更适合庞大的团队和项目，并且价格不菲，所以并不常用。

目前使用比较广泛的是 VSS 和 CVS 。

两者在使用上有各自的优势和不足。

VSS 的全名是 VisualSourceSafe，是微软公司开发的 VisualStudio 开发套件中的软件配置管理部分，有非常好的技术支持和非常详尽的技术文挡。

 VSS 适合在局域网范围内，以

Windows 平台为主的中、小项目，以文件管理为主要功能，使用方便，学习成本低，对服务器仅需要快速大容量的存储器也是它的优势。

CVS 的全名是 ConcurrentV ersionSystem，是一种可以并发的版本控制系统。

它是一个开源项目，可以直接从网站下载最新的源代码。

 CVS 可以满足局域网和广域网不同的网络条件，提供不同级别安全性选择，在一台专门的服务器配合下，客户可以使用任何平台开发项目。

 CVS 本身是在 unix 系统上开发的，在 unix 下提供的是命令行使用模式。

在 Windows

平台下你可以选择用 CVSNT 搭建服务器，用 WinCvs 作为客户端。

 CVS 对于已经完成了开发过程进入项目维护阶段，或者进入项目升级阶段的项目，可提供完善的软件配置管理的支持，不过在学习和操作上学习成本比较高。

1.3软件配置管理实施环境

1.3.1

1）

2）

软件配置管理的实施环境由服务器和客户端软件组成，他们的基本功能如下：

软件配置服务器集中存放软件产品的文件，供多人访问以便进行协同开发。

对产品文件进行安全管理，分配账号并进行访问权限设置。

3）记录所有文件的历史变化，以进行版本控制。

4）保障文件的数据安全，进行冗余存储和备份。

1.3.2客户端软件

1）安装于开发人员的电脑上，用以访问软件配置服务器。

2）提供导入 /导出产品模块的功能。

3）提供对文件的检入 /检出操作。

4）提供查阅和管理文件历史版本的操作。

2软件配置管理的实施目标

软件配置管理包括的范围比较广，我们当前的目标是：

（1）软件配置管理活动被定义和计划。

（2）软件开发过程中的软件制品（程序源码，文档，数据资料等）被识别、控制和管理。

（3）对于处于配置管理下的软件制品的修改被控制。

（4）与软件制品相关的项目组和成员应该被通知制品的目前状态和被修改的信息。

3人员角色分配与职责范围

3.1软件配置管理员

软件配置管理员主要负责如下工作：

1）管理软件配置服务器，维护源码库结构、安全设置，定期备份源码库。

2）编写和维护软件配置管理的相关文档资料，包括服务器配置管理方法、软件配置工具使用方法、软件配置规则与实行方法等。

3）编写培训材料，制定培训计划，对开发人员和产品管理人员进行培训。

4）为开发人员和产品管理人员提供软件配置工具的高级使用技巧支持。

5）督促开发人员定时提交或更新软件源码及文档资料，确保软件配置规则的实行。

3.2开发负责人

开发负责人主要负责如下工作：

1）管理项目文件夹结构，构建代码框架，导入软件配置服务器。

2）在配置管理员的协助下，对项目文件夹的结构和权限进行管理。

3）根据项目进展制定开发基线，管理软件版本编号以及分支版本，必要的时候，负责版本的合并，并解决或指导开发人员解决合并冲突。

4）负责软件发布版本的导出，提供给项目实施人员安装使用。

3.3开发人员

开发人员主要负责如下工作：

1）按照开发负责人的任务分配，从服务器导出项目，进行分工协同开发。

2）从服务器获取代码库最新变更，在自己负责的模块中加入、修改或删除文件。

3）及时提交自己的修改到服务器，并附加变更说明。

4软件配置管理规则

本规则仅限于软件配置管理，而不涉及软件开发的项目管理过程。

4.1分为开发库和产品库进行管理 在软件配置管理工具中，对于源代码的管理一般分为产品库和开发库进行管理。

在软件配置服务器端分别建立产品库和开发库，产品库用于存放通过编译，形成了一定

产品功能并且能够实施的所有软件源代码版本。

开发库中存放正在开发过程中的软件源代码，当这些软件源码符合了一定的条件后，将被导入到产品库。

同样，当开发库需要产品库的源码做为新的开发基线，产品库的源码也可以被导出到开发库进行重新开发。

产品库用于存放软件产品的一系列可发布版本，包括源代码、设计文档、可执行文件、安装包和产品手册。

开发库用于存放开发过程中的一系列软代码版本，是协同开发的工作目录，管理代码文件的历史变更。

在开发库中开发成熟，通过测试后的软件，经过整理设计文档、产品手册、制作安装包后，导入到产品库中存放。

要对现有软件的某一版本进行改进升级时，从产品库导入开发库，作为本次开发计划的开发基线。

4.2对开发库和产品库的管理和操作 我们根据对软件配置管理的不同角色所分配的不同职责范围，对开发库和产品库进行管理和操作。

4.2.1新建版本库这是我们进行软件配置管理的第一步。

首先，由软件配置管理员在服务器端安装和配置

好软件配置管理的工具，然后在服务器上新建两个库目录：

产品库和开发库。

4.2.2对开发库的管理和操作开发库由开发负责人负责日常的更新保管。

对开发库的管理操作方法如下：

（1）导入新项目对于一个新的开发项目，由开发负责人负责构建项目结构。

软件配置管理员配合软件开发负责人 import （导入）该项目到开发库中并完成对新项目的访问权限设置。

（2）对库文件的导入、导出更新以及修改操作开发负责人根据开发任务和开发需要分配开发模块给开发人员。

在开发过程中，软件开发人员根据各人对不同模块拥有的不同权限对开发库中相应的文

件进行 commit （导入） /update（更新）， add（增加） /remove （删除）等操作。

软件开发人员要编辑自己的开发模块，首先，必须 checkout（导出）该模块到本地，然

后在本地对文件进行修改，修改完成后执行 commit （导入）命令将该文件导入到开发库中。

如果是在模块里面增加文件，那么首先要该文件放在要增加文件的模块中， 执行 add（增加）操作。

然后执行 commit （导入）操作，就完成了在模块中增加文件的操作。

如果要从库中删除一个不需要的文件，可以先执行 remove 命令，然后执行 commit 操作向开发库中提交。

软件开发人员如果要在自己开发的模块里面增加一个目录层，就需要执行 import 操作。

如果一个模块对某个软件开发人员只开放了读权限，那么该软件开发人员只能对这个模块执行 update（更新）操作。

建议开发人员每天早上对开发模块使用 update（更新）命令做更新操作，下午下班之前

对开发模块执行 commit （提交）命令，以避免冲突和丢失修改。

同时，程序员必须保证上传的代码是通过编译的源代码。

对于涉及更改项目结构的操作，应由开发负责人负责执行。

（3）对项目进行分支和标记标签

在开发过程中，很多时候需要对一个项目进行 branch（分支）操作，在分支上对项目进

行开发。

这由软件开发人员负责执行。

当项目开发到一个特定阶段，由开发负责人为软件打上标记标签（ tag），作为一个项目

开发的里程碑或开发基线。

（4）再次分配开发模块

开发负责人根据开发任务和开发需要分配开发模块给开发人员。

负责一个开发模块的开发人员我们称为该模块的模块负责人。

在开发过程中，模块负责人可以根据需要把一个开发模块分成几个小的开发模块分配给其它的开发人员进行开发，软件配置管理员配合模块负责人对这些小模块进行访问权限的设置。

之后，各开发人员就可以根据给各人所分配的权限 checkout（导出）这些小模块进行开

发。

（5）上传开发完成的项目到产品库一个软件项目开发完成之后，由软件开发负责人从开发库中导出不包含版本控制信息的该项目的所有模块并把它 import （导入）到产品库中。

同时，由软件配置管理员负责监督检查这些上传的项目模块是否符合软件结构和配置管理规范等。

至此就完成了对一个新项目的开发管理过程。

4.2.3对产品库的管理和操作产品库由软件配置管理人员保管。

产品库中的软件源代码版本来源于开发库或者是公司以前旧的软件产品版本。

对于一个已经开发完成的软件产品，在在投入使用一段时间之后，可能要面临版本升级的情况，例如：

在使用过程中可能会发现该软件的当前版本存在 bug，对于少量的 bug，我

们可以在软件原版本上进行修改。

但是当 bug 累计到一定的阶段，我们对原版本的修改越来越多时，就要考虑在原版本的基础上进行版本的升级。

在软件产品的现有版本上进行版本的升级，首先由软件开发负责人负责 checkout（导出 ）

该软件（在导出的时候不要导出版本控制文件夹）到本地，然后 import （导入）该软件到开发库中。

之后，软件开发负责人和软件开发人员就可以按照对开发库的管理和操作方法根据需要对项目进行修改或者再次开发。

产品的版本号由开发负责人指定。

开发负责人对产品库中的所有版本功能特性的变更要有一个完整的说明，便于以后的开发和使用。

这些工作由软件配置管理人员监督执行，确保软件产品的完整性和正确性。

4.3各司其职以免扰乱版本库结构

软件配置管理员，开发负责人和开发人员要根据自己的职责范围做好工作，以免扰乱版本库结构。

5软件配置管理的方法和技巧

5.1版本主线和分支的概念及运用

5.1.1版本主线

我们把一个项目的主要开发过程成为开发主线。

 通常，一个文件的主干版本历史是一条

增长线。

5.1.2分支软件配置管理并不局限于线性的开发。

它可以将对文件的修改隔离到一个分离的开发线上，而不会影响主线版本，这条线被称为分支。

（1）主线版本可以分为不同的分支，每一个分支可以是一个独立的自我维护的开发线。

当你改变了一个分支中的文件时，这些更改不会出现在版本主线和其它分支版本中。

如果有需要，你可以使用 merge（合并）命令将这些变更合并到另一个分支或者版本主线上。

（ 2）在软件配置管理中进行 branch（分支）操作，一般是针对整个软件项目：

编译好的.exe、 .dll 文件等。

对一个或者几个文件进行分支操作是没有实际意义的。

（ 3）软件项目开发过程中充满了各种不确定性，有时我们需要试探，那么我们在主线版本上开发就存在一定的风险，可能会破坏原来的版本结构。

而使用分支可以帮我们解决这些问题。

例如：

当软件已经达到了一个相对稳定的状态，下一步是想实验加入一种新功能 （新

算法），但是对它没有信心。

担心加入新内容后，系统边的不稳定，希望能方便地回到目前的稳定状态。

再比如：

我们已经发布了一个软件的 1.0 版本，目前的工作已经集中在版本 2.0。

但是，这时发现版本 1.0有一个严重的 bug。

那么，这些情况下，最好的方法就是使用分支。

5.2开发基线和里程碑

在软件配置管理中，开发基线和里程碑是两个重要的概念。

（1）里程碑：

项目开发到一定的阶段，例如：

新上传了一个模块、编译通过了一个模块、完成了一定的产品功能等，都可以给该项目设定一个阶段的里程碑。

对于里程碑的设定，可以是一个项目，也可以是几个文件。

在我们的开发过程中，一般是对整个项目设定里程碑。

里程碑也是项目多个分支开发的基础。

（2）开发基线：

对实现了一定功能的软件产品打上 tag 标记作为一个开发基线 （baseline）。

 一个开发基线是一个特殊的里程碑，开发基线作为一个再次开发的基础。

例如：

开发一个软件，初步实现了产品要求的大的功能框架，那么这时候我们可以为该软件打上 tag 标记作为一个开发基线，作为其它补充功能开发的基础。

同样，在开发过程中，对开发基线的设定也是针对整个项目。

5.2.1（3）设定里程碑和开发基线的 tag 标志时，要注意给定不同的命名规则，以免在使用过程造成混乱

白酒新熟山中归，黄鸡啄黍秋正肥。

呼童烹鸡酌白酒，儿女嬉笑牵人衣。

高歌取醉欲自慰，起舞落日争光辉。

游说万乘苦不早，著鞭跨马涉远道。

会稽愚妇轻买臣，余亦辞家西入秦。

仰天大笑出门去，我辈岂是蓬蒿人。

 《春晓》作者：

孟浩然春眠不觉晓，处处闻啼鸟。

夜来风雨声，花落知多少。

《鹿柴》作者：

王维空山不见人，但闻人语响。

返影入深林，复照青苔上。

《相思》作者：

王维

红豆生南国，春来发几枝。

愿君多采撷，此物最相思。