产品研发配置管理规范V10.docx
《产品研发配置管理规范V10.docx》由会员分享，可在线阅读，更多相关《产品研发配置管理规范V10.docx（10页珍藏版）》请在冰豆网上搜索。
产品研发配置管理规范V10
创格科技软件研发
（仅限内部使用）
配
置
管
理
规
范
序号
版本编号
修订内容
修订人
批准人
发布时间
1
1.0
创格科技软件研发配置管理规范
2013年3月5日
2013年3月
1
关于本文档
1.1内容说明
本文从整体上介绍了产品研发配置管理规范，说明了在配置管理活动中需要遵循的各种管理流程和规范，包括文档管理、代码管理、基线管理等。
1.2文档目的
通过学习使用本文档及引用的其它管理规范，达到如下目的：
A、统一定义配置管理规范；
B、根据管理规范要求来定义各信息体系的配置管理活动，确保各配置项正确的标识及存取；
C、保证各信息体系基线配置项的更改受控，维护软件产品完整性和可追溯性。
1.3术语
名称
描述
备注
配置项
凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：
一是属于产品组成的工作成果，如源代码和需求设计文档。
二是管理过程中产生的文档，如计划和报告等。
ConfigurationItem，CI
基线
由一组经过正式评审的配置项组成，这些配置项构成了一个相对稳定的逻辑实体，每个基线都是其下一步开发的出发点和参考点。
基线通常对于开发过程中的里程碑（Milestone）。
Baseline
存储库
在配置管理工具（如SVN）中建立的配置项存储空间及目录。
利用工具可以对存储库进行版本、基线、用户和授权等管理功能。
Repository
2配置管理基本定义
2.1角色与职责
编号
角色
职责
1
配置管理员（SCM）
配置管理部成员，负责存储库的创建、代码版本管理、授权管理和配置审计。
2
项目经理PM
申请存储库、为存储库使用人员审批权限，汇报用户及权限变更情况。
3
产品CMO
每个产品线的兼职人员，执行产品文档库、基线库维护工作。
4
项目团队成员
使用存储库存取成果物，对于产品基线库有只读权限。
5
其它管理或支持人员
对存储库进行权限申请，并获得存储库负责人的审批，由配置管理员授权后，可以使用该产品存储库。
2.2产品与版本
每个产品由产品设计团队根据产品规划，确定不同的产品发布版本；
每个产品需要建立一个产品文档库，并在文档库中建立一个基线存储目录；
每个发布版本以项目的形式组织开发，配置管理以文档基线和代码分支的方式配合产品的版本管理。
每个版本（项目）在该产品对应的系统代码库中对应一个分支，每次发布对应一个分支。
2.3配置项
凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：
一是属于产品组成的工作成果，如源代码和需求设计文档。
二是管理过程中产生的文档，如项目计划等。
每个配置项的主要属性有：
名称、标签、文件状态、版本、作者、日期等。
所有配置项都被保存在配置库里，确保不会混淆、丢失。
配置项及其历史记录反映了软件的演化过程。
根据研发体系要求，根据产品及项目研发活动，如下产品成果物和管理文档必须纳入文档库进行管理，并在正式评审后存入基线库进行管理。
编号
文件
说明
1
产品定义说明书及评审报告
2
用户研究报告
3
项目里程碑计划
4
业务需求模型
需求建模的的原文档
5
业务需求说明书及评审报告
6
产品需求说明书及评审报告
7
交互设计原型（Axure）及评审报告
8
视觉设计原型、设计规范及评审报告
9
概要设计模型
10
概要设计说明书及评审报告
11
测试方案及评审报告
12
详细设计模型文件
13
详细设计文档及评审报告
14
测试用例及测试初始化数据
15
测试报告
16
发布版本
客户端类产品
17
用户手册
2.4基线
在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。
每一个基线都是其下一步开发的出发点和参考点。
基线确定了配置项的一个版本，且只确定一个版本。
一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。
每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制的过程进行。
在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。
2.5存储库
配置管理中设置产品文档库、产品基线库和系统代码库。
2.5.1产品文档库
产品文档库以产品角度，划分目录层级和分类，放置产品研发中的文档。
包括产品定义、需求分析、系统涉及、开发、测试验证、发布和运维生命周期各个阶段。
产品文档库目录分为两大类，第一类是产品类，这类目录主要用于记录产品生命周期内的各类文档。
第二类是项目类的，该类目录主要用于存储该产品在各个版本的项目研发中需要记录的各类文档。
产品文档库设置请参考文档《产品文档库目录及使用说明》，该文档在各产品文档库根目录下。
2.5.2产品基线库
需要对每个版本确认一个基线，每个基线在SVN库中以目录方式体现。
基线库目录结构如下。
2.5.3系统代码库
代码库申请按照系统的划分，一个系统对应一个代码库。
代码库使用分支、版本和Trunk进行管理。
新建库后由配置管理员对目录进行初始化，初始目录结构如下：
目录名称
目录说明
备注
branches
分支目录，当前开发的代码和分支
开发人员读写权限
tags
标签目录，每一次文档（上线）版本的代码镜像（copy），基线化操作目录。
打tag操作由项目cmo进行
trunk
主干目录，代码始终与生产环境的保持一致，每次发布生产都要进行更新。
合并trunk操作由配置管理员进行
3配置管理流程
配置管理贯穿在整个软件产品生命周期中，一个标准的配置管理对于整个研发流程起到很重要的作用。
3.1配置库用户管理
3.1.1用户注册
需要使用SVN存储库的用户，需要先在系统内进行用户注册。
3.1.2用户权限申请
项目组成员对产品文档库和代码文档库权限申请，由项目经理将申请表单发给SCM统一添加。
其它用户申请某产品配置库权限，需依据工作范围和职责申请，禁止跨权申请。
除配置管理员外，不允许用户拥有所有库目录操作权限。
管理人员原则上不允许申请代码库权限。
3.1.3权限注销
项目结束时收回项目组成员对产品文档库权限，请项目经理及时告知。
产品经理、产品分析员、技术经理等产品相关人员可以保留对文档库的使用权限。
SIT测试封版时收回代码库可写权限，项目结束时，收回项目组临时人员可读权限。
也就是只保留维护人员可读权限。
产品生命周期内有离职、离场、调走人员，请产品负责人及时反馈给配置管理组进行权限的注销，否则出现由此造成的问题，由产品负责人承担；项目组中有人员调动、离职、离场等需要（产品库和代码库）回收权限的情况请项目经理及时反馈给配置管理组进行权限注销和调整，否则出现由此造成的问题，由项目经理承担。
3.2配置库申请
3.2.1产品文档库申请
产品文档库在产品立项结束后，由项目经理填写《产品文档库申请表.doc》，向SCM进行申请。
SCM审核后，依据产品文档库目录结构，创建产品文档库和基线库。
3.2.2代码库申请
新系统代码库的申请需要在概要设计结束后，由技术经理填写《系统代码库申请表.doc》，向SCM进行申请。
由SCM审核后，创建系统代码库，并将代码库SVN地址反馈给技术经理。
3.3文档基线及变更管理
在项目研发每个里程碑结束时，为该阶段成果物建立基线，由产品CMO将该里程碑成果物放入基线库。
操作人员进行登记《产品文档基线版本说明.xls》，维护基线变更报告，同时将基线变更内容发送邮件通知项目组团队成员，抄送配置管理员和开发管理顾问。
项目组团队后阶段工作必须依据基线库中前阶段成果物，不得使用外部其它需求，如果有变更，需要由变更者提出申请，走需求变更流程。
当需要对基线文档进行变更时，必须走变更流程。
详细参考《产品研发需求管理规范.docx》。
3.4代码版本管理
3.4.1申请分支
在原有系统代码库优化代码，必须申请新的分支；
新的分支申请，由技术经理在确定发布版本后申请；
申请时需提交该分支可读写人员列表；
SCM在系统代码库建立分支，并进行授权，将代码分支地址发送给技术经理；
3.4.2封版和解版
测试经理在最后一次SIT测试之前，向SCM发送邮件，申请对该代码分支进行封版，该邮件抄送技术经理和项目经理。
配置管理员解除对该系统代码分支的可写权限。
当测试过程中仍有问题需要解决时，由技术经理向配置管理员发送邮件，申请对该代码分支进行解版。
配置管理员根据技术经理申请，对一部分人员进行授权，并通知技术经理结果。
在代码封版后，非本次发布计划内BUG等，原则上不得申请在该分支优化，如果必须要搭车在本次发布，需要走紧急发布流程。
3.4.3代码分支Merge
分支上线后，配置管理员根据ITP生产发布单的验证信息判定是否进行代码回合，如发布系统进行回滚等不需要回合的情况。
3.5打包发布
系统在不同的环境需要部署，包括DEV、SIT、PRE、PRD，每种环境都需要有对应的配置和发布支持。
所有项目的发布打包必须是全量包，暂不考虑增量包。
发布人员根据测试提供的代码版本来打包，不能每次都打包最新的代码，测试人员只要对打成的包负责测试，无需对版本负责。
3.6配置审计
SCM发起并实施配置管理审计以维护基线的完整性，规范和流程执行的正确性。
项目经理、开发人员必须积极配合审计。
配置审计结果作为为版本（项目）质量重要指标，发布在开发管理中心的《开发规范实施报告》中，其结果将影响个人和团队绩效。
4存储库使用规范
4.1产品及系统命名规范
产品经理在申请产品文档库时，应填写规范的产品名称，包括内部名称，对外发布名称等、产品简写等。
技术经理在申请系统代码库时，应填写规范的系统名称，一般以产品简写为基础，如果涉及到多个系统，可以增加适当的后缀进行区别。
4.2权限使用规范
严禁借用他人账号进行配置项操作，紧急情况求助CMO代操作，CMO同时要做好操作记录。
违规操作，对账号所有人和使用人进行通报和警告一次，若造成质量问题，根据问题严重程度追加处罚。
4.3文档库提交规范
如有新产品，按照申请规范申请新的产品库，不允许私自在某现有目录内自己建库；
产品文档库只有记录产品研发过程和变化的文档才放入，像项目聚餐照片，活动通知，电子书，安装程序等，严禁上传；
产品文档库不应该上传部门相关文档；
文档库里面不得上传代码；
上传文件单个大小限制在30M之内。
如有特殊要求，请提前联系配置管理员；
在文档库中，不得随意更改初始目录，如有需要跟配置管理员申请。
在规划好的初始目录内部，可以根据需要自行建目录；
所有成果物提交必须提交注释信息，格式为“xingmingquanpin,本次提交内容说明。
”；
对于提交基线库的文档，注释格式为：
“JIRA号，xingmingquanpin,本次提交内容说明。
”。
4.4Checkin代码规范
修改本地代码编译成功后，才可提交到代码库中；
开发人员每天向版本库中提交一次代码，而不是集中在某一天；
按操作集提交代码，比如一个问题单修改三个文件，需将三个文件一次性提交代码库；
每次提交的操作集只允许包含一个问题单；
为了保障配置库完整性和可追溯性，Checkin内容必须填写注释。
代码库注释内容为：
JIRA问题单号（问题key值）+修改描述+姓名+工号。
；
在代码提交过程中，不允许出现含有中文字符和空格命名的文件，如：
图片.jpg，副本.java等。
升级会员 