it软件配置管理

1、it软件配置管理,林琳 软件技术教研室,第 5章 软件配置管理,5.1 概述 5.2 配置项 5.3 基线 5.4 版本控制 5.5 变更控制 5.6 软件配置管理系统,软件项目中是否遇到如下的问题：,开发人员使用错误的版本修改程序； 开发人员未经授权修改代码或文档,或修改的结果不能及时反映到各个相关部分； 人员流动，交接工作不彻底造成软件关键部件遗失； 已修复的Bug在新版本中出现； 找不到某个文件的历史版本； 无法重新编译某个历史版本，使维护工作十分困难； 因协同开发中，或者异地开发，版本变更混乱导致整个项目失败； ,软件项目进行中面临的一个主要问题是持续不断的 变化,有效的项目管理能够控

2、制变化. 以最有效的手段应对变化,不断命中移动的目标。,5.1 概述,软件配置管理的概念 SCM简单而言就是管理软件的变化，应用于软件工程过程，通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。 软件配置管理的目的与益处 有效的软件配置管理可以解决一些常见的问题； 有效的软件配置管理可以节约用户资金； 有效的软件配置管理可以提高软件开发管理的水平； 有效的软件配置管理可以保护企业的知识财富。,软件配置管理四个活动,配置项标识、跟踪 配置管理环境建立,基线变更管理,配置审核,配置状态统计,5.2 配置项,5.2.1 配置项定义 5.2.2 软件配置控制 5.2.3 配置

3、项标识,5.2.1 配置项的定义,所有在软件过程中产生的信息，总称为软件配置项，主要包括： 计算机程序（源代码和可执行程序）； 描述计算机程序的文档（针对技术开发者和用户）； 数据（包含在程序内部或外部）。,配置项内容,5.2.2 软件配置控制,配置控制是配置管理的核心工作。配置控制主要包括： 存取控制：设定了软件开发人员对软件基准库的存取权限，保证软件开发过程及软件产品的安全性； 版本控制：是配置管理的基本要求，使得组织在任何时刻都可以获得配置项的任何一个版本； 变更控制：为软件产品变更提过了一个明确的流程，要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施； 产品发布：保证

4、了提交给客户的软件产品是完整的、正确的。,5.2.3 配置项标识,软件配置项标识是管理配置的前提。标识包括文件名和版本。 确定配置项：软件项目在开发过程中会产生成千上百个配置项，那么确定配置项是很重要的； 明确配置项标识的要求：项目组人员按照标识规则对配置项进行标识，最后提交给配置管理员纳入配置库统一管理； 配置项命名： (1) 唯一性：在一个项目内不能出现重名，以避免混淆； (2) 可追溯性：系统的要求，即名字应能体现相邻配置项之间的关系。,5.3 基线,常用软件基线：,基线属性与优点,基线是软件生存期各开发阶段末尾的特定点，也称里程碑。 基线的属性： 通过正式评审过程建立； 存在于基线库，

5、对基线的变更接受更高权限的控制； 基线是进一步开发和修改的基准和出发点； 进入基线前，不对变化进行管理；进入基线后，对变化进行有效管理； 不会变化的内容不纳入基线，变化对其它无影响的也不纳入基线； 基线具有名称、标识符、版本、日期等属性； 交付给客户的基线成为一个Release，内部开发用的基线为一个Build。 基线的优点 重现性：当更新不稳定或不可信时，基线提供一种取消变更的方法； 可追溯性：建立项目工件之间的前后继承关系； 版本隔离：新项目与随后对原始项目所进的变更进行隔离。,基线种类,功能基线(Functional Baseline) 指派基线(Allocated Baseline)

6、产品基线(Production Baseline),软件过程中的配置基线,5.4 版本控制,5.4.1 版本的访问与同步控制 5.4.2 版本分支和合并 5.4.3 版本的历史记录,5.4.1 版本的控制与同步控制,版本的访问控制 工作区域中的源文件是从库中恢复得到的一个复制文件，它可以是可“写”的，也可以是可“读”的。一般有两种工作模式： 一是在工作区域一旦有“读”请求，就做一次恢复操作，获得复制文件，当“读”操作结束，该复制文件被删除； 二是仅当软件库中的内容发生更改时，才发生交互，而不是每次“读”操作都与软件库中的文件发生交互。 版本的同步控制 同步控制实际上时版本的检入检出控制： 检入

