我如何将预发布版本推广到生产环境，并嵌入新版本，而无需重新构建？

Posted 2023-02-19

【中文标题】我如何将预发布版本推广到生产环境，并嵌入新版本，而无需重新构建？

【英文标题】：How can i promote a pre-release build to production, and have the new version embedded, without a rebuild?

【发布时间】：2021-12-03 03:10:03

【问题描述】：

八年后，我遇到了与 nuget feeds and promotions 相同的问题！

在这种情况下，我说的更笼统；我们使用 ProGet 作为我们的包管理器，并且在包推广过程中需要考虑 nuget、通用包，甚至一些 docker 容器。

其中一个想法是拥有多个 Nuget 提要；一个 ci 提要，每个成功的集成都会发布一个包，一个 qa 提要，您只发布您希望 qa 测试的版本，然后是一个发布提要，您只从他们成功测试的 qa 提要中复制包。

假设我们在ci 提要中有一个可以运行的版本，它的版本是1.2.3-ci-xyz。我们希望将其推广到 QA 提要，无需重新构建，并将其重新打包为 1.2.3-rc-1。该软件包通过了 QA 并准备好被提升到 prod 提要中，无需重新构建并交付生产。它应该以1.2.3 的形式发货。 （对吧？）

问题是，如果我们不进行任何重建，软件包二进制文件的版本仍将是 1.2.3-ci-xyz。这将显示在应用中显示或查询版本的任何位置。

这就是我卡住的地方。这里的正确模式是什么？只要我们知道它是什么版本，发布什么版本有关系吗？

意思是，我们将1.2.3-ci-xyz从低级提要提升到高级提要，而不用不同版本重新打包？ 包1.2.3 包含二进制1.2.3-ci-xyz 会不会不正确？ 我们是否总是使用下一个 3 位数字构建，而忘记了 ci/rc 后缀？

【参考方案1】：

我将从我们的内部支持渠道分享这个答案:)

这就是我们 (Inedo) 通常在我们的库中处理此问题的方式。简短的回答是：

我们将程序集版本设置为 Major.Minor.Patch 我们将程序集文件版本设置为 Major.Minor.Patch.Build 我们将包版本设置为 Major.Minor.Patch-ci.Build（然后我们重新打包为 Major.Minor.Patch-rc.Build，然后重新打包为 Major.Minor.Patch） 我们还使用 Assemble Informational Version 来显示友好的版本（例如：版本 6.0.0 (Build 36-v6)）

这允许我们在不重新构建的情况下重新打包。我们还将在产品构建期间检测这些预发布依赖项，并防止它们被发布到生产环境中。您可以查看我们的 ProGet v6 构建示例：ProGet 6.0.0 Build 36。

我觉得较长的答案在我们的博文Best Practices for Versioning NuGet Packages in the Enterprise 中得到了很好的回答。