2.10 软件配置管理

概述与动机

软件配置管理（SCM）是这样一门学问：识别一个软件系统的各个组成部分，控制它们如何变化，记录每一次变更的状态，并验证你所构建和交付的东西与你原本的意图相符。它回答了一个听起来简单、在规模化之后却会变得棘手的问题：这次发布里究竟包含什么，它是如何形成的，又是谁批准的？SWEBOK 把 SCM 视为一个基础性的知识领域，理由很清楚：其他每一项工程活动，都需要一个稳定、已知的配置作为工作对象。

在一个大型团队中，SCM 是让成千上万个活动部件保持一致的结缔组织。源代码、库、容器镜像、基础设施定义、配置数据、文档和测试制品，都按各自的节奏变化，而一个交付的系统正是所有这些东西的某个特定版本组合。没有刻意的配置管理，这个组合就是未知的，也就无法被复现。你无法重建一次过去的发布，无法把一个缺陷追溯到引起它的那次变更，也无法有把握地说出生产环境中正在运行的到底是什么。

企业和政府场景把这一切的重要性进一步抬升。受监管的项目和公共部门项目必须能够证明，变更是经过授权、评审并记录的；一个交付的构建能够追溯到经批准的需求和源代码；且没有任何东西是未经控制就进入系统的。在这里，SCM 既是一套工程体系，也同样是一套证据体系。版本控制（第 2.6 章）管理的是源代码历史；SCM 治理的是整个配置以及它发生变化时所遵循的受控流程。它与基础设施即代码（第 8.2 章）、交付流水线（第 8.1 章）以及审计与保障（第 10.2 章）密切相关。

关键原则

一切决定系统行为的东西都是一个受控的配置项，而不仅仅是源代码。
基线是一个已知的、经过认可的参考点；针对基线所做的变更应当是有意为之的，而不是随意的。
变更是被控制和记录的，而不是被阻止的；目标是让变更被授权、可追溯。
状态记账（status accounting）意味着你始终能够回答一个配置中包含什么、它的变更历史是什么。
审计验证的是所构建和交付的系统与记录在案的配置以及经批准的需求相符。
可复现性是不容商榷的：任何已发布的版本都必须能够从受控的输入重新构建出来。
把识别、记录和验证工作自动化；手工记账无法扩展，也经不起审计的考验。

建议

定义 SCM 流程并落实归属

写下一份 SCM 计划，说明哪些内容受配置控制、这些项目如何被识别、变更如何被提出和批准，以及状态如何被记录和审计。明确落实归属，比如一位配置经理或一个负责任的团队，这样 SCM 才不会成为”人人有责”因而”人人无责”的事情。让流程的严格程度与风险相匹配：一个小型内部工具只需要轻量级的控制，而一个安全关键或受监管的系统则需要正式的委员会和记录。把这份计划锚定在一个公认的标准上，比如 IEEE 828，这样审计员和合作方才能够遵循它。

识别配置项并建立基线

列出决定系统行为方式的配置项：源代码、依赖项、构建脚本、容器镜像、基础设施定义、配置数据、模式（schema），以及关键文档。为每一项赋予一个稳定的标识符和一套版本编号方案。在有意义的节点上设立基线（一个已发布的版本、一套经批准的需求集合、一次经过认证的构建），这样你就有了一个可以据以变更、也可以据以返回的、经过认可的参照点。基线是不可变的：一旦你宣告了它，你就不能编辑它。你只能通过变更流程创建一个新的基线来取代它。

通过一套明确的流程和恰当的委员会来控制变更

让针对受控项目的变更沿着一条明确的路径流转：提议、影响评估、批准、实施和验证。对于风险较高的项目，使用一个变更控制委员会（CCB），在授权一次变更之前权衡成本、风险和进度。要为委员会选择恰当的规模：为常规代码变更设置一个轻量级的自动化关卡，为触及基线、接口或受监管行为的变更设置一个正式的跨职能 CCB。记录每一项决策及其背后的理由，并把重大的配置决策与决策记录（第 1.6 章）关联起来，让理由得以留存。

维护配置状态记账

