产品研发配置管理规范V10.docx

1、产品研发配置管理规范V10创格科技软件研发（仅限内部使用）配置管理规范序号版本编号修订内容修订人批准人发布时间11.0创格科技软件研发配置管理规范2013年3月5日2013年3月1关于本文档1.1内容说明本文从整体上介绍了产品研发配置管理规范，说明了在配置管理活动中需要遵循的各种管理流程和规范，包括文档管理、代码管理、基线管理等。1.2文档目的通过学习使用本文档及引用的其它管理规范，达到如下目的：A、统一定义配置管理规范；B、根据管理规范要求来定义各信息体系的配置管理活动，确保各配置项正确的标识及存取；C、保证各信息体系基线配置项的更改受控，维护软件产品完整性和可追溯性。1.3术语名称描述备注

2、配置项凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：一是属于产品组成的工作成果，如源代码和需求设计文档。二是管理过程中产生的文档，如计划和报告等。Configuration Item，CI基线由一组经过正式评审的配置项组成，这些配置项构成了一个相对稳定的逻辑实体，每个基线都是其下一步开发的出发点和参考点。基线通常对于开发过程中的里程碑（Milestone）。Baseline存储库在配置管理工具（如SVN）中建立的配置项存储空间及目录。利用工具可以对存储库进行版本、基线、用户和授权等管理功能。Repository2配置管理基本定义2.1角色与职责编号角色职责1配置管理员（SCM

3、）配置管理部成员，负责存储库的创建、代码版本管理、授权管理和配置审计。2项目经理PM申请存储库、为存储库使用人员审批权限，汇报用户及权限变更情况。3产品CMO每个产品线的兼职人员，执行产品文档库、基线库维护工作。4项目团队成员使用存储库存取成果物，对于产品基线库有只读权限。5其它管理或支持人员对存储库进行权限申请，并获得存储库负责人的审批，由配置管理员授权后，可以使用该产品存储库。2.2产品与版本每个产品由产品设计团队根据产品规划，确定不同的产品发布版本；每个产品需要建立一个产品文档库，并在文档库中建立一个基线存储目录；每个发布版本以项目的形式组织开发，配置管理以文档基线和代码分支的方式配合产

4、品的版本管理。每个版本（项目）在该产品对应的系统代码库中对应一个分支，每次发布对应一个分支。2.3配置项凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：一是属于产品组成的工作成果，如源代码和需求设计文档。二是管理过程中产生的文档，如项目计划等。每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。根据研发体系要求，根据产品及项目研发活动，如下产品成果物和管理文档必须纳入文档库进行管理，并在正式评审后存入基线库进行管理。编号文件说明1产品定义说明书及评审报告2用户研究报告3项目里

5、程碑计划4业务需求模型需求建模的的原文档5业务需求说明书及评审报告6产品需求说明书及评审报告7交互设计原型（Axure）及评审报告8视觉设计原型、设计规范及评审报告9概要设计模型10概要设计说明书及评审报告11测试方案及评审报告12详细设计模型文件13详细设计文档及评审报告14测试用例及测试初始化数据15测试报告16发布版本客户端类产品17用户手册2.4基线在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了配置项

6、的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。2.5存储库配置管理中设置产品文档库、产品基线库和系统代码库。2.5.1产品文档库产品文档库以产品角度，划分目录层级和分类，放置产品研发中的文档。包括产品定义、需求分析、系统涉及、开发、测试验证、发布和运维生命周期各个阶段。产品文档库目录分为两大类，第一类是产品类，这类目录主要用于记录产品生命周

7、期内的各类文档。第二类是项目类的，该类目录主要用于存储该产品在各个版本的项目研发中需要记录的各类文档。产品文档库设置请参考文档产品文档库目录及使用说明，该文档在各产品文档库根目录下。2.5.2产品基线库需要对每个版本确认一个基线，每个基线在SVN库中以目录方式体现。基线库目录结构如下。2.5.3系统代码库代码库申请按照系统的划分，一个系统对应一个代码库。代码库使用分支、版本和Trunk进行管理。新建库后由配置管理员对目录进行初始化，初始目录结构如下： 目录名称目录说明备注branches分支目录，当前开发的代码和分支开发人员读写权限tags标签目录，每一次文档（上线）版本的代码镜像（copy）

8、，基线化操作目录。打tag操作由项目cmo进行trunk主干目录，代码始终与生产环境的保持一致，每次发布生产都要进行更新。合并trunk操作由配置管理员进行3配置管理流程配置管理贯穿在整个软件产品生命周期中，一个标准的配置管理对于整个研发流程起到很重要的作用。3.1配置库用户管理3.1.1用户注册需要使用SVN存储库的用户，需要先在系统内进行用户注册。3.1.2用户权限申请 项目组成员对产品文档库和代码文档库权限申请，由项目经理将申请表单发给SCM统一添加。其它用户申请某产品配置库权限，需依据工作范围和职责申请，禁止跨权申请。除配置管理员外，不允许用户拥有所有库目录操作权限。管理人员原则上不允