7、：将软件配置项从用户的工作环境存入到软件配置库的过程； 检出：将软件配置项从软件配置库中取出的过程。,访问和同步控制的流程图,软件工程师,软件配置库,检入,检出,访问控 制,5.4.2 版本分支和合并,版本分支 版本分支人工方法就是从主版本复制一份文件，做上标记；实行版本控制之后，版本的分支是一份复制文件，这时的复制过程和标记动作由版本系统自动完成。 版本合并 版本合并是通过对文件的比较来进行合并。有两种途径： 一种是将版本A的内容附加到版本B中； 另一种是合并A和B的内容，形成新的C； 后一种途径更容易理解，也符合软件开发的思路。,5.4.3 版本的历史记录,文件和目录的版本演化的历史可以形

8、象的表示为图形化的版本树； 版本树由版本依次连接形成，每个结点代表一个版本，根结点是初始版本，叶结点代表最新的版本； 典型的软件系统包含多个文件和目录，每个文件和目录都有自己的版本树； 版本的历史记录有助于对软件配置项进行审计，有助于追踪问题的来源； 版本的历史记录应该包含版本号、修改时间、修改者、修改描述这些最基本的内容。,版本树,最简单的版本树只有一个分支，就是版本树的枝干；复杂的版本树除了主干外，还可以包含很多的分支，分支可以进一步包含子分支。,5.5 变更控制,5.5.1 变更类型 5.5.2 变更请求管理 5.5.3 变更管理的实施步骤,变更机制,5.5.1 变更类型,功能变更 功能

9、变更是为了增加或者删除某些功能、或者为了完成某个功能的方法而需要的变更；这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和其对软件系统其他部分的影响。 缺陷变更 缺陷修补是为了修复漏洞需要进行的变更。在项目前期，它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。在项目后期，如果发现错误的阶段在造成错误的阶段的后面，则必须遵照标准的变更控制过程来进行。,5.5.2 变更请求管理,变更请求通常分为两个大类： 增强请求：增强请求指系统的新增特征或对系统“预定设计”行为的变更。 缺陷：指存在于一个已交付产品中的异常现象或缺陷。 变更请求管理过程： 变更请求提交 变更请求接收 变

10、更请求评估 变更请求决策 变更请求实现 变更请求验证 变更请求完成,变更请求管理流程,批准变 更请求?,指派给相应的开发人员,5.5.3 变更管理的实施步骤,变更请求提交 缺陷和增强请求通常在请求起源和收集信息类型上不同。 变更请求接收 项目必须建立接收提交的变更请求并进行跟踪的机制。指定接收和处理变更请求的责任人，确认变更请求。 变更请求评估 大多数机构根据请求的类型是缺陷还是增强而使用不同的评估过程。 变更请求决策 决策阶段是当选择实现一个变更请求时所做出的决定，如推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总是以不同方式进行处理。,变更管理的实施步骤,变更请求实现 增强请求实现较

11、之缺陷实现需要更多的设计工作，这是因为增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决方案。 变更请求验证 验证发生在最终测试及文档制作阶段。增强请求的测试通常涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单的验证开发人员的修复是否真正消除了该缺陷。 变更请求完成 完成是变更请求的最终阶段，这可能是完成了一项请求或者决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原有请求者中止这一循环过程。,5.6 软件配置管理系统,5.6.1 软件配置标准 5.6.2 配置管理工具介绍 5.6.3 配置管理工具的选择 5.6.4

12、版本控制工具-svn,软件配置管理系统功能,并行开发系统 修订版管理 版本控制 产品发布管理 建立管理 过程控制 变更请求管理 代码共享,5.6.1 软件配置标准,软件配置标准和指南,5.6.2 软件配置管理工具对比,由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制均十分接近，但由于其定位不同，因此各有特点。,1.早期配置管理工具,CCC、SCCS、RCS 上个世纪七十年代初期加利福

13、利亚大学的Leon Presser教授撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的配置管理工具：CCC，这也是最早的配置管理工具之一。 在软件配置管理工具发展史上，继CCC之后，最具有里程碑式的是两个自由软件：Marc Rochkind 的SCCS (Source Code Control System) 和Walter Tichy 的RCS (Revision Control System)，它们对配置管理工具的发展做出了重大的贡献，直到现在绝大多数配置管理工具基本上都源于它们的设计思想和体系架构。,2.Rational C

