基于Serverless框架开发的微服务如何实现CI/CD自动版本管理

首先你可以根据团队的服务耦合度，先确定版本管理的基础规则：

1. 版本号规范 #

采用通用的语义化版本规则主版本号.次版本号.修订号，不同环境追加对应标识做区分：

• Develop环境：追加-dev.构建序号后缀，例：2.1.3-dev.142
• Staging环境：追加-beta.构建序号后缀，例：2.2.0-beta.76
• 生产环境：不追加后缀，正式发布版本，例：2.2.0

2. 版本管理策略选择 #

结合你当前的单体仓多服务结构，二选一即可：

• 统一版本管理：所有服务共用同一个版本号，存放在根目录package.json的version字段中，适合服务之间耦合度高、每次发布需要同步上线的场景，操作成本最低。
• 独立版本管理：每个服务的版本号存放在各自目录下的package.json的version字段中，只有对应服务的代码发生变更时才升级该服务的版本，适合服务耦合度低、迭代频率差异大的场景，节省不必要的构建资源。

3. CI/CD 流水线自动升级逻辑 #

直接在你现有的CodePipeline+CodeBuild流程中加三步即可：

步骤1：变更检测 #

流水线触发后，先对比当前Commit和上一次成功构建的Commit，判断src/services下哪些服务的目录有代码变更，生成待升级版本的服务列表。如果是统一版本管理，这一步可以跳过，每次触发直接升级全量版本。

步骤2：自动生成版本号 #

按分支规则自动生成对应版本：

• 从Feature合并到Develop分支：自动升级修订号，拼接Dev环境后缀和当前CodeBuild的构建序号
• 从Develop合并到Staging分支：默认升级次版本号，若Commit信息包含fix:前缀的热修复内容则升级修订号，拼接Staging环境后缀和构建序号
• 从Staging合并到Master分支：直接使用Staging分支对应版本号，去掉环境后缀即可；如果Commit信息包含BREAKING CHANGE标识，自动升级主版本号

步骤3：版本持久化 #

自动将生成的版本号写入对应package.json文件，可选择将版本变更Commit回对应分支，Commit信息带上[skip ci]标识避免触发重复构建；同时将版本号、对应Commit哈希、部署环境等信息写入Lambda的环境变量、API网关的阶段变量或者AWS Parameter Store做留存，方便后续线上问题溯源。

4. 可选配套优化 #

如果需要自动生成变更日志，可以要求团队提交代码时遵循Conventional Commit规范（feat:/fix:/docs:等前缀），CodeBuild构建时自动解析Commit信息生成对应服务的CHANGELOG文件，和版本一起归档即可。

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