4. 版本控制策略：特征定义、工程代码、模型版本与部署配置的统一管理

在信用评分特征服务中，版本控制不仅是代码管理，更是对特征定义、特征工程代码、模型版本以及部署配置这四类资产的协同管理。任何一方的版本漂移都可能导致线上推理结果与离线训练不一致。本节采用 Git Flow 分支模型配合 语义化版本控制（SemVer），建立可追溯、可回滚的多环境版本管理体系。

4.1 四类版本资产的划分与标识

首先明确需要纳入版本控制的四类资产及其存储位置：

4.2 Git Flow 分支模型适配

针对信用评分特征服务的多环境特点，对标准 Git Flow 做如下适配：

• main 分支：仅存放已通过生产环境验证的稳定版本，每个 commit 对应一个可发布的语义化版本。
• develop 分支：集成开发分支，包含下一个迭代的所有已完成特性。
• feature/* 分支：从 develop 拉出，用于开发新特征定义或工程代码。合并回 develop 前需通过单元测试与特征一致性校验。
• release/* 分支：从 develop 拉出，用于准备发布。在此分支上只做 bug 修复和文档更新，不引入新功能。完成后合并到 main 和 develop。
• hotfix/* 分支：从 main 拉出，用于紧急修复生产环境问题。修复后同时合并到 main 和 develop。
• env/* 分支（扩展）：从 release 或 main 拉出，用于特定环境的配置微调，例如 env/staging、env/production。这些分支仅包含部署配置的差异，不包含代码逻辑变更。

4.3 语义化版本控制（SemVer）

对特征定义和特征工程代码采用 MAJOR.MINOR.PATCH 格式：

• MAJOR：不兼容的 API 或特征语义变更。例如：删除某个核心特征、改变特征计算逻辑导致输出分布发生根本变化。
• MINOR：向下兼容的新增功能。例如：新增一个可选特征、增加新的分箱策略。
• PATCH：向下兼容的 bug 修复或性能优化。例如：修复空值处理逻辑、优化计算效率。

对于模型版本，建议采用 日期+序号 格式（如 r20250315_001），因为模型迭代频率高且不涉及 API 兼容性概念。部署配置则跟随其引用的特征定义版本和模型版本，使用 deploy_cfg:<feature_version>_<model_version> 的复合标识。

4.4 版本关联与追溯

在信用评分场景中，一次完整的发布需要锁定四类资产的版本组合。推荐在部署配置中显式声明依赖：

# deploy_config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: credit-scoring-feature-service
data:
  feature_definition_version: "feature_def:v2.1.0"
  feature_engine_code_version: "feat_eng:v1.3.2"
  model_version: "model:r20250315_001"
  environment: "production"

4.5 多环境版本映射

不同环境（开发、测试、预发布、生产）通常运行不同版本的组合。下表展示了一个典型的多环境版本映射：

4.6 版本控制流程总结

下图展示了从特征定义变更到生产发布的完整版本控制流程：

4.7 常见问题与避坑指南

• 特征定义与代码版本不同步：特征定义仓库更新后，特征工程代码仓库未及时合并对应逻辑。解决方案：在 CI 中加入跨仓库的版本兼容性检查。
• 模型版本与特征版本解耦：模型训练时使用的特征版本与线上推理时使用的特征版本不一致。解决方案：在模型注册时记录训练所用的特征定义版本号，并在部署时强制校验。
• 部署配置中的版本号写死：导致无法快速回滚。解决方案：使用环境变量或配置中心动态注入版本号，保留历史配置快照。
• hotfix 分支未同步到 develop：导致下次发布时修复内容丢失。解决方案：在 hotfix 合并到 main 后，强制要求合并回 develop。