配置管理基础知识.ppt

1、配置管理基础知识,1. 基础知识 2. 规范流程 3. SVN工具使用,配置管理基础知识,配置管理是一门研究变化的学科，没有了变化也就没有配置管理，配置管理管理的是变化，它的核心就在于变更控制。 配置管理就是通过对软件生命周期不同时间点上的软件配置项进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而保证软件产品的完整性、一致性和可追溯性的活动。 有效的变更控制可以降低由于变化对软件造成的负面影响，可以提高工作效率、缩短产品开发周期。,配置管理配置项,配置是指一个产品在生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素成为该

2、产品配置中的一个配置项（CI）。 配置项的特点： 作为一个整体纳入配置管理的产品配置数据 影响产品质量的 在生命周期中有可能改变的,配置管理配置项,配置项种类： 计划（包括各类产品相关计划，如开发计划、配置管理计划、测试计划等） 需求文档（包括各类需求规格、需求分析报告、需求更改记录等） 设计文档（包括给类过程设计文档，如概要设计、详细设计） 程序代码（所有开发的源代码，包括各类支持数据，二进制文件，第三方代码） 测试（包括测试代码、测试用例设计、测试报告等）,配置管理配置项,工具（如语言开发工具、编译和建立工具、测试工具配置管理工具） 用户文档（包括用户手册、安装指南等） 目标代码（目标代码

3、、可执行代码等） 运行环境（系统运行平台、环境设置要求等） 安装盘（包含安装到运行平台上的系统、安装说明、发布说明、运行环境要求等）,配置管理配置项,配置项状态分为： 计划：配置项被标识后，写入配置项清单 管理和受控：CMO将该配置项纳入配置库，打上标签 已基线化：配置项经过review-修改-QA审计-批准签发后，CMO将该配置项打上标签 受控：对于非由产品直接改动的配置项（如：用户提供的软件，购买的工具等）， CMO将配置项放入配置库或者维护配置项的版本信息，以保证该配置项是可控和可跟踪的。,配置管理基线,基线就是配置项在其生命周期的不同时间点上通过Review而进入正受控的一种状态。形成

4、基线的这个过程被称为“基线化”。 基线有三个特点： 通过正式的review过程建立。 基线存在于配置库中，基线的变更由CCB控制。 基线是进一步开发和修改的基准。,配置管理CCB,CCB： 由PDT开发代表指定 负责评估和批准对配置项的更改 确保批准后的更改的正确实施 CCB包括哪些人？ PDT开发代表，PM，QA，CMO，TC，以及其它确定的人员,配置管理基线,每个基线都将接受配置管理的严格控制，对它的修改将严格按照变更控制要求的过程进行。在一个开发阶段结束时，上一基线加上增加或修改的基线内容形成下一基线，这就是“基线管理”的过程。 单项基线就是针对每个配置项建立的基线，每个配置项在经过 r

5、eview修改QA审计批准签发CMO打标签后就建立了自己的单项基线。,配置管理基线,项目基线是指在产品开发过程中的某个阶段点，将各个已单项基线化的配置项作为一个整体进行基线化后形成的基线。 项目阶段结束时，由项目经理向项目CMO提出基线化申请。项目CMO通过给所有组成项目基线的配置项打标签来实现基线化。基线化后，项目CMO还须以配置状态报告的方式通告相关人员和受影响的组。 配置项形成基线或发生基线变更后，需要由项目组CMO进行配置状态发布，通知项目组成员及项目利益相关人。 发布内容包括所有发生基线变化的配置项的名称、版本及存放位置。,1. 基础知识 2. 规范流程 3. SVN工具使用,规范流

6、程命名规范,公共交付件命名规范： 不随发布版本变化： + + + 如：Conplat V100 支持标准 随发布版本变化： + + + 如：Conplat V100R001B01D001 版本发布说明书,规范流程命名规范,项目组交付件命名规范： + + +”组” 如： Conplat V100R001B01D001 XXX组PC-LINT报告 按模块划分交付件命名规范： + + + 如： Conplat V100 Syslog规格列表,规范流程命名规范,开发项目交付件命名规范： 开发项目命名： +“ ”+“ ”+ “开发/移植/增强” + “项目” 如： Conplat V100R001 IP

