配置管理

配置管理

Posted by Dongyupu on March 14, 2023

1简介

1.1目的

本规程描述了项目级配置流程所涉及的角色、活动和工作产品，用于规范和指导如何开展项目级配置管理活动，便于指导对需求或任务在实施过程中的配置管理。

1.2适用范围

  • 本规程适用于需求或任务（包括项目需求、常规需求、紧急需求与生产问题）在开发实施过程中的配置管理工作。
  • 工作产品应包括：
    • 项目管理类文档：如项目计划、项目状态报告等。
    • 项目工程类文档：需求分析说明书、总体设计说明书、详细设计说明书等。
    • 源代码（含数据和配置文件、编译脚本、环境参数、执行码，安装软件包等）。

      1.3术语表

1.4相关规程

参考《组织级配置管理规程》获得组织级配置库的总体结构、配置库管理维护和配置用户管理等有关的内容。

2总体描述

2.1规程概述

软件产品在应用研发与项目管理的过程中输出的多数工作成果物需进行配置管理，配置管理是确保软件产品在其整个生命周期中保持完整性、一致性和可追溯性的有效管理手段。

2.2规程结构图

2.3角色和职责

  • 配置管理员（中心）：向配置管理员（项目）提出配置管理要求并进行指导培训，自动化构建服务器的构建基础介质管理。
  • 配置管理员（项目）：负责策划涉及源代码、执行程序的项目级配置，识别配置项，定义配置基线并确定基线建立计划，制定配置审计计划，完成配置管理计划。申请项目级的配置库，在需求或任务过程中对工作产品进行版本控制与基线管理，管理和维护数据库脚本的目录结构和项目自动化构建脚本，执行项目级配置审计，编制配置审计报告，跟踪并关闭配置审计问题。配合执行配置管理员（中心）提出的配置管理要求。
  • 文档管理员：负责策划文档类等工作产品的项目级配置，识别配置项，定义配置基线并确定基线建立计划，制定配置审计计划，完成配置管理计划。申请项目级的配置库，在需求或任务过程中对工作产品进行版本控制与基线管理，执行项目级配置审计，编制配置审计报告，跟踪并关闭配置审计问题。而配合执行配置管理员（中心）提出的配置管理要求。
  • 项目成员：负责编制工作产品，正确控制和标识工作产品的版本，及时归档工作产品至配置库中，编制项目自动化构建脚本，自动化构建服务器的编译依赖第三方介质管理，提供投产实施材料。
  • 厂商负责人：负责为承包的应用、项目提供配置管理员（项目）。

    2.4流程输入及输出

    2.4.1 输入

  • 项目/需求里程碑计划
  • 工作产品

    2.4.2 输出

  • 《配置管理计划》
  • 《配置项清单》
  • 《配置状态报告》
  • 《配置审计报告》

    2.5流程图

    3流程活动描述

3.1 策划配置管理

