工程项目配置管理规范

1 概述

1.1 目的和背景

为加强项目过程的控制，提供团队协同的效率，保证软件项目、研发项目相关的技术组件、文档资源在其整个生命周期中的完备性、可追溯性。制定修订本规范。

1.2 适用范围

所有软件开发（含研发）、运维、咨询服务、技术服务类项目。

2 总体原则与要求

1．公司所有非涉密项目的项目过程资料、代码都应当在其产生之后即提交到公司统一的配置库（GitLab库）；

2．项目配置管理同时兼顾规范性与实用性；

3．软件产品或技术组件，必须确保源代码与构建成果的一致性；

4．配置管理是对项目开发实施过程的版本管理与协同支持，因而必须在过程中及时提交，不得在项目结项时再为了应付要求临时提交；

3 角色与职责

1) 公司配置管理员：

• 负责公司统一配置库的技术平台搭建与维护、数据备份、人员权限控制、技术支持；

• 负责统一配置标准要求的编制，统一文档库目录结构的维护；

• 定期协同项目管理部对配置库进行检查。

2) 项目经理：

• 全面负责项目配置管理，对配置管理的一致性，及时性负总体责任；

• 负责配置库的创建与项目组参与人员、角色的维护；

• 督促项目资料与代码的及时提交；

• 接受项目管理部与公司配置管理员的配置库检查，组织对不规范项的整改。

3) 项目管理部：

• 负责对项目配置管理的定期检查，作为项目经理绩效评价参考；

• 结项时负责对项目配置库的内容进行全面检查。

4) 技术部门经理：

• 负责督促各项目组的配置管理规范落实，对项目组的配置管理规范工作负领导责任；

• 负责部门级文档资料共享库的创建与维护。

4 使用规范要求

4.1 基本概念与约定

GitLab中的核心对象是群组（Group）、项目(project)。群组一系列相关项目的合集，并可通过群组统一给群组下的项目设置访问权限。项目是一个独立的git版本仓库。每个项目的URL表现为 git.spm.wiseda.com.cn:2080/群组标识串/项目标识串。项目必须属于一个群组标识串，默认会以当前用户ID作为群组标识串。在需要时，项目可以从一个群组迁移到另一个群组。

作为分布式的版本控制系统，git版本仓库与SVN的最大不同是只能整个版本仓库克隆（Clone）到本地进行工作，而SVN可以从一个版本库的任意指定目录进行检出(checkout)。为了工作方便，我们约定文档与代码分别用不同的git项目。代码又根据项目的开发架构，按照集成构建（Build）与部署的粒度划分，可划分为多个git仓库，一般一个代码git仓库对应于一个构建成果。正常情况下，一个项目的结构类似如下：

如上图中，“WPM研发项目-文档库”为一个项目，项目管理者、业务分析人员主要使用这个项目管理项目文档；开发的每个构建组件为一个项目，上图中，PC端前端，企业微信的前端，后端服务，老ERP接口服务分别为不同的项目。分别开发与构建。

4.2 命名规则

1. 群组(group)的命名规则： 群组以工程项目的项目号为群组标识串，项目号+项目名称为群组名称，群组描述为项目的简单说明，标识串的大小写与项目编号一致，使用大写。如下图：

2. 项目(project，版本库)命名规则：

a) 正常一个项目一个文档版本库，项目标识串为“项目号+‘-’ +docs”，项目名称为 “项目名称+‘-’ +文档库”。

b) 代码版本库根据开发架构可设立多个，每个代码版本库的标识串为 部署组件的英文名称（web服务的上下文根,组件的缩写，可使用英文、数字、减号），名称为 “标识串+‘-’ +中文名称”。描述中可对该组件的用途与注意事项进行说明。标识串的字母用小写，以减号作为单词之间的连接划分。

注意：在项目名称、项目标识串均采用减号‘-’作为唯一连接符。

4.3 其他使用约定规范

1. http://git.spm.wiseda.com.cn:2080/stand/ 为默认的公司文档库结构模板，新项目创建文档版本库中，从这个库中 派生（fork）出一个新的库到新项目的群组中；由公司组织对文档库结构及相关的模板进行更新维护工作，提供项目实施过程的中常用模板。

