软件配置管理流程规范手册

软件配置管理流程规范手册4.2变更管理目标：控制配置项的变更，确保变更的必要性、合理性、可追溯性，避免未经授权的修改。4.2.1变更请求发起触发场景：需求变更、缺陷修复、优化改进等；输入：变更请求单（模板见附录B）；输出：变更请求登记。操作步骤：1.变更申请人（开发/测试/产品人员）填写《变更请求单》，内容包括：变更描述（what）；变更原因（why）；影响分析（对进度、成本、质量的影响）；实施计划（how）。2.将《变更请求单》提交至配置管理工具（如Jira），配置管理员登记并分配唯一变更ID（如`CR-____`）。4.2.2变更评审输入：变更请求单、配置项清单、基线文档；输出：变更评审结果（批准/驳回/暂缓）。操作步骤：1.配置管理员组织CCB召开变更评审会，评审内容包括：变更的必要性（是否必须修改）；变更的可行性（技术、资源是否支持）；变更的风险（是否会引入新问题）。2.CCB根据评审结果签署意见：批准：进入变更执行阶段；驳回：返回申请人修改，或终止变更；暂缓：等待进一步信息（如需求澄清）。4.2.3变更执行与验证输入：变更批准意见、配置项；输出：修改后的配置项、验证报告。操作步骤：1.开发人员根据变更批准意见，从受控库检出需修改的配置项，在开发库中进行修改；2.修改完成后，提交代码审查（如通过Git的PullRequest），确保代码符合规范；3.测试人员对修改后的配置项进行验证（如功能测试、回归测试），出具《变更验证报告》；4.验证通过后，将修改后的配置项提交至受控库，更新配置项清单。4.2.4变更发布输入：验证通过的配置项、变更验证报告；输出：发布通知、产品库更新。操作步骤：1.配置管理员将受控库中的配置项合并至产品库（如Git的master分支）；2.生成正式发布版本（如`v1.0`），并打上版本标签；3.发布《变更发布通知》，告知项目团队及相关stakeholders（如客户、运维人员）变更内容、生效时间。4.3版本控制目标：对配置项的版本进行管理，确保不同版本的可追溯性，支持版本回滚。4.3.1版本命名规则采用三段式版本号（主版本.次版本.修订版本），规则如下：主版本（Major）：重大功能变更（如架构调整、核心功能新增），例：`v2.0.0`；次版本（Minor）：新增功能或优化（如新增一个模块、改进用户界面），例：`v1.1.0`；修订版本（Patch）：缺陷修复或微小调整（如修复一个bug、调整配置文件），例：`v1.0.1`。示例：初始版本：`v1.0.0`；新增功能后：`v1.1.0`；修复bug后：`v1.1.1`；重大升级后：`v2.0.0`。4.3.2分支策略（以Git为例）分支类型用途创建来源合并目标主干分支（master）存储正式发布的产品版本初始创建无（仅读取）开发分支（dev）存储正在开发的版本mastermaster（发布时）功能分支（feature）开发新功能devdev（功能完成）缺陷分支（bugfix）修复生产环境缺陷masterdev+master发布分支（release）准备正式发布（如测试、文档）devmaster+dev操作规范：功能分支命名：`feature/功能名称`（例：`feature/user-login`）；缺陷分支命名：`bugfix/缺陷ID`（例：`bugfix/BUG-____`）；发布分支命名：`release/版本号`（例：`release/v1.0`）；分支合并前必须经过代码审查（如通过Git的PullRequest）。4.3.3版本回滚当发布的版本出现严重问题时，需进行版本回滚，操作步骤如下：1.确认回滚目标版本（如`v1.0.0`）；2.从产品库检出目标版本，覆盖当前生产环境的版本；3.验证回滚后的版本是否正常运行；4.发布《版本回滚通知》，说明回滚原因、影响范围。4.4配置审计目标：检查配置项的完整性、一致性、合规性，确保配置管理活动符合流程要求。4.4.1审计类型审计类型审计内容审计时机功能审计（FunctionalAudit）配置项是否符合需求规格基线建立前、变更发布前物理审计（PhysicalAudit）配置项是否完整、版本是否一致每迭代结束后、季度末4.4.2审计流程输入：配置项清单、基线文档、变更记录；输出：配置审计报告（模板见附录C）。操作步骤：1.配置管理员制定审计计划，明确审计范围、时间、人员；2.审计人员检查配置项：功能审计：核对配置项是否符合需求文档（如代码是否实现了需求中的功能）；物理审计：核对配置项的数量、版本、存储路径是否与配置项清单一致（如产品库中的版本是否与发布通知一致）。3.记录审计发现的问题（如配置项遗漏、版本不一致），并提出整改要求；4.编制《配置审计报告》，经项目经理审批后发布；5.跟踪整改情况，确保问题在规定时间内解决（如3个工作日内）。4.5配置状态报告目标：向项目团队及stakeholders反馈配置项的当前状态，确保信息透明。4.5.1报告内容配置项状态（新增、修改、删除）；变更记录（近期批准的变更请求）；版本信息（当前使用的版本、待发布的版本）；审计结果（近期审计发现的问题及整改情况）；风险提示（如未解决的变更、版本冲突）。4.5.2报告频率与受众报告类型频率受众每日简报每日下班前开发团队、测试团队每周报告每周五下午项目经理、产品经理月度报告每月末管理层、客户4.5.3报告格式采用表格+文字说明的形式，示例如下：配置项名称类型版本状态变更IDuser-service-api代码v1.0.1修改CR-____需求文档文档v1.0未变更-测试用例文档v1.1新增CR-____说明：本周批准了2个变更请求，其中CR-____修复了用户登录功能的bug，CR-____新增了支付功能的测试用例。目前开发库中的feature分支正在开发新功能，预计下周合并至dev分支。5工具支持5.1工具选择工具类型推荐工具用途版本控制工具Git、SVN、Perforce管理代码、文档的版本配置管理工具Jira、Confluence、GitLab跟踪变更请求、存储配置项构建工具Maven、Gradle、Ant自动化构建、生成二进制文件部署工具Jenkins、GitLabCI/CD、ArgoCD自动化部署、发布版本5.2工具配置与维护权限管理：根据角色分配工具权限（例：开发人员可提交代码，测试人员可访问受控库，管理员可管理配置库）；备份与恢复：定期备份配置库（如每日备份），确保数据安全；工具升级：及时升级工具版本，修复安全漏洞，提升性能。6角色与职责角色职责配置管理员（CMO）1.建立与维护配置库；