3.1.1 进入准则

  • 项目需求已立项，并已确定项目里程碑计划
  • 常规需求任务已受理，并确定版本里程碑计划
  • 紧急需求或生产问题已受理

    3.1.2 输入

  • 项目/需求里程碑计划

    3.1.3 工作任务

  • 1．识别配置管理员（项目）
  • 1.1 当需求或任务启动时，配置管理员（中心）识别并指定负责需求或任务的配置管理员（项目），具体如下：
    • 1) 对于项目需求，须单独识别和指定该项目各系统的配置管理员（项目）；
    • 2) 对于常规需求、紧急需求与生产问题，可单独指定配置管理员（项目）。
  • 2．策划配置管理内容
  • 根据项目/需求的里程碑计划，以及任务的特性，配置管理员（项目）、文档管理员策划配置管理的内容，主要的策划内容包括：
  • 2.1选择配置管理工具及配置库结构
    • 1) 选择配置工具，并确定在指定的配置库中的存放位置。配置工具选择原则如下：
      • 对于需求或任务实施过程中文档和执行码（程序包），文档管理员应选择SVN作为配置管理工具。
      • 对于源代码，配置管理员（项目）应选择Gitlab作为配置管理工具。原使用RTC、SVN的应用需逐步迁移至中心指定的GitLab库中，RTC仅限主机使用，SVN不再管理源代码。
    • 2) 根据实际的任务类型，配置管理员（项目）、文档管理员策划相应的配置库结构及其人员的访问权限（RTC、GitLab、SVN等），具体配置库结构请详见《配置库结构层次和权限控制》，并积极主动申请接入中心指定的管理工具。
  • 2.2识别配置项
    • 1) 配置管理员（项目）与文档管理员、项目经理、测试经理等人员沟通，根据需求或任务实施过程中需输出的工作产品列表，结合《标准配置项列表》，识别出需纳入配置管理的配置项（如需求分析说明书、总体设计说明书、源代码等）。
    • 2) 配置管理员（项目）与文档管理员对识别的配置项确定标识，将标识的配置项记录在配置管理计划的配置项列表中，同时生成《配置项清单》（在《配置项目清单》中预留配置项的映射路径）。配置项的标识命名规则请详见《配置命名规范》。
  • 2.3定义基线
    • 1) 根据需求或任务特点、类型及其生命周期模型，配置管理员（项目）、文档管理员与项目经理等相关人员一起识别并规划需求或任务所需管理的基线种类。基线的类型包括：计划基线、需求基线、设计基线、测试基线、投产基线等。可根据需求或任务的实际情况进行增减，但必须包括需求基线和投产基线。
    • 2) 当基线已规划识别后，配置管理员（项目）、文档管理员初步拟定基线建立计划并发布。可按里程碑计划确立基线，具体如下：
      • 计划基线：项目计划或版本计划通过评审时建立，包含里程碑计划等配置项。
      • 需求基线：《需求分析说明书》通过评审时建立，包含业务需求、需求分析说明书等配置项。
      • 设计基线：《总体设计方案说明书》通过评审时建立，包括总体设计方案说明书、详细设计说明书等配置项。
      • 测试基线：完成系统测试、性能测试、业务测试通过时建立，包括测试案例、测试报告、源代码等配置项。
      • 投产基线：投产当日建立，包括投产技术手册、源代码、程序修改登记表、投产程序包等配置项。
    • 3) 配置管理员（项目）、文档管理员与项目经理、测试经理等人员讨论配置项与配置基线的对应关系，即确定各基线分别包含哪些配置项，每个配置项分别属于哪类基线。
  • 2.4制定配置管理计划
    • 1) 在项目过程定义和里程碑计划初步确定后，配置管理员（项目）、文档管理员与项目经理协商沟通，制定配置管理计划，并提交项目经理，由项目经理将配置管理计划纳入到项目计划中，具体请参见《项目计划》中关于“配置管理计划”的描述。配置管理计划主要内容应包括：
      • 策划项目实施过程中工作成果存档和版本控制要求；
      • 制定基线建立及发布计划，包括策划基线的版本、建立时间，指定基线应包含哪些配置项。
      • 制定配置审计计划。计划安排的原则：在基线建立前完成配置审计。
  • 2.5评审配置管理计划
    • 1) 项目经理发起和组织项目计划（含配置管理计划）的评审活动，具体评审活动请参考《评审规程》及《评审工作机制》中 关于“项目计划”的评审要求。

      3.1.4 退出准则

  • 完成制定配置管理计划并通过评审

    3.1.5 输出

  • 《配置管理计划》
  • 《配置项清单》

    3.2 申请建立配置库

    3.2.1 进入准则

  • 完成配置策划活动

    3.2.2 输入

    无

    3.2.3 工作任务

  • 1．申请建立配置库
  • 1.1 当配置管理策划完成后，配置管理员（项目）向配置管理员（中心）申请建立需求或任务相关的初始配置库。
  • 2．初始化配置库
  • 2.1 配置管理员（中心）在相应的配置库中新建初始的配置库
    • 1) 项目需求：配置管理员（中心）在项目需求库中新建以项目名称命名的库，在代码配置库建立相应的源代码的库。
    • 2) 常规需求/紧急需求/生产问题：配置管理员（中心）创建常规需求库；在代码配置库建立相应的源代码的库。
  • 2.2 按成员名单，配置管理员（中心）开通配置管理员（项目）对新建的子库的访问权限，配置管理员（项目）开通项目成员对新建的配置子库的访问权限。
  • 2.3 配置管理员（中心）向配置管理员（项目）反馈已完成新建初始配置子库及其权限设置。配置管理员（项目）向项目成员和关联系统的配置管理员（项目）告知配置库的路径。

    3.2.4 退出准则

  • 建立了配置子库并完成用户权限初始化设置

    3.2.5 输出

    无

    3.3 管理版本

    3.3.1 进入准则

    建立了配置库并完成用户权限初始化设置

    3.3.2 输入

    工作产品

    3.3.3 工作任务

  • 1．管理工作产品版本
  • 1.1对于项目/需求（含生产问题）的开发编码阶段、测试的工作产品（源代码）的版本管理的步骤及要求如下：
  • 驻场开发类型：
    • 1) 源代码版本管理原则
      • 信息源代码只能存放在指定的开发环境和配置库（GitLab）中，未经批准，任何人不得擅自复制、拷贝、修改信息系统源代码。未经研发部门责任人批准，测试人员不得访问应用源代码；未经批准，数据中心人员及其他外部人员严禁访问应用源代码。
      • 主干版本上的源代码必须与生产环境版本保持一致，主干版本源码构建后的执行码可直接用于生产环境部署。
      • 并行版本（研发周期有重叠但投产窗口不一致的版本），应建立不同的分支。
      • 同一应用的每个版本都应该对其所有架构的所有项目统一拉取分支,所有分支的初始版本都应该基于低版本分支的最新状态拉取。
      • 配置文件需要严格受控，原则上优先接入配置中心管理，并应该由项目经理或项目经理指定项目组成员进行专人管理、维护，并区分开发、测试、生产环境的版本。
    • 2) 日常源代码版本管理
      • 配置管理员（项目）基于低版本分支的最新状态拉取此版本分支。
      • 开发人员从正确的分支版本获取源代码，根据项目/需求（含生产问题）的任务进行源代码修改，在确认此版本与生产版本完成合并且已解决冲突的基础上，执行并通过代码调试后（可提交测试验证），再将源代码提交至分支中。
      • 配置管理员（项目）应遵循窗口先后顺序，至少每周一次向后窗口分支进行源代码的同步，尽早解决版本冲突。
      • 当需要拆版/合版时，配置管理员（项目）组织项目成员对分支版本进行相应的回退/合并，保持分支版本与对应环境版本一致。
      • 当存在版本补丁时，补丁定版程序应包含该版本增量的全量程序，即定版加补丁程序。
      • 分支定版时，已接入配置中心的应用直接使用最新部署成功的版本；未接入配置中心应用需以最新部署成功的版本作为基础，仅可改动需变更的配置文件，再进行定版。
      • 分支定版时，配置管理员（项目）组织项目组根据版本变更的源码清单、提版程序清单进行核对，确认待定版清单无误则可完成定版，若清单不一致者，需分析原因并整改完成后，方可定版。
    • 3)投产源代码版本管理
      • 分支投产当天，配置管理员（项目）应对分支投产版本（含补丁）的源代码（含配置文件、数据库脚本文件等）创建投产版本基线，以标识版本。
      • 分支投产后3个工作日内，配置管理员（项目）需关闭已投产分支。
      • 配置管理员（中心）将投产基线版本源代码同步到主干库中，以保持主干版本与生产环境一致。；
      • 配置管理员（项目）需确认已将投产版本源代码追平（同步）到各并行开发的分支中，以保持现行开发版本基于主干（生产）版本进行开发。
    • 4)源代码项目结构管理
      • 源代码初始化时原则上以一个应用的一种架构作为一个项目，每个项目内应包含该应用架构的源码、数据库脚本、配置文件、自动化构建总控脚本等。项目具体目录结构请参见《配置目录结构和命名规范》中的相关描述。
    • 5)数据库脚本管理
      • 数据库脚本文件编写需遵循同一版本内可重复执行安装的原则，定版过程无需对预定版数据库脚本做任何调整。
        • ①数据库插入数据语句中，需标准写入删除语句；
        • ②数据库新增表语句中，需根据各应用数据库表判断是否删除后重复执行或是否存在无需执行；
        • ③数据库新建索引或者新建存储过程语句中，需标准先写删除索引或者存储过程语句。数据库脚本具体存放目录结构几命名请参见《配置目录结构和命名规范》中的相关描述。
  • 非驻场开发类型： 对于非驻场开发的项目/需求（含生产问题）的日常源码版本管理由合作公司自行管控，但每一次投产都必须将全量源码（含配置文件、SQL）提交至中心指定的源码配置库中，并创建投产版本基线。
  • 1.2 对于项目或需求（含生产问题）的测试、投产阶段的工作产品（可执行程序）的版本管理步骤如下：
  • 驻场开发类型：
    • 1)配置管理员（项目）将每次提交测试的可执行程序提交至指定的配置库中；
    • 2)配置管理员（项目）/版本管理员将定版投产的可执行程序提交至指定的配置库中。
  • 非驻场开发类型： 厂商负责人需将定版投产的可执行程序提交至中心指定的配置库中。
  • 1.3 对于项目或需求（含生产问题）的其他的阶段的工作产品（非源代码、可执行程序）的版本管理步骤如下：
  • 1) 获取正确版本
    • 项目成员在配置库的正确路径下中获取正确版本的工作产品。
  • 2) 版本信息更新
    • 在完成工作产品创建或修订后，正确标识版本和名称，以及补充文档修订记录。
  • 3) 上传配置库
    • 工作产品的版本信息完成后，需及时存放到需求或任务的配置库中正确的配置路径下。
  • 1.4 当项目成员间需对同一工作产品进行编写或修改时，项目成员不得擅自将已编写或修改的工作产品（包括项目文档或程序源代码等）给其他项目成员，项目成员应将已完成的工作产品正确标识版本和命名后提交配置库中，其他项目成员均只能从配置库中获取工作产品。
  • 2．管理环境程序版本
  • 2.1环境程序版本管理原则
    • 1)所有开发、测试环境的程序版本更新都应该基于生产环境的程序版本，即程序版本投产后应同步至各个开发、测试环境。
  • 2.2日常环境程序版本管理
    • 1)测试环境版本变更，变更需根据项目/需求（含生产问题）的任务提版计划进行，每次变更前需完成当前环境程序版本备份，配置管理员（项目）/版本管理员将需要测试的任务对应的程序提版、部署到对应的测试环境（已实现自动化的应用需使用自动化工具完成提版、部署）。
  • 2.3投产后环境程序版本管理
    • 1)敏捷环境需要在投产当天完成，其他环境需要在投产后1个工作日内完成.
    • 2)对于已实现同步环境自动化的应用，配置管理员（项目）/版本管理员应使用自动化工具进行环境同步，环境的配置应由版本管理员完成。