为每一个配置项保持一份准确、可查询的记录：它当前的版本、它属于哪个基线，以及施加在它上面的变更请求。这份状态记账正是让你在任何时刻都能回答一次发布包含什么、以及它是如何形成的关键所在。要从你的权威工具（版本控制、流水线、制品仓库）中自动生成这份记录，而不是维护一份与现实逐渐脱节的平行电子表格。这份记录是从需求到变更、到构建、再到部署这条可追溯性链条的骨干。

开展配置审计

按固定周期验证两件事。功能配置审计确认该配置的表现符合其需求所规定的方式。物理配置审计确认交付的制品与记录在案的配置相符：确认构建来自记录在案的源代码和依赖项，且不包含任何来路不明的内容。要尽可能地把这一切自动化：可复现构建、制品校验和、软件物料清单（SBOM）和来源证明（provenance attestation），把审计从一次人工检查变成一项持续性的检查。

把发布和交付管理为受控事件

把一次发布当作一个特定的、经过标识的基线，通过一套可重复的流程交付出来。为你的发布明确设定版本号，生成一份清单或物料清单，准确描述其中包含的内容，并记录从发布到源代码修订版本、再到部署制品之间的映射关系。对已发布的制品进行签名和校验和处理，让下游的任何人都能验证其完整性。把发布管理与交付流水线（第 8.1 章）关联起来，使跨环境的晋升本身也是受控的、被记录的、可回退的。

选择并集成 SCM 工具

依靠能够自动化识别、控制、记账和审计的工具，而不是单纯依赖自律：用版本控制管理源代码，用制品和镜像仓库管理二进制文件，用一条不可变的流水线管理构建，用基础设施即代码管理环境，用依赖项和 SBOM 工具追踪来源。把它们连接起来，使一次变更能够可追溯地从提交一路流向已部署的发布。你追求的是这样一套工具链：配置记录是完成工作的副产品，而不是一项独立的文书杂务。

权衡：利与弊

选择	优点	缺点
正式的变更控制委员会	授权和审计轨迹强，变更前权衡风险	吞吐更慢；用于常规变更时开销较大
轻量级自动化关卡	流转快；开销低；能扩展到大量变更	对高风险基线而言不够严谨；审议较少
严格的不可变基线	可复现、可审计的参照点	需要纪律和工具支撑；用得过度会造成摩擦
自动化状态记账	记录准确、始终最新；随时可供审计	前期工具和集成投入较大
手工配置记录	上手简单；不需要工具	会与现实脱节；在规模化和审计下会失效

核心的权衡是控制与流转之间的取舍。严格的变更控制带来强有力的保障，但会拖慢交付速度。宽松的控制流转迅速，但会削弱可追溯性。答案不是在全局层面二选一，而是按风险来分层控制：让常规变更通过快速关卡自动流转，把正式委员会和不可变基线保留给授权和可审计性真正重要的项目。第二重权衡是前期的工具投入与持续的文书成本和审计风险之间的取舍。自动化记账的搭建成本更高，但维持成本要低得多。

与团队讨论的问题

