1. 课程导入

软件定义汽车（Software-Defined Vehicle，SDV）把汽车从“以硬件为中心”的机械产品，转变为“可持续交付软件能力”的移动计算平台。随之而来的核心问题不再是“某个功能能不能实现”，而是“这个功能从需求到量产、从量产到售后、从售后到报废，如何被持续、可控、可追溯地交付与治理”。这正是本课程要解决的主线：服务生命周期与版本治理。

本课程的学习目标可以概括为四个层次：第一，理解 SDV 中“服务”作为软件交付单元的定义与边界；第二，掌握服务从设计、开发、集成、验证、发布、运营到退役的完整生命周期；第三，建立版本治理的工程能力，包括版本命名、依赖锁定、灰度发布、回滚与合规审计；第四，能够把上述能力落到具体工具链与流程中，形成可复用的工程实践。

核心概念：服务、生命周期与版本治理

在 SDV 语境下，服务（Service）通常指一个可独立部署、可被其他组件调用的软件能力单元，例如座舱语音服务、车身控制服务、OTA 升级服务、诊断服务等。服务具有接口、版本、依赖、配置和运行状态。与传统的 ECU 固件不同，服务可以跨域部署、动态编排，并且需要与整车网络、云端和诊断系统协同。

生命周期（Lifecycle）描述服务从“想法”到“退役”的全过程。典型阶段包括：需求与架构设计、开发与单元测试、集成与系统验证、发布与部署、运营与监控、迭代与退役。每个阶段都有明确的输入、输出、准入准出条件和责任人。

版本治理（Version Governance）则是对“版本”这一核心资产进行管理：谁可以发布版本、版本如何命名、依赖如何锁定、变更如何评审、发布如何灰度、问题如何回滚、历史如何审计。版本治理的目标是让每一次软件变更都可解释、可追溯、可回退。

整体框架：从服务到治理的闭环

本课程的整体框架可以理解为一个“三层闭环”：最底层是服务资产层，包括服务定义、接口契约、版本仓库和配置基线；中间层是生命周期流程层，覆盖设计、开发、验证、发布、运营和退役；最上层是治理与度量层，包括版本策略、发布门禁、合规审计和运营指标。三层之间通过数据流和决策流连接，形成持续改进的闭环。

上图展示了本课程的整体框架。需要特别注意的是，三层之间不是单向的“瀑布”，而是带有反馈的闭环：治理层通过门禁和指标约束流程层，流程层产生的数据又反哺资产层和治理策略。

方法流程：一次服务变更的完整路径

为了把抽象框架落到工程实践，我们以“一次服务变更”为例，说明从需求到退役的典型路径。假设需要为某车型新增“远程空调预启动”服务，流程如下：

1. 需求与设计：明确服务边界、接口契约、性能指标和安全等级，输出服务设计文档与接口定义。
2. 开发与单测：在服务仓库中创建特性分支，完成编码与单元测试，生成候选版本号。
3. 集成与验证：将服务部署到集成环境，执行接口测试、系统测试和整车在环测试，记录测试报告。
4. 发布与灰度：通过发布门禁后，先向小批量车辆灰度推送，观察关键指标，再逐步扩大范围。
5. 运营与监控：采集服务调用成功率、时延、资源占用和故障日志，形成运营看板。
6. 迭代或退役：根据运营数据决定迭代新版本，或在下线时归档版本、清理依赖并保留审计记录。

在这个过程中，版本治理贯穿始终。每一次变更都必须关联需求编号、变更单、测试报告和发布记录，形成完整的追溯链。

案例场景：没有版本治理会发生什么

某项目在早期为了快速交付，采用了“谁开发谁发布”的方式，版本号随意命名，依赖关系靠口头约定。结果在一次 OTA 升级中，座舱服务的新版本依赖了尚未发布的语音服务接口，导致部分车辆语音功能不可用。由于没有版本锁定和回滚策略，团队花了数小时才定位到问题版本，并手动回退。

这个案例说明，版本治理不是“大公司才需要”的重型流程，而是 SDV 规模化交付的基础设施。越早建立，后期成本越低。

课程路线图与关键清单

本课程共 30 章，整体路线遵循“概念—流程—工具—治理—实战”的递进结构。前段建立服务生命周期与版本治理的认知框架；中段深入设计、开发、验证、发布和运营各阶段的具体方法；后段聚焦版本策略、合规审计、度量体系和典型故障复盘。下表给出课程的核心模块与关键产出。

在学习方法上，建议每章都带着三个问题阅读：这个阶段解决什么问题？输入和输出是什么？如果缺失会导致什么后果？同时，尽量把课程中的模板、清单和参数映射到自己所在项目的实际场景中，形成可落地的工程资产。

# 版本治理最小检查清单
1. 版本命名是否符合语义化规范（主版本.次版本.修订号）？
2. 依赖是否锁定到具体版本，是否存在浮动依赖？
3. 发布前是否通过门禁（测试、安全、合规）？
4. 是否具备灰度发布与回滚预案？
5. 变更是否关联需求、测试报告和发布记录？
6. 审计日志是否完整、可追溯、可导出？