2. 除非特别复杂的大型微服务项目，一般项目请不要建立配套的子群组。

3. 出于实验、学习的目的，个人可以在自己的个人群组命名空间下创建个人项目，但严禁将正式的项目配置库放到个人命名空间下。个人项目必须确保其存放内容不存在版权、法律方面的问题，且公司配置管理员在存储空间不足等情况下，有权删除个人命名空间下的项目。

4. 推荐使用GitLab的议题(issues)功能进行项目的BUG、用户意见反馈的记录跟踪。因为每个版本库都有议题，建议将所有的议题记录到项目文档库项目中。

5. 不得在GitLab上创建部门群组，不在GitLab上进行部门的业务技术资料共享，这类资料请使用 km.wiseda.com.cn 进行共享管理。

6. 文档库默认启用LFS支持。

5 主要过程与要求

5.1 立项与配置库创建

在工程项目立项或开发实施工作正式开始时（非涉密项目），项目经理（或委派项目技术负责人）负责创建版本配置库。其命名规则见上述要求。在实际的工作过程中，存在虚拟项不能及时立项等情况,按以下的规则处理：

1. 免费质保期的维护项目:正常的软件开发实施项目结项后的免费质保期内的维护工作，可以仍沿用原项目的配置库，不再单独创建配置库。

2. 多期延续性的项目（即二期、三期仍然在原来的代码基础上继续开发完善，或代码仍然有依赖的），创建二期、三期新项目的群组与文档版本库，而代码库可通过项目设置的 转移（Transfer project）功能，将代码库从一期项目转移到二期项目中。

3. 项目立项延后，尚未正式立项，没有项目号的。可先找项目管理部申请项目号，特殊情况可以（明确不会有合同、项目的），经共享中心批准可以创建以项目名称编写为群组名的群组，结构与上述的项目要求一致。

4. 因为客户方推行自有环境的devops ，必须将代码库放在客户提供的服务上的，项目经理必须给出书面说明到项目管理部备案。客户方具外网访问条件的，可以公司 gitlab 上建立git库的同步镜像。不具备外网访问条件的，在项目验收、结项时应当把git库整体镜像到公司 gitlab 。

5.2 项目实施过程的要求

1. 权限控制：项目经理负责项目配置管理库的人员变更权限控制。开发实施项目的群组与项目的权限级别应当是私有的，当项目组成员变动时，项目经理应当及时更新项目的参与人员名单。

2. 及时提交：项目的工作成果应当在产生之后及时提交，不应当非要等到一个文档定稿，或一块功能代码开发测试完成再提交。同时再三强调：一切未提交配置库的工作成果都不算工作成果，一切未提交配置库的工作成果都不算工作成果，一切未提交配置库的工作成果都不算工作成果。

3. 合理注释：每次提供都应当有一个简短的提交说明。

4. 合理使用分支：软件开发项目的代码应当基于git Flow 的工作流合理使用分支。文档库可一个master分支即可。已经上线的系统，至少应有master 主分支（对应于线上运行版本）和 develop 分支（新功能开发），且必须保证线上运行版本与代码库中版本的一致性。

5. 持续构建：推进devops 的流水线构建使用。对于在公司内进行开发测试的项目，使用Rancher所提供的流水线功能。切实因为环境限制，不能使用公司开发环境进行集成构建的，也建议项目组自行安装 Jenkins 。并限定只能通过集成流水线的构建成果进行发布部署。严禁从开发人员本机构建然后往生产环境部署，严禁生产环境直接替换单个文件的热修补行为。

5.3 配置工作的检查

项目管理部与公司配置管理员至少每季度对各项目的配置管理情况进行一次检查。对于中间过程不按规范进行提交处理的，通报技术部门经理，并考核项目经理绩效。

5.4 项目经理变更

项目经理变更，软件项目开发转维护，在WPM变更过程完成后，项目管理部负责将项目群组的owner 变更给新的项目经理或维护项目经理。

5.5 项目结项、撤项与归档

归档(Archive)后的项目将变成只读，不可再提交与变更。考虑到项目运维工作的持续性，不在结项后马上归档。只在配置工作检查时，对于长时间不活动的项目归档。

本通知自发文之日起生效，最终解释权由卓越共享中心负责。