我们的配置项清单上究竟应该包含什么，当出现新的东西时，由谁来负责决定？ SCM 只有在受控项目的清单与真正决定系统行为的那一整套东西相匹配时才能起作用，而在一个大型系统中，这个集合远比大多数团队所想的要大：源代码、依赖项、构建脚本、容器镜像、基础设施定义、模式、特性开关，以及那些悄悄改变软件行为方式的配置数据。如果没有人拥有这份清单，它就会过时，而那个让你在生产环境中栽跟头的项目，往往正是没人想到要去控制的那一个。带上你们当前的清单，去寻找那些决定行为、却不在清单上的项目。指定一位负责任的所有者（一位配置经理或一个具名的团队），使添加一个新项目成为一次深思熟虑的决策，而不是一次意外，因为人人有责的 SCM 就是无人负责的 SCM。
我们能否证明一个已部署的制品确实来自我们认为的那个源代码和流水线，这个证明能否经得起篡改的考验？ 可复现性和可追溯性正是 SCM 的全部意义所在，这个问题的尖锐版本是：你能否用证据、而不是断言，把正在运行的二进制文件与一次具体的提交和一次构建运行关联起来。在一个受监管或高价值的系统中，这也是你的供应链防线：经过签名的来源证明、制品校验和以及软件物料清单，把”我们相当确信”变成了一个审计员或事故响应人员能够核实的东西。带上你们最近的一次发布，试着从已部署的制品往回倒推到经批准的变更。如果任何一个环节是一句人工断言，而不是一条被记录、可验证的链接，那正是攻击者或一次诚实的失误能够神不知鬼不觉地混入东西的地方，而堵住它的办法是把签名和来源信息接入流水线，让记录成为交付的副产品。
今天是否有人能够就地编辑一次发布，这会对我们信任它的能力造成什么影响？ 一个基线只有在不可变时才有用：一旦”这次发布”可以在事后被编辑，你就再也无法复现它，也无法把它当作一个可靠的参照点，每一次下游审计都会变成一场考古。经典的失败模式是配置在生产环境中被直接编辑，或者一个标签被悄悄移动，这恰恰是那种感觉无伤大雅、却会让一次发布事后无法重建的捷径。带上诚实的答案到会议上：谁拥有在不经过变更流程的情况下修改一个已部署基线的权限，这种情况发生过吗？解决办法是让基线真正做到不可变，并让每一次变更都经过提议、影响评估、批准和验证，按严格程度分层，使常规变更通过快速的自动化关卡流转，而基线和受监管的变更则提交给委员会。
我们的配置状态记账是从权威工具中自动生成的，还是靠手工维护的，它与实际部署的内容脱节了多远？ 状态记账是让你在任何时刻都能回答一次发布包含什么、以及它是如何形成的那份记录，而在一个大型系统中，这份记录只有在它是工作的自然产物、而不是被手工敲进一份平行电子表格时，才是值得信赖的。这里相互竞争的拉力在于，一份手工维护的登记表在起步时感觉成本低、也灵活，而把它自动化则意味着要集成版本控制、流水线和制品仓库，让这份记录成为交付的副产品。带上你们今天依赖的这份登记表，随机挑选三次最近的发布，检查记录的版本、基线和已应用的变更请求，是否与工具所说的实际发布内容相符。对于一个企业或政府项目而言，一份与现实脱节的状态记录不是一个整洁与否的问题，而是一次等待发生的审计发现，因为一位审计员一旦抓到一处缺口，就会不再信任整份记录，并要求你手工重建它。
我们的变更控制是否按风险分层，还是无论变更触及什么，都套用同样一套繁文缛节？ 控制与流转相互抗衡：一个正式的变更控制委员会在授权一次变更之前会权衡成本、风险和进度，但把这套仪式套用到一次常规的代码微调上只会增加延迟，而把一个共享基线或一条受监管的支付流程推过一个快速自动化关卡，恰恰在你最需要审议的地方省略了审议。失败模式是对称的：要么是统一的繁重，人们学会绕开它；要么是统一的宽松，让一次高风险的变更未经审视就溜过去。带上上个季度的一份变更样本，按每一项触及的内容分类，检查它所获得的严谨程度是否真正与其风险相匹配。在一个受监管或公共部门的场景中，要明确哪些项目类别必须提交跨职能委员会，哪些可以通过自动化关卡流转，并把这种分层明确地记录下来，因为”我们靠判断力”不是一项审计员或监督机构能够核实的控制措施。
我们上一次开展功能配置审计和物理配置审计是什么时候，其中有多少证据是一份现成的实时记录，而不是一次重建？ 功能配置审计确认系统的表现符合其需求所规定的方式，物理配置审计确认交付的制品与记录在案的配置相符、且不包含任何来路不明的内容；跳过它们，就意味着你在没有核实过的情况下，相信自己的基线和状态记账是诚实的。这里的张力在于成本：手工审计缓慢又痛苦，这正是团队一再推迟它的原因，而出路是用可复现构建、制品校验和、软件物料清单和来源证明把这些检查自动化，让验证变成一项持续性的工作。带上你们最近的一次发布，试着当场产出从需求到变更、到构建、再到部署的追溯链条，以及从制品到源代码的证明。对于企业和政府项目而言，这条证据链正是认证和监督所要求的，因此诚实的问题在于，明天的审计能否用你们已经掌握的记录来回答，还是要靠一场你们负担不起的考古式重建。

行业视角

