配置管理规范

配置管理规范对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：1、配置项及其命名规则；2、配置库文件目录结构；3、角色和权限定义；4、配置项变更流程；5、配置项发布；6、基线定义和基线变更。配置项及其命名规则对我们的项目来说，配置项需要包括以下的内容：1、项目管理过程文档；a)项目任务书；b)项目计划；c)项目周报；d)个人日报和周报；e)项目会议纪要；f)培训记录和培训文档；2、QA过程文档；a)QA不符合报告；b)QA周报；c)评审记录；3、工作产品a)需求文档；b)设计文档；c)代码；d)测试文档；e)软件说明书和手册；4、项目中使用的第三方产品上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发生遗漏；3、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，但在我们以前的项目中，确实还遇见过。一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。配置项的命名包括两个方面的内容：1、配置项标识：在我们的项目中，一般使用“项目名_配置类别_配置项特殊标识”来命名。下表列出了我们在项目中使用的配置类别命名：配置类别命名配置类别命名项目任务书PT项目计划PP项目周报PR个人日报和周报PER项目会议纪要PM培训记录和培训文档TRQA不符合报告QAPQA周报QAR评审记录RR需求文档REQ设计文档DD代码CODE测试文档TD软件说明书和手册MAN项目中使用的第三方产品PART3配置项命名中的“配置项特殊标识”根据配置类别的不同而不同。比如，对“设计文档”，如果细分的话，可以分为“概要设计”和“详细设计”；对“代码”，可以按照模块来命名配置项。2、配置项版本命名：配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。一般说来，配置库至少包括个人工作区、受控库、发布区三个部分，在我们的项目中，所有的配置项都保存在一个VSS库中，对这三个部分的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的。因此，我们配置项的版本命名规定如下：a)基线版本：按照基线的状态，我们这个项目中的基线有两个方面：一是作为里程碑的基线；另一个是模块的阶段性成果基线（对工作产品而言），由模块的负责人确定。里程碑基线――对我们的项目来说，采用的是迭代的开发过程，以一个迭代过程为例，分为需求、概要设计、详细设计、代码实现、单元测试、集成测试、系统测试七个阶段，每个阶段都需要产生里程碑。对每个里程碑都有明确的标识标明当前状态。阶段性成果基线――阶段性成果主要体现在代码过程中，比如代码进行到一个阶段，开发组长认为代码的这个状态可以保留，就可以确定为一个代码基线。这种基线一般不需要通过评审等正式手段来确定，但也必须有相应的验证手段；比如在我们的项目中，在代码阶段，确定代码基线的责任人是开发组长，但开发组长必须保证代码基线符合一定的条件。b)其他版本：除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。而产品的版本则需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在VSS库上用Label来标识，同时维护一张描述产品版本和模块版本关系的矩阵图便于追踪。配置库目录结构在确定了配置项之后，就可以确定配置库的目录结构了。配置库的目录结构直接关系到配置管理的工作量和使用的方便性，所以需要根据自己的需要确定一个合理的结构。在确定配置管理库目录结构的时候，我们曾经考虑过两种产品目录结构的方式：一种是按照模块划分，在模块下再划分诸如设计文档、代码等目录；另一种方式是按照产品类型划分，例如首先是文档、代码，然后在其下按照模块划分。这两种方式都有自己的优点，最终我们还是选择了前一种划分方式，一方面是考虑便于进行权限的分配，另一方面是考虑到便于将同一模块的所有内容组织起来进行版本的管理。下表是我们在实际中采用的配置库结构（部分）：第一级第二级第三级第四级说明M管理类文档PM项目管理0－Init初始阶段PCPTRPN1－Plan计划阶段…………………………QA0－PPQAP质量保证计划…………………………P项目产品0－Req需求阶段0－CRS客户需求1－SRS需求分析文档2－RTM需求跟踪矩阵1－Des设计阶段0－HLD概要设计1－DBD数据库设计2－Imp实现/编码阶段0－Module1模块10－COD代码1－DDS详细设计2－HLD概要设计3－UNT单元测试…………………………3－Test0－Int集成测试1－Syt系统测试…………………………4－Man手册…………………………5－Others其他…………………………从这里的配置库结构中可以看到，我们在最上层将配置项分为管理类和产品类：管理类中的项目管理部分基本是按照初始－计划－执行－收尾四个阶段来划分。在项目产品类别中，我们按照需求－设计－实现－测试四个阶段划分目录，在实现阶段，为每个模块划分了代码、详细设计、概要设计和单元测试四个目录，需要说明的是，在第三层中有一个HLD的目录，在模块下同样有一个HLD的目录，在我们的实际工作中，第三层的HLD目录用来存放系统级别的概要设计文档，而模块下的HLD目录用来存放模块级别的概要设计文档。当然，这里的配置库结构仅仅起到了示范作用，在实际使用中，可以根据自己的需要修改。例如，在Module的级别上可以增加一个SubSystem的层，便于在产品集成时更加方便。角色定义及权限分配角色是配置管理流程的执行者和参与者，定义明确的角色有利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色由一个人担任，但还是应该保留角色的定义。下面是该项目中我们的角色定义：配置管理员整个配置管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。开发经理开发经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。开发经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；开发组长开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；开发工程师开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；测试组长测试组长负责组织测试，给出测试计划和测试方案，并核定测试报告。测试组长对所有目录都有读取权限，对测试目录有读写权限；测试工程师测试工程师负责完成测试工作，包括测试用例开发和测试执行，测试报告编写。测试工程师对自己负责的模块有读取权限，对测试用例目录有读写权限。QA工程师QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。〔说明〕除配置管理员外，其他所有成员都没有Destroy目录和文件的权限，这是为了防止误删除操作带来不可挽回的损失。如果需要对目录进行Destroy操作，必须由配置管理员进行。配置项变更流程我们所说的配置项变更流程主要是针对配置项发生变化的控制，在我们的项目中分为两个部分，首先是对配置项新建、检入（CheckIn）和检出（CheckOut）的规定；其次是对入库的文件类型和大小的规定：新建、检入、检出及破坏1、新建：即Add，除特殊情况外，一般不规定由谁来新建（只要有权限即可），但尽量指定每个project只有一人负责新建。2、检入：即checkin，检入频率规定如下：i.在代码编写前，至少每周一次ii.代码编写阶段，至少每天一次iii.测试阶段以后，根据代码、文档的变动，只要当天有变动就要检入一次。iv.为配合检查、备份工作，需在检查备份周期前全部checkin(不保持checkout)并退出登录。详见“检查及备份”部分3、检出：即checkout。原则上只对要修改的文档方可检出。4、破坏（Destroy）：一般情况不可以破坏文件、目录。5、如果是误操作，则可在一天内提交管理员处6、如果超过一天，则需要由项目经理同意，且管理员破坏前要备份。7、各阶段环境职责环境阶段负责人职责公司内部编码前开发人员每周及需要评审前checkin工作产品（包括版本发布说明）到SVN上开发组长每周SCM人员每周统计编码开发人员每天checkin工作产品（包括版本发布说明）到SVN上开发组长每周检查经理及组长抽查及走读SCM人员每周统计，检查代码风格测试开发人员每天checkin工作产品到SVN上（如当天没有修改可以不进行checkin）以LABEL形式提交一个新版本给测试，附带版本发布说明测试人员对测试完成后的程序打LABEL发布后开发人员将新版本checkin到SVN,打测试LABEL,向测试人员提交申请测试人员对测试完成后的程序打LABELSCM人员对变更做好控制和记录，并发布现场开发负责人将发布后的产版本更新至现场，或指定人员进行公司外部编码现场开发负责人在无法通过sos连到公司SVN的情况下，需要在现场建立配置库（文件方式或SVN等），做到基本的版本控制和备份。每周至少通过SOS提交一次至公司的SVN库中。现场开发人员每天checkin工作产品到现场配置库（包括版本发布说明）。SCM人员做好督促和监督工作，每周将现场开发负责人提交的现场版本更新到公司配置库（SVN）。测试现场开发人员每天checkin工作产品到现场配置库（如当天没有修改可以不进行checkin）。如已经回公司则每天checkin工作产品到公司配置库SVN（如当天没有修改可以不进行checkin）。每周通过SOS提交一个新版本给测试，打测试LABEL,附带版本发布说明(如没有更新可不提交)对测试完成后的程序打LABELSCM人员做好督促和监督工作发布后现场调试现场维护现场开发负责人在无法通过sos连到公司SVN的情况下，需要在现场建立配置库（文件方式或SVN等），做到基本的版本控制和备份。每周至少通过SOS提交一次至公司的SVN库中。通过LABEL提交测试版本现场开发人员对修改后的版本通过SOScheckin新版本到SVN,打测试LABEL,向测试人员提交申请（由修改至提交测试人员不应超过三天）测试人员对测试完成后的程序打LABELSCM人员对变更做好控制和记录，并发布做好督促和监督现场提交更新版本到SVN。关于SVN库内存放文件类型及大小的规定1、文件名及目录规定：以英文名字命名2、文件大小规定：最大不超过20M3、允许类型：4、表2.1中提至的文