7、S开发项目 开发项目文档命名： + + 如： Conplat V100R001 XXX项目 命令手册,规范流程配置项存放,代码：统一存放于http:/xxx.xxx.xxx.xxx/conplat_code_vob/，其中的trunk存放主线版本，tags存放标签版本，branches存放特性分支，branches_BugFix存放代码修改分支。 文档：统一存放于http:/xxx.xxx.xxx.xxx/conplat_doc_vob/ ，具体文档按照目录分类放置。 版本：统一存放于？（服务器待定），该目录下包含两个文件夹，“发布版本”与“验收版本”。每次版本发布，由平台CMO将发布版本按版

8、本号放置于“发布版本”；“验收版本”只有各组CMO有写权限，存放结构为“验收版本”特性名称放置日期版本，不允许覆盖更新。TC从该目录下取验收版本进行测试。 其它：非以上三项，可放置于？（服务器待定），包括但不限于工具类，未正式发布类等。,规范流程分支策略,主线分支：Conplat平台拥有一个主线分支http:/xxx.xxx.xxx.xxx/conplat_code_vob/trunk，只有平台CMO有修改权限，开发人员修改问题或者合入特性，需要使用单独的分支。 非同步问题单修改分支：每次版本发布后，平台CMO从主线版本拉出问题单修改分支http:/xxx.xxx.xxx.xxx/conpla

9、t_code_vob/branches_BugFix，平台开发人员均在该分支上进行非同步单的问题修改。合入主线前要求编译验证通过。该分支的生命期从版本发布到下一个版本封版。 同步问题单分支：每个同步单一个单独分支，以同步单号命名，位于http:/xxx.xxx.xxx.xxx/conplat_code_vob/branches_BugFix。同步问题单由发起组负责确保分支的编译验证通过，版本经理负责确定版本要合入的同步问题单列表。,规范流程分支策略,版本验证分支：封版后由平台CMO从主线上拉出，位于http:/xxx.xxx.xxx.xxx/conplat_code_vob/branches_

10、BugFix，合入验证问题，保证编译通过后，版本发布前，由平台CMO合入主线。给各项目组CMO开修改权限。该分支的生命期从版本封版到本版本发布。 特性分支：新特性每个特性一个分支，位于http:/xxx.xxx.xxx.xxx/conplat_code_vob/branches。特性分支中，如果需要其他项目组配合修改，需要给其他项目组开同步问题单。新特性合入时要求特性负责人严格按Conplat 特性合版本Checklist操作。,1. 基础知识 2. 规范流程 3. SVN工具使用,SVN工具使用版本控制,“锁定修改解锁”方案,SVN工具使用版本控制,“复制修改合并”方案,SVN工具使用访问方

11、式,样式 存取方式 file:/ 直接从本地磁盘上访问仓库 http:/ 通过 WebDAV 协议访问 Apache 服务器，而访问仓库 https:/ 和 http:/ 相同，但使用 SSL 来作加密 svn:/ 通过自定义的协议访问一个 svnserve 服务器 svn+ssh:/ 和 svn:/ 相同，但通过一个 SSH 通道来使用,SVN工具使用版本号,在SVN中，每一次提交都被作为一个原子事务来对待 。 一个 svn commit 操作可以将任意数量的文件和目录的修改发布作为一个单独的原子事务来处理 。 每当仓库接受一次提交，仓库中的文件系统目录都会创建一种新的状态，叫做一个修订本。 每一个修订本都被赋予一个唯一的自然数，并且每一个修订本的数字都比前一个要大。刚刚建立的仓库的初始的版本是 0 ，只包含一个空的根目录。 Subversion 的修订版编号是针对整个目录树的，而不是某一个独立的文件 。 在完成向仓库的提交之后，刚刚提交的文件和目录就拥有了最新的修订版编号，而其他文件没有。,SVN工具使用基本操作,check-out（检出）：获得仓库的一个私有工作拷贝 update（更新） commit（提交）：见前页,SVN工具使用基本操作,Commit时的四种情况： 本地未修改，且与仓库中最新版