初创企业。 让 SCM 保持轻量但真实。把源代码、基础设施定义和配置数据都放进版本控制，让每一次发布都是由同一条流水线产出的、打了标签的构建，而不是手工拼凑出来的制品。跳过变更控制委员会和正式基线，这些在你们的规模下属于过度设计，但绝不要让任何人直接在生产环境中编辑配置，因为正是这一个捷径，会让一次发布在下周二客户遇到缺陷时变得无法复现。

中小企业。 在没有配置经理、预算又紧张的情况下，应依靠那些几乎免费为你提供 SCM 能力的工具：一个托管的版本控制平台、它内置的流水线，以及一个制品仓库，这样配置记录就成了一项副产品，而不是一份需要专人负责的工作。购买那些已经内嵌在你们已在付费使用的工具中的这项能力，而不是自建一套定制流程。把你们稀缺的注意力花在最重要的两个习惯上：可复现的、打了标签的发布，以及不让改变行为的配置出现在手工的生产环境编辑中。

大型企业。 问题在于众多团队之间的一致性：一份共享的 SCM 计划、一套共同的配置项分类体系、分层的变更控制，以及从版本控制、制品仓库和流水线中自动生成的状态记账。把正式的变更控制委员会和不可变基线保留给共享平台和受监管的流程，让常规变更通过自动化关卡流转，并把签名来源证明和 SBOM 标准化，使任何团队的发布都能被追溯，任何审计员都能查询一份实时记录，而不必委托一次重建工作。

政府。 采购规则、透明度和公共问责塑造着这个流程。要遵循一份与公认标准（比如 IEEE 828）对齐的正式 SCM 计划，在合同里程碑处为配置项建立基线，并让每一次针对受控基线的变更都经过一个委员会，记录其影响、决策和理由。要求交付的制品能够从受控输入中被复现、经过校验和处理，并能够从经批准的需求到交付的构建端到端地被追溯，因为这条有文档记录的证据链正是认证、审计和公共监督所要求的。

示例

初创企业。 一家六人的初创公司让自己的 SCM 保持轻量但真实：源代码、基础设施定义和配置数据都存放在版本控制中，每一次发布都是由同一条流水线产出的、打了标签、有版本号的构建，而不是手工拼装出来的。当一位客户报告了一个上周二出现的缺陷时，他们能在几分钟内把已部署的制品追溯到确切的那次提交，而不是靠猜测。他们跳过了变更控制委员会和正式基线，这些在他们的规模下属于过度设计，但他们拒绝让任何人直接在生产环境中编辑配置，因为正是这一个捷径，会让一次发布事后无法复现。

大型企业。 一家大型金融服务公司把所有可部署的制品、基础设施定义和配置数据都置于配置控制之下。每一次发布都是一个不可变的、带版本号的基线，配有自动生成的软件物料清单，每一个已部署的制品都携带一份经过签名的来源证明，将其与一个具体的源代码修订版本和流水线运行关联起来。常规的应用变更通过自动化流水线关卡流转，而针对共享平台基线或受监管支付流程的变更则提交给一个变更控制委员会。状态记账从版本控制、制品仓库和流水线中自动生成，因此审计员查询的是一份实时记录，而不必要求一次重建。

政府。 一个国防项目遵循一份与 IEEE 828 对齐的正式 SCM 计划。配置项在合同里程碑处被列出并建立基线，一个变更控制委员会授权每一次针对受控基线的变更，并记录其影响、决策和理由。功能配置审计确认交付的系统满足规定的需求，物理配置审计确认交付的制品与记录在案的配置完全相符。发布能够从受控输入中被复现、经过校验和处理，并且端到端可追溯（）从经批准的需求，经过变更请求，到交付的构建（）这正是认证和监督所要求的那条证据链。

商业案例：动机、投资回报率与总拥有成本

SCM 的存在是为了在一个系统的整个生命周期中控制风险和成本。回报来自可复现性和可追溯性：你能够重建任何一次发布，把缺陷追溯到引起它们的变更，并用记录而非考古来回答审计问题。这缩短了事故诊断的时间，降低了审计的成本和时长，并防止了那类代价高昂的失败（）没有人能说清楚现在运行的是什么、也不知道如何重建它。

