配置管理基础知识

配置管理基础知识配置管理基础知识配置管理是一门研究变化的学科，没有了变化也就没有配置管理，配置管理管理的是变化，它的核心就在于变更控制。配置管理就是通过对软件生命周期不同时间点上的软件配置项进行标识，并对这些被标识的软件配置项的更改进行系统控制，从而保证软件产品的完整性、一致性和可追溯性的活动。有效的变更控制可以降低由于变化对软件造成的负面影响，可以提高工作效率、缩短产品开发周期。配置管理－配置项配置是指一个产品在生命周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素成为该产品配置中的一个配置项（CI）。配置项的特点：作为一个整体纳入配置管理的产品配置数据影响产品质量的在生命周期中有可能改变的配置管理－配置项配置项种类：计划（包括各类产品相关计划，如开发计划、配置管理计划、测试计划等）需求文档（包括各类需求规格、需求分析报告、需求更改记录等）设计文档（包括给类过程设计文档，如概要设计、详细设计）程序代码（所有开发的源代码，包括各类支持数据，二进制文件，第三方代码）测试（包括测试代码、测试用例设计、测试报告等）配置管理－配置项工具（如语言开发工具、编译和建立工具、测试工具配置管理工具）用户文档（包括用户手册、安装指南等）目标代码（目标代码、可执行代码等）运行环境（系统运行平台、环境设置要求等）安装盘（包含安装到运行平台上的系统、安装说明、发布说明、运行环境要求等）配置管理－配置项配置项状态分为：计划：配置项被标识后，写入配置项清单管理和受控：CMO将该配置项纳入配置库，打上标签已基线化：配置项经过review-修改-QA审计-批准签发后，CMO将该配置项打上标签受控：对于非由产品直接改动的配置项（如：用户提供的软件，购买的工具等），CMO将配置项放入配置库或者维护配置项的版本信息，以保证该配置项是可控和可跟踪的。配置管理－基线基线就是配置项在其生命周期的不同时间点上通过Review而进入正受控的一种状态。形成基线的这个过程被称为“基线化”。基线有三个特点：通过正式的review过程建立。基线存在于配置库中，基线的变更由CCB控制。基线是进一步开发和修改的基准。配置管理－CCBCCB：由PDT开发代表指定负责评估和批准对配置项的更改确保批准后的更改的正确实施CCB包括哪些人？PDT开发代表，PM，QA，CMO，TC，以及其它确定的人员配置管理－基线每个基线都将接受配置管理的严格控制，对它的修改将严格按照变更控制要求的过程进行。在一个开发阶段结束时，上一基线加上增加或修改的基线内容形成下一基线，这就是“基线管理”的过程。单项基线就是针对每个配置项建立的基线，每个配置项在经过review－修改－QA审计－批准签发－CMO打标签后就建立了自己的单项基线。配置管理－基线项目基线是指在产品开发过程中的某个阶段点，将各个已单项基线化的配置项作为一个整体进行基线化后形成的基线。项目阶段结束时，由项目经理向项目CMO提出基线化申请。项目CMO通过给所有组成项目基线的配置项打标签来实现基线化。基线化后，项目CMO还须以配置状态报告的方式通告相关人员和受影响的组。配置项形成基线或发生基线变更后，需要由项目组CMO进行配置状态发布，通知项目组成员及项目利益相关人。发布内容包括所有发生基线变化的配置项的名称、版本及存放位置。规范流程－命名规范公共交付件命名规范：不随发布版本变化：平台名称++平台V版本号++文档类型如：ConplatV100支持标准随发布版本变化：平台名称++平台D版本号++文档类型如：ConplatV100R001B01D001版本发布说明书规范流程－命名规范项目组交付件命名规范：平台名称++平台D版本号++项目组标识＋”组”＋文档类型如：ConplatV100R001B01D001XXX组PC-LINT报告按模块划分交付件命名规范：平台名称++平台V版本号++模块名称＋文档类型如：ConplatV100Syslog规格列表规范流程－命名规范开发项目交付件命名规范：开发项目命名：平台名称+“”+平台R版本号+“”＋模块名称＋特性描述+“开发/移植/增强”+“项目”如：ConplatV100R001IPS开发项目开发项目文档命名：项目名称++文档类型如：ConplatV100R001XXX项目命令手册规范流程－配置项存放代码：统一存放于，其中的trunk存放主线版本，tags存放标签版本，branches存放特性分支，branches_BugFix存放代码修改分支。文档：统一存放于，具体文档按照目录分类放置。版本：统一存放于？（服务器待定），该目录下包含两个文件夹，“发布版本”与“验收版本”。每次版本发布，由平台CMO将发布版本按版本号放置于“发布版本”；“验收版本”只有各组CMO有写权限，存放结构为“验收版本”－特性名称－放置日期－版本，不允许覆盖更新。TC从该目录下取验收版本进行测试。其它：非以上三项，可放置于？（服务器待定），包括但不限于工具类，未正式发布类等。规范流程－分支策略主线分支：Conplat平台拥有一个主线分支，只有平台CMO有修改权限，开发人员修改问题或者合入特性，需要使用单独的分支。非同步问题单修改分支：每次版本发布后，平台CMO从主线版本拉出问题单修改分支，平台开发人员均在该分支上进行非同步单的问题修改。合入主线前要求编译验证通过。该分支的生命期从版本发布到下一个版本封版。同步问题单分支：每个同步单一个单独分支，以同步单号命名，位于。同步问题单由发起组负责确保分支的编译验证通过，版本经理负责确定版本要合入的同步问题单列表。规范流程－分支策略版本验证分支：封版后由平台CMO从主线上拉出，位于，合入验证问题，保证编译通过后，版本发布前，由平台CMO合入主线。给各项目组CMO开修改权限。该分支的生命期从版本封版到本版本发布。特性分支：新特性每个特性一个分支，位于。特性分支中，如果需要其他项目组配合修改，需要给其他项目组开同步问题单。新特性合入时要求特性负责人严格按《Conplat特性合版本Checklist》操作。工具使用——版本控制“锁定－修改－解锁”方案工具使用——版本控制“复制－修改－合并”方案工具使用——访问方式样式存取方式file:///直接从本地磁盘上访问仓库http://通过WebDAV协议访问Apache服务器，而访问仓库https://和http://相同，但使用SSL来作加密svn://通过自定义的协议访问一个svnserve服务器svn+ssh://和svn://相同，但通过一个SSH通道来使用工具使用——版本号在SVN中，每一次提交都被作为一个原子事务来对待。一个svncommit操作可以将任意数量的文件和目录的修改发布作为一个单独的原子事务来处理。每当仓库接受一次提交，仓库中的文件系统目录都会创建一种新的状态，叫做一个修订本。每一个修订本都被赋予一个唯一的自然数，并且每一个修订本的数字都比前一个要大。刚刚建立的仓库的初始的版本是0，只包含一个空的根目录。Subversion的修订版编号是针对整个目录树的，而不是某一个独立的文件。在完成向仓库的提交之后，刚刚提交的文件和目录就拥有了最新的修订版编号，而其他文件没有。工具使用——基本操作check-out（检出）：获得仓库的一个私有工作拷贝update（更新）commit（提交）：见前页工具使用——基本操作Commit时的四种情况：本地未修改，且与仓库中最新版本同：commit与update操作均不作任何事情本地已修改，且与仓库中最新版本同：commit成功提交，update不作事情本地未修改，且与仓库中最新版本异：commit不作事情，update取最新版本到工作拷贝本地已修改，且与仓库中最新版本异：commit将会失败，首先需要update，如果svnupdate命令自动合并本地和公共修改出现冲突，会要求用户解决杭州迪普科技有限公司