配置库使用规范cx

1、 配置库使用规范拟制:陈 霞日期2016/02/15审核:日期2016/02/22版权所有 侵权必究修订记录Revision record日期Date修订版本Revision version修改描述 change Description作者Author2016/02/15 0.0.1配置库使用规范初稿定稿陈霞目录1.前言42.角色与职责43.用于配置管理的软硬件资源44.配置库管理基本活动54.1配置库54.2配置项74.3配置库权限74.4命名规范84.5基线84.6版本发布规则82021/12/22第3页, 共8页 1. 前言制定配置管理规范的目的在于对所开发的软件制定各种必要的配置管理规

2、定，从而使所交付的软件能够满足任务书中的各种需求，能够满足软件需求说明书中的各项具体要求，以便有计划地开展配置管理工作，确保产品开发过程中的稳定性、一致性和可靠性。2. 角色与职责角色职责、工作范围产品经理提供资源，负责支持和协调项目进度跟踪管理,协助资源协调，培训需求跟踪管理。项目经理负责技术支撑，提供资源测试经理负责测试工作的管理CCB组长组织会议审核变更申请，确定变更申请修改方案CCB成员参与CCB会议审核变更申请，确定变更申请修改方案配置管理员（1） 制定配置管理计划（2） 创建和维护配置库（3） 配置标识（4） 基线发布（5） 版本发布（6） 配置项状态发布（7） 配置审计。（8）

3、权限管理（9） 变更管理交付经理组织交付团队对影响交付的重大问题进行分析、跟踪、督促和解决。3. 用于配置管理的软硬件资源服务器SVNGitlabConfluenceJIRA地址软件资源SVN Client版本：TortoiseSVN 1.7.12 Subversion 1.7.9GitLab:7.13.5Confluence: 5.7.4JIRA:6.4.4硬件资源计算机名：DOCSERVER处理器：Intel(R)Xeon(TM) CPU 3.00GHz (4CPUs)内存：2046MB RAMCPU：E3-1230内存：32G企业硬盘：16TCPU：E3-1230内存：16G企业硬盘：6

4、TCPU：E3-1230内存：16G企业硬盘：6T4. 配置库管理基本活动4.1 配置库配置库一般可以分为代码库、文档库，现在可以认为所有软件工程活动的成果或者中间成果都应该纳入到配置库中进行统一管理，以便于随时追溯软件工程活动的每一个环节点。4.1.1 公用资源库部门制定的开发规范和各种管理规范文档，各种开源和公司购买的开发工具，以及各种学习资料。内容包括： 企业各项基本管理制度；公司的基本管理制度主要是企业目前状态和常规管理信息等内容。帮助员工了解企业的纵向深度内容。 单独的薪酬体系和劳动保障内容；这一项内容应该写明企业内的薪酬体系，各级别的薪资待遇，以及各个级别如何帮助员工合理避税，最大

5、化员工收益的各种模式。劳动保障内容应该写明员工应该享受哪些国家规定的基本劳动保障，另外，在什么阶段何种除了基本保障以外的保障或者收益提高。 企业各部门的划分和分类目标；本类别介绍企业内各个部门的职能和划分方式以及划分原则，当企业部门发生调整的时候应该在一定时间范围内调整，有利于新进入的员工更多的了解企业的横向扩展内容，以便于在适当的时候与需要的部门之间进行配合操作，降低无效的时间浪费。 各种工作所需要的工具软件，以及这些软件的内部使用配置说明书。 团队成员介绍和职责说明。 团队和开发工作相关的其他文档资料。4.1.2 公共代码库部门构建的基于历史项目总结和提炼出来的具有一定通用型的代码组件。其

6、内容包括以下四项：代码分类代码具体的分类位置，方便使用者查找，如果用户无法查询或者查询很困难，那么被引用的次数少，自然因为代码库而获得的奖励部分就会减少。代码全部按照公司规定封装好的可执行代码和相关的库文件形态。代码简要说明文字代码的输入输出和一些功能介绍。Demo实例程序实际调用这段代码实现功能的例子程序，可以让使用者知道为什么要用，是否能达到目的。4.1.3 项目管理库项目管理相关的文档和资料，针对每一个项目建立一个单独的库，并建立权限控制机制。基本包括下面内容： 项目管理：项目计划，人员分配，职能和项目目标等； 需求调研：需求调研的原始资料素材； 需求分析：需求分析文档和模型； 概要设计

