应用代码与对应配置、基础设施的版本映射管控方案咨询

背景与可选仓库结构 #

我们现有两个服务：

• Service A：包含应用代码、环境配置、基础设施依赖（队列、数据库等）
• Service B：包含应用代码、环境配置

参考DevOps最佳实践，有两种Git仓库结构可选：

方案1：服务独立单仓（全内容聚合） #

- Service A
    src
    config
    infra
- Service B 
    src
    config
    infra

方案2：代码、配置、基础设施分离仓 #

- Service A
    src
- Service B
    src
- Config（含跨服务通用配置及服务专属配置）
     common.yml
     - service A
       application.test.yml
       ...
     - service B
       application.dev.yml
- Infra
     env

核心痛点 #

技术共识是将代码与环境配置（.env文件）分离，但面临两个关键问题：

1. 版本绑定需求：比如v2.0.0的应用代码依赖AWS SQS，对应配置要包含SQS参数、基础设施模板要包含SQS的CloudFormation配置；v3.0.0切换为Kafka后，配置和基础设施也要同步匹配，需要实现三者的版本强绑定。
2. 跨团队协作适配：基础设施由不同团队维护，单仓方案无法适配各自的维护流程。

落地解决方案 #

1. 服务级单仓+统一版本标签（优化方案1） #

给每个服务单独建仓（保持方案1的结构），每次发布时给服务仓打统一版本标签，比如v2.0.0-serviceA，这个标签同时覆盖src、config、infra目录的内容。

• 优势：服务内的代码、配置、基础设施天然绑定，版本追溯直接看标签即可。
• 适配跨团队：基础设施团队可以在服务仓的infra目录中存放指向基础设施团队主仓特定版本的引用文件（比如infra-version.txt，内容为基础设施仓的标签v2.0.0-sqs-template），服务发布时同步引用该版本的基础设施模板，既满足服务与基础设施的版本绑定，又不干涉基础设施团队的独立维护流程。

2. 分离仓版本关联机制（适配方案2） #

如果坚持用代码、配置、基础设施分离的结构，通过版本映射文件实现三者绑定：

• 在每个服务的src根目录添加version-bind.yml，内容示例：

  app-version: v3.0.0-serviceB
  config-version: v3.0.0-serviceB-config
  infra-version: v3.0.0-kafka-template
  

• 配置仓和基础设施仓各自独立打版本标签，服务发布时，通过CI/CD工具读取version-bind.yml中的版本号，拉取对应版本的配置和基础设施模板进行部署。
• 跨团队协作：基础设施团队维护自己的仓并打标签，服务团队只需在version-bind.yml中指定所需的基础设施版本，无需介入基础设施团队的流程。

3. CI/CD流水线强绑定 #

不管用哪种仓库结构，在CI/CD流水线中加入版本校验步骤：

• 部署前检查应用代码版本、配置版本、基础设施版本是否匹配预设的映射规则（比如从版本号前缀判断一致性：v2.0.0-*必须对应绑定）。
• 若不匹配则终止部署，避免出现版本不兼容的情况。

内容的提问来源于stack exchange，提问作者user14013917