9、许申请代码库权限。 3.1.3权限注销项目结束时收回项目组成员对产品文档库权限，请项目经理及时告知。产品经理、产品分析员、技术经理等产品相关人员可以保留对文档库的使用权限。SIT测试封版时收回代码库可写权限，项目结束时，收回项目组临时人员可读权限。也就是只保留维护人员可读权限。产品生命周期内有离职、离场、调走人员，请产品负责人及时反馈给配置管理组进行权限的注销，否则出现由此造成的问题，由产品负责人承担；项目组中有人员调动、离职、离场等需要(产品库和代码库)回收权限的情况请项目经理及时反馈给配置管理组进行权限注销和调整，否则出现由此造成的问题，由项目经理承担。3.2配置库申请3.2.1产品文档库

10、申请产品文档库在产品立项结束后，由项目经理填写产品文档库申请表.doc，向SCM进行申请。SCM审核后，依据产品文档库目录结构，创建产品文档库和基线库。3.2.2代码库申请新系统代码库的申请需要在概要设计结束后，由技术经理填写系统代码库申请表.doc，向SCM进行申请。由SCM审核后，创建系统代码库，并将代码库SVN地址反馈给技术经理。3.3文档基线及变更管理在项目研发每个里程碑结束时，为该阶段成果物建立基线，由产品CMO将该里程碑成果物放入基线库。操作人员进行登记产品文档基线版本说明.xls，维护基线变更报告，同时将基线变更内容发送邮件通知项目组团队成员，抄送配置管理员和开发管理顾问。项目组

11、团队后阶段工作必须依据基线库中前阶段成果物，不得使用外部其它需求，如果有变更，需要由变更者提出申请，走需求变更流程。当需要对基线文档进行变更时，必须走变更流程。详细参考产品研发需求管理规范.docx。3.4代码版本管理3.4.1申请分支在原有系统代码库优化代码，必须申请新的分支；新的分支申请，由技术经理在确定发布版本后申请；申请时需提交该分支可读写人员列表；SCM在系统代码库建立分支，并进行授权，将代码分支地址发送给技术经理；3.4.2封版和解版测试经理在最后一次SIT测试之前，向SCM发送邮件，申请对该代码分支进行封版，该邮件抄送技术经理和项目经理。配置管理员解除对该系统代码分支的可写权限。

12、当测试过程中仍有问题需要解决时，由技术经理向配置管理员发送邮件，申请对该代码分支进行解版。配置管理员根据技术经理申请，对一部分人员进行授权，并通知技术经理结果。在代码封版后，非本次发布计划内BUG等，原则上不得申请在该分支优化，如果必须要搭车在本次发布，需要走紧急发布流程。3.4.3代码分支Merge 分支上线后，配置管理员根据ITP生产发布单的验证信息判定是否进行代码回合，如发布系统进行回滚等不需要回合的情况。 3.5打包发布系统在不同的环境需要部署，包括DEV、SIT、PRE、PRD，每种环境都需要有对应的配置和发布支持。所有项目的发布打包必须是全量包，暂不考虑增量包。发布人员根据测试提供

13、的代码版本来打包，不能每次都打包最新的代码，测试人员只要对打成的包负责测试，无需对版本负责。3.6配置审计SCM发起并实施配置管理审计以维护基线的完整性，规范和流程执行的正确性。项目经理、开发人员必须积极配合审计。配置审计结果作为为版本（项目）质量重要指标，发布在开发管理中心的开发规范实施报告中，其结果将影响个人和团队绩效。4存储库使用规范4.1产品及系统命名规范产品经理在申请产品文档库时，应填写规范的产品名称，包括内部名称，对外发布名称等、产品简写等。技术经理在申请系统代码库时，应填写规范的系统名称，一般以产品简写为基础，如果涉及到多个系统，可以增加适当的后缀进行区别。4.2权限使用规范 严

14、禁借用他人账号进行配置项操作，紧急情况求助CMO代操作，CMO同时要做好操作记录。 违规操作，对账号所有人和使用人进行通报和警告一次，若造成质量问题，根据问题严重程度追加处罚。4.3文档库提交规范如有新产品，按照申请规范申请新的产品库，不允许私自在某现有目录内自己建库；产品文档库只有记录产品研发过程和变化的文档才放入，像项目聚餐照片，活动通知，电子书，安装程序等，严禁上传；产品文档库不应该上传部门相关文档；文档库里面不得上传代码；上传文件单个大小限制在30M之内。如有特殊要求，请提前联系配置管理员；在文档库中，不得随意更改初始目录，如有需要跟配置管理员申请。在规划好的初始目录内部，可以根据需要

15、自行建目录；所有成果物提交必须提交注释信息，格式为“xingmingquanpin, 本次提交内容说明。”；对于提交基线库的文档，注释格式为：“JIRA号，xingmingquanpin, 本次提交内容说明。”。4.4Check in代码规范修改本地代码编译成功后，才可提交到代码库中； 开发人员每天向版本库中提交一次代码，而不是集中在某一天；按操作集提交代码，比如一个问题单修改三个文件，需将三个文件一次性提交代码库；每次提交的操作集只允许包含一个问题单；为了保障配置库完整性和可追溯性，Check in内容必须填写注释。代码库注释内容为：JIRA问题单号（问题key值）+修改描述+姓名+工号。；在代码提交过程中，不允许出现含有中文字符和空格命名的文件，如：图片.jpg，副本.java等。