14、learCase,Rational 公司是全球最大的软件CASE 工具提供商，现已被IBM收购。也许是受到其拳头产品、可视化建模第一工具Rose 的影响，它开发的配置管理工具ClearCase 也是深受用户的喜爱，是现在应用面最广的企业级、跨平台的配置管理工具之一。 ClearCase提供了比较全面的配置管理支持，其中包括版本控制、工作空间管理、Build管理等，而且开发人员无需针对其改变现有的环境、工具和工作方式。 其最大的缺点就在于其价格不菲，每个客户端用户许可证大约需要几千美金，所以在国内应用群体有限。,ClearCase的特点,1） 版本控制 ClearCase不仅可以对文件、目录、链

15、接进行版本控制，同时还提供了先进的版本分支和归本功能用于支持并行开发。另外，它还支持广泛的文件类型。 2）工作空间管理 可以为开发人员提供私人存储区，同时可以实现成员之间的信息共享，从而为每一位开发人员提供一致、灵活、可重用的工作空间域。 3） Build管理 对ClearCase 控制的数据，既可以使用定制脚本，也可使用本机提供的make 程序。,3.CVS,CVS 是Concurrent Versions System 的缩写，它是在SCCS 和 RCS 的基础上发展起来的。 它是开放源代码软件世界的一个伟大杰作，由于其简单易用、功能强大，跨平台，支持并发版本控制，而且免费，它在全球中小型

16、软件企业中得到了广泛使用。 缺少相应的技术支持，许多问题的解决需要自已寻找资料。,4.Microsoft Visual Source Safe （VSS）,VSS，是微软公司为Visual Studio配套开发的一个小型的配置管理工具，准确来说，它仅能够称得上是一个小型的版本控制软件。VSS的优点在于其与Visual Studio实现了无缝集成，使用简单。提供了历史版本记录、修改控制、文件比较、日志等基本功能。 但其缺点也是十分明显的，只支持Windows平台，不支持并行开发，通过Check out - Modify - Check in的管理方式，一个时间只允许一个人修改代码，而且速度慢、伸

17、缩性差，不支持异地开发。,5.Subversion（SVN）,Subversion 是类似于VSS 和 CVS 的版本管理软件,与CVS相同是开放源码的版本管理系统，它是设计为 CVS 的一个升级产品。 和CVS相比，SVN有一个独立的版本管理文件系统。这一点使得它比CVS更有优势一些。但是相比于CVS有着30年的使用经验 来讲，SVN在某些方面还需要进一步改进。 著名的SourceForge 也于 2006 年初，将 SVN 作为托管项目的另外一个选择，由此可见其前景非常好。,5.6.3 软件配置管理工具的选择,1）功能是否符合实际需求，是否符合团队特点 2）性能是否满意 3）费用是否可以接

18、受 4） 售后服务如何,功能上的要求并行开发支持,在团队协作开发过程中，有两种主要的模式：集体代码权和个体代码权。采用集体代码权模式进行开发时，一段代码可能同时会被多个开发人员同时修改；而采用个体代码权模式进行开发时，每一段代码都始终被一个开发人员独享，别人需要修改时也会通过该开发人员完成。 而配置管理软件针对这一情况，也采用了不同的策略：Copy-Modify-Merge(拷贝、修改、合并) 的并行开发模式、Check out-Modify-Check in（签出、修改、签入）的独占开发模式。在并行开发模式下，开发人员可以并行开发、更改代码。,并行开发支持对比表,功能上的要求异地开发支持,如

19、果开发团队分布在不同的开发地点，就需要对工具的异地开发功能进行仔细的评估了。大多数工具都提供基于Web的界面，用户可以通过浏览器执行配置管理的相关操作，而且有些工具就通过这样的方法来实现对异地开发的支持。这种实现方法有太多的局限性，例如网络（Internet）连接带宽的限制、防火墙以及安全问题等。,异地开发支持对比表,功能上的要求跨平台开发支持,功能上的要求与开发工具的集成性,性能上的要求运行性能,性能上的要求安全性,性能上的要求易用性,价格比较,Rational ClearCase属于企业级配置管理工具软件, 价格较贵。 VSS 是微软打包在Visual Studio开发工具包之中的，显然花