3.3.4 退出准则

工作产品已标识版本号并及时上传配置库

3.3.6 输出

无

3.4 源码构建及部署

3.4.1 进入准则

工作产品（源代码）通过内测验证

3.4.2 输入

工作产品（源代码）

3.4.3 工作任务

    1. 构建部署管理原则
  • 1.1应用源代码的编译、打包、测试发布，原则上应按照规范使用指定的管理工具。项目团队成员需配合配置管理员（中心）进行工具的推广调研和使用培训。
  • 1.2应用部署变更时（含应用程序、配置文件、服务进程等变更）须统一使用应用用户执行，不应使用root用户。
  • 1.3.对于使用产品页面配置进行的变更，应改造为支持通过修改配置文件、更新数据库或在服务器上使用命令行调用程序完成更新。
    1. 自动化构建管理
  • 2.1应用自动化构建服务器的构建环境基础介质版本和构建执行目录结构由配置管理员（中心）统一管理，编译依赖第三方介质由项目成员管理。
  • 2.2应用自动化构建调度服务器由配置管理员（中心）统一管理，应用在调度工具上的初始配置由配置管理员（中心）指导配置管理员（项目）完成，日常维护由配置管理员（项目）完成。
  • 2.3应用构建过程脚本由配置管理员（中心）和项目成员分工完成，应用源码下载、调用项目组构建脚本和构建产物上传配置库部分的脚本由配置管理员（中心）完成，应用编译和输出完整程序包的自动化构建脚本由项目成员提供,由配置管理员（项目）负责日常维护。 构建服务器目录结构和自动化构建脚本存放的目录结构请参见《配置目录结构和命名规范》中的相关描述。
  • 2．构建提版管理
  • 2.1当完成源代码开发并已确定提版基线时，由配置管理员（项目）将源代码构建成可执行程序，具体构建要求请参见《发布管理规程》中的“3.1测试发布管理”的相关描述。
  • 3．部署提版产品
  • 3.1项目组成员提供投产实施材料，配置管理员（项目）检查并确认投产实施材料的完整性，以及版本的正确性后，发起程序部署申请，版本管理员审核部署程序内容及版本通过后，实施部署。具体部署要求请参见《发布管理规程》中的“3.1测试发布管理”的相关描述。

    3.4.4 退出准则

    部署完成

    3.4.5 输出

    无

    3.5 管理基线

    3.5.1 进入准则

    工作产品通过评审或通过验证批准

    3.5.2 输入

    无

    3.5.3 工作任务

  • 1．发布基线
  • 1.1 工作产品（除源代码外）的基线管理 根据配置基线建立计划，当任务实施的各阶段的工作产品通过评审或验证批准后，文档管理员建立对应的基线，对基线进行版本标识。
  • 1) 总体策划的工作产品（如项目计划）
    • 项目成员将正确标识版本的工作产品归档入库后，根据基线建立计划，文档管理员在相应的配置项上标识基线。
  • 2) 按系统设计的工作产品（如详细设计）
    • 项目成员按系统将正确标识版本的工作产品归档入库后，各关联系统的文档管理员应在《配置项清单》中更新维护工作产品的版本与配置路径；
    • 根据基线建立计划，各关联系统的文档管理员在相应的配置项上标识基线。
  • 1.2源代码的基线管理 在代码配置库中，项目成员将《配置命名规范》中要求正确标识程序名称及版本，并及时纳入配置库，各系统的配置管理员（项目）应在对应项目或需求任务中的《配置项清单》中映射源代码的配置路径，并对源代码统一进行版本控制和基线标识，具体处理过程请详见《源代码配置指南》。

  • 1.3 基线发布对照表 |发布类型|发布责任人|发布范围|发布要求及时机| |:—–|:—–|:—–|:—–| |里程碑基线发布|配置管理员（项目）、文档管理员|项目内受影响的相关人员|通过评审或测试验证| |投产基线发布|项目经理、配置管理员（项目）、文档管理员|内部|通过投产审批并投产当天内|

  • 说明：里程碑基线是指：计划基线、需求基线、设计基线、测试基线。
  • 2．更新基线
  • 2.1 在需求或任务实施过程中，当通过评审或验证的工作产品的内容发生变更时（如项目计划变更、需求变更等），变更申请人提出变更申请，具体变更控制处理请参见《变更管理规程》中相关描述。
  • 2.2 若变更经审核批准，当变更内容实施完毕后，配置管理员（项目）、文档管理员验证工作产品内容已完成变更，并更新工作产品对应的配置项基线版本。若变更经审核拒绝，配置管理员（项目）、文档管理员保持原基线及版本不变。
  • 3．配置状态及报告
  • 3.1 形成基线时，配置管理员（项目）、文档管理员编写配置状态报告，内容报告：配置项名称、版本号、起始时间、批准人、基线名称及版本等。
  • 3.2 当发生变更时，配置管理员（项目）、文档管理员根据变更提出人提交的《变更申请表》，在整个变更过程中，跟踪变更请求状态，基线变更情况记录在配置状态报告中。
  • 3.3 配置管理员（项目）、文档管理员将配置状态报告及时发布给任务实施的相关人员。
  • 3.4 配置管理员（项目）、文档管理员定期（如每周）向项目经理、项目成员反馈配置项按计划执行的情况及基线变更状态。
  • 3.5.4 退出准则 基线已建立或已更新
  • 3.5.5 输出 无
  • 3.6 产品入库
  • 3.6.1 进入准则 投产基线已建立
  • 3.6.2 输入 无
  • 3.6.3 工作任务
    • 1．工作产品入库
    • 1.1 需求或任务投产完成后，各系统的配置管理员（项目）、文档管理员检查确认投产基线中的工作产品，准备执行工作产品的入库操作：
      • 1) 代码（含源码和执行码）入库
        • 各系统的配置管理员（项目）按系统维度将代码归档到产品配置库中；
        • 配置管理员（中心）检查并确认代码是否已完成入库。
      • 2) 除代码外其他工作产品的入库
        • 各系统的项目经理或文档管理员按系统维度将工作产品整合归档到产品配置库中，并更新《产品库入库清单》中；
        • 文档管理员检查并确认工作产品是否已完成入库。

          3.6.4 退出准则

          投产完成，投产基线中的工作产品已入产品配置库

          3.6.5 输出

          无

          3.7 配置审计

          配置审计为了维护配置管理执行的有效性，并确保软件产品在其整个生命周期中，各配置项在技术上和管理上的完整性。

          3.7.1 进入准则

  • 定期或按计划审计：
  • 项目需求/常规需求/紧急需求：根据配置审计计划执行。
  • 生产问题：每双周对项目团队内的生产问题的配置执行审计。
  • 事件驱动（如配置库内容出错、外部要求审计等）。

    3.7.2 输入

    无

    3.7.3 工作任务

    • 1．执行审计
    • 1.1 配置管理员（项目）、文档管理员对需求或任务的配置执行审计，在审计过程中记录审计问题和结果。配置审计的内容包括：
      • 1) 审计项目级配置库的目录结构完整性；
      • 2) 审计项目成员归档配置项是否及时、正确，并坚持配置记录是否正确反映了配置项的配置情况；
      • 3) 根据配置管理计划中说明的需求和所批准的变更请求的处理结果为依据，审计项目级配置库中配置项的完备性和正确性；
      • 4) 验证是否符合配置管理规范和要求。
    • 2．审计问题跟踪与关闭
    • 2.1 在配置审计执行完成后，配置管理员（项目）、文档管理员在3个工作日内完成《配置审计报告》的编制，并发布给全体项目成员和其他相关人员。
      • 1) 在编制过程中，配置管理员（项目）、文档管理员与项目经理确认审计发现的问题，并制定相应的纠正措施与计划。
    • 2.2 对已确认的审计问题，项目经理督促项目成员按照制定的纠正措施和计划进行整改。
    • 2.3 配置管理员（项目）、文档管理员跟踪整改进度，并验证整改后的审计问题是否全部关闭。
      • 1) 当审计问题已关闭并验证，应知会全体项目成员和其他相关人员。

        3.7.4 退出准则

        审计问题得到验证并关闭

        3.7.5 输出

        《配置审计报告》

        4活动裁剪指南

        |序号|类型|裁剪| |:—–|:—–|:—–| |1|项目需求|本过程所有活动不允许裁剪| |2|常规需求/紧急需求|策划配置管理时可不输出详细的配置管理计划，但需执行“识别配置项”、“定义基线”和“制定配置审计计划”的活动| |3|生产问题|策划配置管理时可不输出详细的配置管理计划，但需执行“识别配置项”、“定义基线”的活动。|