软件三库管理规范标准

.. ..

1 目的围

规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规。

2 参考文献

《软件三库管理制度》

3 术语和定义

GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。

SPM：公司研发部开发的持续集成工具，用于集成软件部署包。

Releaser：公司研发部开发的基于SPM的软件部署包发布工具。

Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。

4 职责

4.1

软件三库管理职责

软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。

4.2

软件管理员职责

a)

具备软件配置管理知识；

b)

熟悉研制项目的配置管理；

c)

熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。

5 管理容与方法

5.1

建立软件三库

5.1.1 开发库

a)

开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。

项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。

项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。

测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。

b)

开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。

. . . .

.. ..

项目组成员负责维护自动测试脚本和版本生成脚本。

Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。

另任库管理员，负责出入库管理、配置项管理等工作。

5.1.2 受控库

a)

受控库代码部分基于GitLab建立，按照软件项目分配仓库。

软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab上作为独立稳定的分支，该分支不接受更改，有效受控。

b)

受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。

Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。

该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。

c)

受控库说明部分存在于公司部的公共服务器。

另任库管理员，负责出入库管理、配置项管理等工作。

d)

受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。

项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。

5.1.3 产品库

产品库存在于公司部公共服务器，按照软件项目分配仓库。

另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。

5.2

制定三库管理规定

5.2.1 容要求

软件三库管理规定：

a)

入库控制

相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。

b)

访问控制

各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。

. . . .

.. ..

c)

出库控制

相关人填写出库申请，负责人审批，库管理员操作出库，通过安全介质交予相关人，详见三库管理要求（第5.4、5.5、5.6节）。

d)

库间转换

库间转换遵循入库控制的要求。

e)

更改控制

详见三库管理要求（第5.4、5.5、5.6节）。

f)

配置状态报告

详见受控库和产品库管理要求（第5.5、5.6节）。

g)

配置审核

详见受控库和产品库管理要求（第5.5、5.6节）。

h)

维护规程

GitLab平台搭建在10.10.0.20服务器上，Jenkins平台搭建在10.10.0.11服务器上，产品库位于10.10.0.10服务器（群晖NAS），采用RAID技术便于数据重构，每晚0点各平台数据库对现有数据进行自动备份。每三个月对三库服务器进行检查维护，以便从紧急状态恢复。

5.2.2 相关要求

软件三库管理规定相关要求：

a)

配置项选择

配置项选择由项目组识别。

b)

配置标识

各库采用适应性标识，标识规详见三库管理要求。

c)

版本控制

代码版本由GitLab自动管理，部署包版本由Jenkins自动管理，产品包版本由产品库管理员管理。

d)

基线建立和更改（基线的基本划分和更改）

采用GitLab平台的里程碑概念，里程碑要求分自主升级与项目组要求两部分。

e)

软件发行

软件发行必须经过测试、申请、审批。

5.3

安全控制

库管理员在入库、出库、更改、发行时，实施介质鉴别、病毒检查和权限审查。

. . . .

.. ..

5.4

软件开发库管理要求

5.4.1 入库容

软件开发库入库容应是项目确定的软件配置项。项目组按照顾客方要求和研制项目特点明确软件配置项的种类、格式和容，对软件规模和复杂度不大的项目，可将软件配置项种类作适应的合并，但应确保容完整。

5.4.2 库属性

软件开发库属性一般应包括的容：

a)

配置项（配置标识、配置项位置），

b)

开发人，入库时间，

c)

更改人，更改时间，

d)

提取人，出库时间，以及提取原因，

e)

其他。

5.4.3 入库控制

将符合项目标识、版本等软件配置要求的软件配置项入库，并按照库属性的相关要求做入库记录。

5.4.4 访问控制

软件开发库代码部分和说明部分的访问控制基于GitLab权限机制实现，部署包部分的访问控制基于服务器的权限机制实现。

5.4.5 出库控制

软件开发库出库应按照以下要求进行：

a)

按规定的权限出库：

如无极特殊的情况，代码部分不允许出库；实需出库的情况，须经项目组长和软件经理审批；

部署包部分和配置项部分的出库经项目组长审批，由项目组配置管理员操作出库。

b)

登记出库原因、去向和用途、使用人等信息；

c)

记录出库项、提取人和出库时间等信息。

5.4.6更改控制

软件开发库的更改应按照以下要求进行：

a)

按规定的权限实施更改：

项目组相关人建立Git分支，完成更改后提交由GitLab自动备份，在Jenkins发起集成，提交部署包给测试组成员，完成更改测试后将结果反馈给项目组，项目组长. . . .

.. ..

审核通过，将该分支Merge到主分支，并在Jenkins发起集成；

应客户特殊需求更改的分支不应Merge到主分支，通过测试后直接转入受控库；

项目组成员相应修改配置项；

b)

利用GitLab的功能向相关人实时发布更改信息，以便相关人做相应更改；特别紧急的情况，可口头通知之后需在GitLab的Issue平台记录；

c)

