Azure Pipelines推送类库至NuGet的正确流程咨询

你的流程逻辑完全正确，这种“构建流水线负责预发布包推送+工件留存，发布流水线负责正式版发布”的模式，是适配Azure Pipelines架构的最佳实践之一，核心是把验证环节和正式发布环节做了清晰隔离，降低发布风险。

各阶段的细节优化建议 #

• 构建流水线阶段
  • 打包时用dotnet pack结合内置变量生成唯一预发布版本号，比如1.0.0-ci.$(Build.BuildId)或1.0.0-preview.$(Build.SourceBranchName)，确保每个预发布包可追溯到具体构建。
  • 推送预发布包后，建议立即触发自动化测试（集成测试、依赖项目兼容性测试），验证包的功能完整性，避免正式发布后踩坑。
  • 留存.nupkg作为工件时，要保留完整的版本信息，别只存文件，方便发布流水线直接复用。
• 发布流水线阶段
  • 发布流水线需绑定构建流水线的成功事件，并且必须加手动审批——只有预发布包验证通过、产品确认可以发布时，再执行正式推送。
  • 正式版本号建议手动指定（发布时输入1.0.0），或者用Git Tag同步版本，别自动生成，防止版本混乱。
  • 推送正式包时直接用构建流水线留存的工件，不要重新打包，避免两次构建生成的包不一致。

额外注意事项 #

• 预发布包和正式包可通过版本标识区分（比如带-preview后缀），如果有条件，也可以用不同的NuGet源分开存放，避免预发布包被误用作正式依赖。
• 提前配置好Azure Pipelines的NuGet服务连接，确保推送时权限验证正常，避免因权限问题导致推送失败。
• 可以在构建阶段添加代码签名步骤，对预发布包和正式包进行签名，提升包的可信度。

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