7、：概要设计文档和模型； 详细设计：详细设计模型； 代码：所有的代码； 测试项目配置库：存放测试计划，测试用例，测试报告，样包等； 开发项目配置库：存放度量统计，风险管理，里程碑报告，问题与缺陷，接口说明，配置说明，项目计划，项目总结等； 开发工具：各种本项目所需的工具以及开发环境配置实现的说明。4.1.4 内部技术资料和代码库团队核心技术人员确定技术资料的分类目录，所有的技术人员都可以在对应的分类目录下补充自己认为有价值的文档资料，通过审核后的资料会显示在资料库内供大家查看和学习使用。采用confluence论坛形态组成评论和学习方式，每一个文档被阅读后都可以直接查阅相关评论和补充内容。具体的

8、分类可以根据企业的目的和企业的技术要求进行定义，可以去掉一些自己公司短期内不需要的技术资料，着重保留有关系的资料，也可以采用兼容并蓄无所不有的方式进行资料库的分类管理。4.2 配置项配置管理中的配置项包括项目中产生的所有文档和代码以及相关信息，诸如录音文件、图片照片扫描件等等，详细分析包括下面这些类别：项目计划：开发计划、迭代计划、测试计划等；需求资料：需求采集录音、需求调研记录、需求调研报告；系统分析：概要设计报告（包括技术架构和功能清单）、以及重要的架构表现代码、用例模型或者需求分析文档集；概要设计：UI分析文档、UI设计结果、原型设计（Axure设计文件.rp）、分析模型、测试方案；详细

9、设计：设计模型、测试用例；代码编写：代码、单元测试、基线发布、持续集成；测试：集成测试、系统测试、回归测试等；说明：配置库所有内容提交，都需要有注释进行修改说明。4.3 配置库权限4.3.1 权限类别读权限：对应配置项有在线查看和下载权限。读写权限：对资源的增加、修改、删除、check in/out的权限, 包括对分支的构建, 标签的提交；4.3.2 权限分配产品经理：拥有需求资料部分的全部权限，拥有对项目管理资源的查阅权限。配置管理员：拥有配置库管理权限，对整个配置库的管理层配置权限、分支构建管理权限。项目经理：拥有配置库中所有配置项的查询权限和项目管理、资源管理配置项的管理权限。基线管理员

10、：项目经理指定人员兼任，具有基线发布的权限。基线发布后，测试组获得通知，并启动针对该基线版本的集成测试工作。开发团队：拥有指定项目内对应任务分支的文档和代码的增加修改删除权限，可以查询所属项目的全部文档，可以访问使用公用组件组代码。测试团队：拥有部分产品文档查阅，测试库的读写权限。QA：拥有对全过程开发成果的查阅权限。全员都拥有的权限：公用资源库、公共代码库的查阅权限。4.4 命名规范4.4.1 产品版本号命名规则  产品名+R+SPC+B R从R001开时，B从B001开始，SPC从SPC001开始，1).R是产品中小项目版本号，比如海南电信就是R001，固网版本是R00

11、2，R版本后面带3位数字，不同的小项目中R版本不一样，往后累加1；2).SPC是软件补丁版本号，后面带3位数字，第一次对外发布的时候不需要带SPC版本，如:NISP3.0R001B001，后续对外发布升级版本，需要增加SPC版本，如:NISP3.0R001SPC001B002，每次对外发布一次SPC版本往后累加1；3). B是build版本，内部转测试的版本号，每个R版本下的B版本标识都是唯一，并且往后累加1，不同的R版本下的B版本重新规划。4.4.2 模块版本号命名规则 模块名_V1.0.0 build *从V1.0.0开始,1).主版本号：当产品版本号改进时，第一个1开始递增，每

12、次增1；2).次版本号：当结构性更改或迭代版本发布时，第二个0开始递增，每次增1；3).修订版本号：当普通版本修改，第三个0开始递增，每次增1;4).build次数：通过自动构建系统进行的每日构建次数，此数值在整个项目生命周期中是累加状态，不清零，如果目前没有搭建每日构建环境，则可以空缺。4.4.3 文档命名规则 产品名-文件名（_日期）4.4.4 分支命名规则 br_分支名*说明：分支统一由开发向配置管理员申请，说明分支用途，分支命名，由配置管理员建立。4.5 基线基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础。当基线形成后，配置管理员需要通知相关人员基线已经形成，并且哪儿可以找到这基线了的版本。基线后的软件文档或源码就不能改动(改动需要变更控制委员会通过才可以)。4.6 版本发布规则版本发布分转测试和转交付两种类型；版本发布转测试前，