软件配置管理（SCM）中常见的三库模型（受控库、开发库、产品库），其核心作用是实现配置项的版本控制与生命周期管理：
受控库（Controlled Library）：存放已通过正式评审、批准并纳入基线（Baseline）的配置项（如需求规格说明书、设计文档、测试用例、已验证的代码版本等）。该库受严格访问控制，变更需走变更控制流程（CCB审批），确保基线稳定可追溯。
开发库（Development Library）：供开发人员日常使用，存放正在开发、频繁修改的配置项（如源代码、临时脚本、未评审的设计草稿）。通常权限较宽松，支持快速迭代，但不保证稳定性或可发布性。
产品库（Product Library）：存放经完整测试、验收合格、正式发布的最终产品版本（如交付给客户的安装包、发布文档、签名镜像等）。该库内容只读或仅允许发布操作，确保交付一致性与可重现性。
三库分离体现了“开发—受控—发布”的阶段性管控思想，是CMMI、ISO/IEC 12207等标准推荐的实践，有助于提升产品质量、审计合规性与发布可靠性。
典型工作流示例： 开发库 →（提交+评审）→ 受控库（形成基线） 受控库 →（集成测试+发布审批）→ 产品库（生成发布版本）受控库中的基线配置项原则上不可随意修改，因其代表已评审通过、达成共识、具备可追溯性和稳定性的项目里程碑（如需求基线、设计基线、产品基线）。只有在发生经评估确认的必要变更时，才允许修改，且必须遵循严格的配置控制流程（Configuration Control Process），通常依据IEEE 828或ISO/IEC 12207标准，并由配置控制委员会（CCB, Configuration Control Board）主导。
✅允许修改的典型条件包括：
- 发现严重缺陷（如安全漏洞、功能失效、合规性不满足），且无法通过补丁或临时方案规避；
- 外部强制要求变更（如法规更新、第三方接口协议升级、客户签署的正式变更请求）；
- 基线本身存在评审遗漏或重大技术错误，经复核确认影响整体交付质量；
- 项目范围发生经批准的重大变更（Scope Change），且已触发基线重定（Baseline Re-baselining）。
🔄标准修改流程（关键角色与步骤）：
- 变更请求（CR, Change Request）提交
→ 提出者（开发/测试/PM等）填写结构化CR表（含问题描述、影响分析、预期收益、风险评估）； - 初步审查与登记
→ 配置管理员（CMO）审核完整性，分配唯一CR编号，录入配置管理系统（如Jira+GitLab CI/CMDB）； - 影响分析（Impact Analysis）
→ 相关领域负责人（如架构师、测试经理、SQA）联合评估对范围、进度、成本、其他配置项、测试用例、文档等的影响； - CCB评审与决策
→ CCB（通常含项目经理、技术负责人、质量代表、客户代表（可选））召开会议，投票决定：批准/拒绝/延期/要求补充材料； - 批准后执行变更
→ 开发人员从受控库检出（checkout）副本 → 在开发库完成修改 → 全面回归验证（含单元/集成/系统测试）→ 提交变更包； - 基线更新与发布
→ CMO将验证通过的配置项重新纳入受控库，生成新版本号（如V1.2.0），更新基线标识（Baseline ID）、基线快照及变更日志； - 通知与同步
→ 向所有干系人发布基线更新通告，同步更新相关文档（如配置状态报告CSR）、测试环境与构建流水线。
⚠️ 补充说明：
- 所有操作需留痕（审计追踪），支持回滚至前一基线；
- “修改”不等于“覆盖原版本”，而是新增版本+版本关联（如继承关系、差异说明）；
- 小型项目中CCB可简化为PM+技术骨干双签，但流程不可省略。