ASP.NET Core项目中App.Core NuGet包的QA与生产版本管控问题

针对你遇到的App.Core包并行开发导致生产发布混入未测试变更的问题，以下是几个比Git Flow更适配Azure DevOps和NuGet生态的方案：

1. 语义化版本+预发布后缀的精准版本控制 #

• 给App.Core启用严格的语义化版本规则，每个开发者的特性分支对应专属预发布后缀：比如开发者1的分支版本用1.5.0-dev.user-table，开发者2的用1.5.0-qa.order-index
• Azure DevOps流水线配置：QA环境仅拉取带-qa后缀的预发布包，生产环境只拉取无预发布后缀的正式版本
• 开发者2完成QA验证后，将其分支合并到主分支，发布正式版本1.5.0，生产流水线直接引用该正式版本，完全隔离开发者1的未测试预发布包

2. Azure Artifacts视图隔离机制 #

• 在Azure Artifacts中为App.Core包创建三个层级视图：
  • @Local：所有新构建的包自动进入此视图，供开发调试使用
  • QA-Approved：仅允许通过QA测试的包进入（可通过Azure DevOps流水线自动触发提升，或手动审核）
  • Production-Ready：仅允许经过最终生产验证的包进入
• 生产流水线配置为仅从Production-Ready视图拉取App.Core包，确保只有完全验证的版本被部署到生产

3. 特性分支绑定的独立包构建 #

• 每个开发者的特性分支独立构建App.Core包，包版本包含分支唯一标识（比如1.5.0-feature-[分支名]）
• QA环境部署时，针对不同特性测试任务绑定对应的分支包版本，测试通过后再将该分支合并到生产发布分支
• 生产流水线仅基于生产发布分支构建App.Core包，或拉取该分支对应的包版本，彻底避免混入其他未测试分支的变更

额外补充：数据库变更的版本对齐 #

因为你没有使用EF Core Code First迁移，建议给每个App.Core包版本附带对应版本的数据库变更脚本，脚本命名和包版本严格一致（比如script-1.5.0.sql）。生产发布时，仅执行当前部署包对应的脚本，确保数据库变更和代码版本完全匹配。

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