总拥有成本倾向于支持自动化。手工配置记录起步便宜，维护成本却稳步攀升，而且恰恰会在你最需要它们的时候（）事故或审计期间（）失效，因为它们已经与现实脱节。自动化的识别、记账和审计前期投入更大，但会把配置记录变成交付流水线近乎免费的副产品。向领导层陈述这个案例时，要把 SCM 描述为让发布可复现、让变更可审计的控制措施，并将其与不可复现发布、旷日持久的审计，以及不受控变更所带来的合规风险相权衡。

反模式与陷阱

靠口口相传的配置： 一次发布的真实内容只存在于某位工程师的脑子里，而不在任何记录中。
可变基线： “这次发布”被就地编辑，导致它再也无法被复现或被当作可靠的参照点。
不受控的配置数据： 代码被纳入了版本控制，但改变其行为的配置却在生产环境中被随意编辑。
变更控制作秀： 一个对一切都橡皮图章式批准的委员会，只增加延迟而没有增加真正的审视。
手工状态记账： 一份版本电子表格，与实际部署的内容悄悄地渐行渐远。
不可复现的构建： 无法从受控输入中重新构建的发布，导致审计和重建都变成了猜谜游戏。
不可追溯的发布： 没有从已部署的制品追溯回源代码修订版本、变更请求和批准的映射关系。

成熟度模型

第 1 级（启动）： SCM 是临时且被动应对的。只有源代码受到控制；发布是手工拼装的；没有基线，没有关于已部署内容的可靠记录，也没有办法复现一次过去的构建。
第 2 级（发展）： 基本做法开始出现，但因团队而异。一些系统定义了配置项和变更流程，并为其发布设定版本号，基线在个别地方存在，但记录部分是手工维护的，控制的严谨程度在组织内部并不一致。
第 3 级（标准化）： 实践已被记录并在组织范围内强制执行。一套共同的配置项分类体系、不可变基线、分层变更控制和状态记账已经建立，并且在很大程度上实现了自动化；发布是可复现、可追溯的，审计有工具支撑，而不是依赖记忆。
第 4 级（管理）： SCM 用数据来度量和控制。可复现率、从需求到已部署制品的可追溯性覆盖率、每个控制层级的变更前置时间、配置漂移事件，以及审计发现，都被对照基线和目标进行跟踪。偏差会触发纠正措施，每一项”是否放行”的决策都基于这些证据，而不是基于断言。
第 5 级（编排）： SCM 在整个组织范围内被持续改进和集成。凭借可复现构建、SBOM、来源证明和实时状态记账实现完全自动化和持续验证，这个流程被编织进交付、安全和审计之中，并随着风险和交付结果的变化而调整，根据证据来淘汰或重新界定控制措施。

讨论思路

你们今天能否从受控输入中精确地复现上一次发布，这需要花多长时间？
哪些配置项决定了行为，却实际上并不受控，尤其是配置数据和基础设施？
你们的变更控制是否按风险分层，还是到处都在增加统一的开销，或者到处都是统一的宽松？
你们的配置记录存放在哪里，它与实际部署的内容脱节了多远？
如果明天进行审计，你们能拿出什么证据，其中有多少是重建出来的，而不是现成的记录？
可复现构建、SBOM 和来源信息如何改变了你们的审计能够自动验证的内容？

关键要点

SCM 控制的是整个配置（代码、依赖项、基础设施和配置数据），而不仅仅是源代码。
基线是不可变的参照点；变更是针对基线被授权和记录的，而不是被阻止的。
状态记账必须让你在任何时刻都能回答一次发布包含什么、以及它是如何形成的。
审计验证的是所构建和交付的内容与记录在案的配置以及经批准的需求相符。
按风险分层控制，并把识别、记账和审计自动化，让记录成为交付的副产品。

参考资料与延伸阅读

IEEE Computer Society, SWEBOK Guide (Guide to the Software Engineering Body of Knowledge), Software Configuration Management knowledge area
IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
ISO/IEC/IEEE 12207, Systems and software engineering: Software life cycle processes (configuration management process)
Jez Humble and David Farley, Continuous Delivery
Bob Aiello and Leslie Sachs, Configuration Management Best Practices: Practical Methods that Work in the Real World
NIST guidance on software supply chain security, software bills of materials (SBOM), and artifact provenance
CNCF and open standards for build provenance and attestation (as reference frameworks)