应用程序版本管理与镜像打标相关技术问询

应用技术栈 #

• NextJS
• Docker（含Docker Compose）
• GitHub Actions（CI/CD）

1. 应用程序版本升级的最佳时机与操作位置 #

时机分两种场景：

• 常规功能迭代/BUG修复：在开发分支完成所有功能测试、代码评审通过后，合并到主分支前执行版本升级。此时版本号的变更能准确对应本次迭代内容，且不会干扰未完成的开发工作。
• 重大依赖版本升级（如NextJS大版本更新）：单独创建升级分支，完成兼容性适配、全量测试后，选择业务低峰期合并到主分支并触发发布，避免生产环境出现兼容性故障。

操作位置：

• 核心操作是更新代码仓库中的版本配置文件（如NextJS项目的package.json），确保版本号与迭代内容匹配；
• 若Docker镜像版本与应用版本强关联，需同步更新docker-compose.yml或镜像构建脚本中的版本标识。

2. Docker镜像打标：语义化版本还是提交哈希？ #

不需要二选一，建议两者结合使用：

• 语义化版本（如v1.2.3）：用于预发布、生产环境。符合行业通用规范，能直观反映版本迭代层级（主版本/次版本/补丁），方便运维、业务团队快速识别版本对应的功能或修复内容，同时与package.json的版本号保持一致，便于溯源。
• 提交哈希（如abc1234）：用于开发、测试环境。每个提交对应唯一哈希值，不存在标签覆盖风险，能精准定位镜像对应的代码版本，方便排查测试阶段的问题，尤其适合频繁迭代的日常开发场景。
• 实操示例（GitHub Actions中）：

  docker build -t my-nextjs-app:${SEMVER_VERSION} -t my-nextjs-app:${GITHUB_SHA::7} .
  

3. PR合并前手动升级版本，还是CI阶段自动执行？ #

根据版本类型选择：

• 正式发布版本（如v1.2.0）：建议手动在PR合并前升级。版本号的变更需要人为确认合理性（比如判断是主版本、次版本还是补丁升级），同时在PR描述中说明版本升级的原因，确保团队全员知晓，避免版本号冲突或误发布。
• 日常测试/快照版本：建议通过GitHub Actions自动执行。借助semantic-release等工具，结合约定式提交规范（如feat:对应次版本升级、fix:对应补丁升级），自动生成版本号、更新package.json、打Git标签并构建镜像，减少手动操作的繁琐与人为错误。

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