2.管理变更请求，组织变更评审；

3.生成配置状态报告；

4.执行配置审计；

5.培训项目团队遵守配置管理流程。开发人员1.提交配置项至开发库；

2.遵守版本控制规则（如分支策略、代码审查）；

3.参与变更执行与验证。测试人员1.验证变更后的配置项；

2.提交测试结果至配置管理工具；

3.参与配置审计。变更控制委员会（CCB）1.评审变更请求，做出决策；

2.监督变更执行情况；

3.解决变更中的争议。项目经理1.审批配置项清单、变更请求；

2.协调配置管理资源；

3.确保配置管理流程落地。7奖惩机制7.1奖励对严格遵守配置管理流程、表现突出的团队或个人，给予通报表扬或奖金奖励（如季度配置管理先进个人）；对提出优化配置管理流程建议的团队或个人，给予创新奖励（如流程改进奖）。7.2惩罚对违反配置管理流程的行为（如未经评审修改受控库中的配置项、未提交变更请求直接修改代码），给予口头警告或书面警告；对因违反流程导致严重后果的（如版本冲突导致项目延期、数据丢失），给予绩效扣分或岗位调整。8附则8.1手册修订本手册根据公司业务发展和流程优化需要，每一年修订一次，修订流程如下：1.配置管理员收集项目团队的反馈意见；2.组织CCB评审修订内容；3.经管理层批准后发布新版本。8.2解释权本手册的解释权归公司研发管理部所有。8.3生效日期本手册自2024年X月X日起生效。附录附录A配置项清单模板配置项ID配置项名称类型负责人存储路径基线关联备注CI-001user-service-api代码张三dev/feature/user-login需求基线用户管理APICI-002需求文档文档李四controlled/req/需求基线V1.0版本CI-003测试用例文档王五controlled/test/测试基线覆盖核心功能附录B变更请求单模板字段内容变更IDCR-____申请人张三（开发工程师）申请日期____变更描述修改用户登录功能的密码校验规则（允许特殊字符）变更原因用户反馈密码规则过于严格，影响使用体验影响分析1.需修改user-service-api的代码；

2.需更新测试用例；

3.对进度无影响（预计1天完成）。实施计划1.3月15日：检出代码，修改密码校验逻辑；

2.3月16日：提交代码审查，测试人员验证；

3.3月17日：合并至受控库，发布变更。CCB意见批准（签字：李四，____）附录C配置审计报告模板字段内容审计编号CA-____审计范围项目A的配置项清单（CI-001至CI-005）审计时间____审计人员王五（配置管理员）、赵六（测试负责人）审计发现1.CI-003（测试用例）的版本为v1.0，但配置项清单中记录的是v1.1；

2.CI-005（数据库脚本）未纳入受控库，存储在开发库中。整改要求1.3月22日前更新配置项清单中的CI-003版本；

2.3月22日前将CI-005提交至受控库。整改结果已完成（签字：张三，____）附录D版本控制策略示例（Git）1.从master分支创建dev分支（`gitcheckout-bdevmaster`）；2.从dev分支创建feature分支（`gitcheckout-bfeature/user-logindev`）；3.开发完成后，将feature分支合并至dev分支（`gitmergefeature/user-login`）；4.准备发布时，从dev分支创建rele