Git分支及更改的配置项须符合标识、版本的要求，标记对应版本的里程碑：

Bug修复型更改须以hotfix/开头，需求蠕动型更改须以feature/开头。

5.4.7 转受控库

在软件开发过程中，通过公司认可的测试或评审的软件配置项转入受控库。

受控库的代码和部署包一般具有release/vX.X.X-Y的tag标识，公司部使用的保留develop标识，应客户特殊需求集成的保留feature标识；受控库的说明具有XXX项目YY说明vX.X.X标识。

5.5

软件受控库管理要求

5.5.1入库容

软件受控库的入库容是通过测试或评审的软件配置项以及公司和顾客方认可的其他容。

5.5.2库属性

软件受控库属性至少应包括以下容：

a)

配置项（配置标识、配置项位置），

b)

开发人、开发时间，

c)

评测人、评测时间，

d)

入库批准人、入库时间，

e)

更改说明、更改人、更改批准人、更改时间、更改申请号，

f)

出库目的、提取人、出库时间、出库批准人，以及

g)

其他。

5.5.3入库控制

当开发库中的软件配置项完成评测时，开发人提出入库申请；受控库管理员审查入库项的标识、版本以及测评发现的问题是否归零；受控库管理员有关入库信息进行登记。

5.5.4 访问控制

软件受控库代码部分的访问控制基于GitLab权限机制实现，部署包部分和说明部分的访问控制基于服务器的权限机制实现。

. . . .

.. ..

5.5.5出库控制

提取人提交出库（或复制）申请；相关负责人审批；受控库管理员对有关出库信息进行登记。

5.5.6更改控制

不对受控库配置项实施更改，所有更改以升级的形式实现，将升级后的相关配置项按照入库规则进行入库，并及时向有关人员发布更改信息。

升级标识X.X.X-Y符合规定：核心升级，第一位升一级；依赖升级，第二位升一级，bug修复和需求蠕动，第三位升一级；alpha标识对，beta标识对外。

5.5.7配置状态报告

受控库管理员在配置项更改时向公司的有关部门报告配置状态，并向生产、使用、维护相关人员发布受控库配置信息。

5.5.8配置审核

在研制阶段结束之前对受控库进行配置审核：

a)

研发部指定配置审核人员；

b)

配置审核人员拟制配置审核计划，并获批准；

c)

实施配置审核；

d)

项目组对审核发现的不符合项进行整改；

e)

配置审核人员验证整改情况；

f)

将配置审核及验证结果通报软件经理。

5.7.9 转产品库

在定型（鉴定）通过后，将软件受控库中的软件配置项转入软件产品库，其他相关项纳入档案管理，其保存期应与系统服役期保持一致。

5.6

软件产品库管理要求

5.6.1入库容

软件产品库入库容是供交付、生产、检验验收、维护的软件产品和其他软件工作产品。

5.6.2库属性

软件产品库属性一般应包括以下容：

a)

配置项（配置标识、配置项位置）

b)

开发人、开发时间，

c)

入库时间、入库批准人，

d)

评测时间、评测人，

. . . .

.. ..

e)

评审组长、评审时间，

f)

更改说明、更改人、更改批准人、更改时间、更改申请号，

g)

发行人、发行版本、发行时间，

h)

出库目的、出库时间、提取人、出库批准人，以及

i)

其他。

5.6.3入库控制

开发人提出入库申请；产品库管理员对入库项进行标识和版本审查；公司代表（或授权人）应会同顾客方代表共同批准入库；产品库管理员有关入库信息进行登记。

5.6.5出库控制

软件产品库中的项出库（或复制）时，由使用部门或提取人提交出库（或复制）申请；公司代表（或授权人）审批；产品库管理员对有关出库信息登记。

5.6.6更改控制

不对产品库配置项实施更改，所有更改以升级的形式实现，将升级后的相关配置项按照入库规则进行入库，并及时向有关人员发布更改信息。

公司会严格控制升级，升级标识X.X.X符合规定：核心实现升级，第一位升一级；依赖实现升级，第二位升一级，bug修复、配置更改、需求蠕动等，第三位升一级。

5.8.7配置状态报告

产品库管理员在配置项更改时向公司的有关部门和顾客方代表报告配置状态，并向生产、使用、维护相关人员发布软件产品库配置信息。

5.8.8配置审核

在软件定型（鉴定）时对产品库进行配置审核：

a)

公司和客户共同指定配置审核人员；

b)

配置审核人员拟制配置审核计划，并获批准；

c)

实施配置审核；

d)

研发部对审核发现的不符合项进行整改；

e)

配置审核人员验证整改情况；

f)

将配置审核及验证结果通报公司和客户代表。

5.8.9供方控制

对供方提供的软件产品进入软件产品库时，按照软件产品库入库要求进行控制。

. . . .

.. ..

6 支持性文件

文件控制程序 记录控制程序 技术文件管理办法

. . . .

.. ..

拟 制 审 核

日 期 日 期

. . .

批 准

日 期

.