20、费的精力不大，价格也比较便宜，可以做为个人、小项目团队版本控制之用。 CVS与Subversion则是完全免费的开源软件，性能较之企业级配置管理工具差距不大，也是一种不错的选择。,售后服务比较,配置管理工具Subversion介绍,什么是Subversion？,Subversion 是一个自由的、开放源码的版本控制系统。也就是说，它可以管理各个时刻的文件和目录。Subversion 将文件存放在一个中心仓库（repository）中。这个仓库非常类似于一个普通的文件服务器，只是它还可以记录文件和目录曾经做过的每一次变更。这样，我们就可以恢复旧版本中的数据或者是检查数据曾经做过怎样的改动。在这点

21、上，许多人都将版本控制系统比作一种“时间机器”。 Subversion 的仓库可以通过网络来访问，允许不同的用户在不同的计算机上使用。C/S架构软件,搭建SVN服务器 svn-1.4.0-setup.exe服务器端 TortoiseSVN客户端,SVN的基本工作思路,在一台服务器上建立一个仓库，仓库里可以存放许多不同项目的源程序。 由仓库管理员统一管理这些源程序这样，就好象只有一个人在修改文件一样避免了冲突每个用户在使用仓库之前，首先要把仓库里的项目文件下载到本地。 用户做的任何修改首先都是在本地进行，然后用 svn 命令进行提交，从而更改服务器端内容 这样就可以做到跟踪文件变化，冲突控制等等

22、,客户端TortoiseSVN,TortoiseSVN是Subversion版本控制系统的一个免费开源客户端，它适用于Windows系统。,TortoiseSVN的特性,外壳集成 TortoiseSVN与Windows外壳（例如资源管理器）无缝集成，你可以保持在熟悉的工具上工作，不需要在每次使用版本控制功能时切换应用程序。 并且你不一定必须使用Windows资源管理器，TortoiseSVN的右键菜单可以工作在其他文件管理器，以及文件/打开对话框等标准的Windows应用程序中。,TortoiseSVN的特性（续）,图标覆盖 每个版本化的文件和目录的状态使用小的覆盖图标表示，可以让你立刻看出工

23、作拷贝的状态,TortoiseSVN的特性（续）,Subversion命令的简便访问 所有的Subversion命令存在于资源管理器的右键菜单，TortoiseSVN在那里添加子菜单。,TortoiseSVN的特性（续）,Subversion命令的简便访问 所有的Subversion命令存在于资源管理器的右键菜单，TortoiseSVN在那里添加子菜单。,1-1,1-2,1-3 修改,1-4,2-1,2-2 修改,2-3,2-1 如果从 未检出过,课堂案例1：,使用SVN进行版本控制的步骤,1.导入模块(check in/import model) 在服务器端的仓库里面建立起对应项目的模块。

24、2.检出模块(check out) 在客户端建立起工作目录，之后的所有编码都是在工作目录的基础上进行的 3.同步(update) 多人合作时，每次修改文件之前，保持文件是最新的，因此要从服务器上下载最新版本文件进行修改。执行update操作 4.修改提交(commit) 修改之后，要将修改的文件上传服务器。执行commit操作,演示操作,请注意观看,课堂小练习,角色扮演游戏（RPG） 挑选2位同学与老师共同完成。 演示： 修改同一文件：text.txt 第一次修改输入：自己的姓名，然后回车。 第二次修改输入：Hello,姓名！然后回车,步骤： 1.老师进行check in（import）操作，

25、导入项目text.txt 2.老师进行check out操作，检出text.txt 3.由老师修改text.txt后，执行提交（commit）操作 4.同学A进行check out操作，检出text.txt 5.由同学A修改text.txt后，执行提交（commit）操作。,6.同学B进行check out操作，检出text.txt 7.由同学B修改text.txt后，执行提交（commit）操作。 8.由老师进行更新（updata）操作，更新text.txt 9.由老师修改text.txt后，执行提交（commit）操作 10.同学A进行更新（updata）操作，检出text.txt 11.

26、由同学A修改text.txt后，执行提交（commit）操作。 12.同学B进行更新（updata操作，检出text.txt 13.由同学B修改text.txt后，执行提交（commit）操作。 14.由老师进行版本查看,任务2：第一部分,按照 SVN客户端 从FTP上下载客户端进行安装，注意操作系统的区别,任务2：第二部分 SVN小组实践,按照任务单上的提示，进行小组的任务实践。共同修改文档“会议纪要”,目的：通过实践掌握简单的配置管理操作：导入、导出、检出、提交、更新 方法步骤： 1.全组人员在一个空文件夹里面执行检出（checkout），url- svn:24SVN

27、这里替换成小组编号，如T1-1。,2.小组内，由组长分配顺序，第一个同学修改文件（可以写入一些话），会议记录.doc，然后点提交（commit）。用户名和密码参看SVN权限分配表,3.第二个同学，先点击“会议记录.doc”右键，选择更新（update），然后打开“会议记录.doc”，修改一下可以写入一些话）， 然后点提交（commit） 4.以此类推，全组全部进行完成后， 报告老师，进行检查。,出现问题,如果第二个同学在修改文件之前，忘记了做更新（update），会出现什么情况呢？,但是你选择更新（update）之后呢？,出现冲突,冲突表示,解决冲突,有时当你从版本库中更新你的文件时，会有冲突

28、。冲突出现的原因是两个开发人员修改了文件中相同的几行。由于Subversion不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串 revision,解决冲突（续）,对于每个冲突的文件Subversion在你的目录下放置了三个文件： filename.ext.mine 这是你的文件，在你更新你的工作复本之前存在于你的的工作复本中也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。 filename.ext.rOLDREV 这是在你更新你的工作复本之前的基础版本(BASE revision)文件。也就是说，它是在你做最后修改

29、之前所检出的文件。 filename.ext.rNEWREV 这个文件是当你更新你的工作复本时，你的Subversion客户端从服务器接收到的。这个文件对应与版本库中的最新版本。,解决冲突（续）,你可以通过TortoiseSVN 编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。 然后，执行命令TortoiseSVN 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。 如果你的二进制

30、文件有冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。 如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。 你可以右击父文件夹，选择TortoiseSVN 已解决.，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。,只需要修改该文档，然后点右键，选已解决（resolved），然后提交（commit）即可。 注意： 在配置管理中，冲突的解决需

31、要授权。,任务2：第三部分,小组制造一次冲突，然后解决它。,任务2：第4部分Subversion+TortoiseSVN的使用,下载软件 安装服务器端软件 svn-1.6.5-setup.exe,创建仓库（服务器端）,在服务器的本地硬盘上创建一个新文件夹，最好以英文命名，并保持文件夹为空 点鼠标右键选择“在此创建版本库” 可以看到会生成若干个文件夹,密码分配,创建仓库后，在conf文件夹下可以看到三个文件：,1.打开svnserve.conf,找到这个,把password-db前面的#号去掉,2.打开passwd，找到,把#开头的两行去掉， 加上 aaa = 123 即用户名为aaa ，密码为

32、123,启动服务（服务器端）,在服务器端启动服务，之后所有的客户端均可以访问 在命令行模式中找到Subversion的安装路径中的bin目录 使用命令svnserve d r 仓库路径仓库名 例如 svnserve d r d:svn1 保持命令行窗口不被关闭,任务2：第4部分,安装服务器端软件，svn-1.4.0-setup.exe 每个小组创建一个仓库 修改仓库的密码配置文件，分配一个用户名为 admin，密码为admin的账号 小组选出SQA人员，进行导入操作 然后按照前面的步骤，小组完成一轮的合作。,TortoiseSVN进阶查看差异,可以使用右键菜单中的“查看与上一版本差异”命令进行差异查看 2. 在项目开发中，有一个很常用的要求就是查看更改。可能是你要求查看同一文件的两个版本之间的差异，或者是查看两个独立的文件的差异。TortoiseSVN自带了一个工具叫TortoiseMerge用来查看文本文件的差异。也有一个叫TortoiseIDiff的工具来比较图像文件的差异。当然，你可以根据你自己的喜好来选择比较差异的工具。,TortoiseSVN进阶查看任意版本,如果你想查看以往版本内容，可以使用该命令,1,2,填入你想要查看的版本号,TortoiseSVN进阶生成版