根据版本标签限制部署到特定环境

Question

我正在使用 TFS 完成我的 CI 设置，我还有最后一部分需要克服。目前，每个 CI 构建都被推送到 octopus，nuget 包的版本为 major.minor.patch.buildid，这些在 Octopus 版本中使用的版本为 major.minor.patch-beta{buildid}。因此，每个 CI 构建都将被标记为给定版本的 beta 构建，例如1.3.0.194 / 1.3.0-beta194。毫无疑问，在选择一个去测试团队之前会有许多迭代的开发构建——让我们假设在这种情况下选择的构建是 194。在这一点上，我设想创建一个新版本 1.3.0-rc1，它使用 build 194 二进制文件。然后将其推送到测试环境并开始测试。可能有多个测试周期，假设测试人员签署了 1.3.0-rc4 版本。然后可以基于 1.3.0-rc4 二进制文件制作新版本 1.3.0，这是该产品的黄金版本。

首先，这是个好主意吗？一些反馈将不胜感激。

另外，是否可以根据版本中的标签将部署限制在某些环境中？在我的示例中，我绝不希望将标记为 -beta 的版本部署到测试环境中 - 应该只有 -rc 构建。同样，只有无标签的构建应该部署到生产环境中。

Answer 1

这就是你绝对不应该这样做的原因。

当您创建 1.3.0.194 版本时，Octopus 将保证为工件、流程和变量提供快照，这意味着部署将以相同的方式在每个环境中执行。

您可以随心所欲地编辑这些内容，但 1.3.0.194 不会因为这些更改而成为风险更大的部署，因为它会忽略它们。

如果您创建了版本 1.3.0.194，然后对部署过程或变量进行了更改，这些更改将泄漏到版本 1.3.0.194-beta 中，并且不再是您测试过的同一部署。当您更改为 1.3.0.194-rc 版本时也会发生同样的情况 - 更多更改会泄漏到您尚未实际测试过的情况中。

您的部署过程，就像您的代码一样，应该进行版本控制和测试 - 这就是您在整个部署生命周期中使用相同版本所获得的结果。

Answer 2

使用 beta/rc 标记部署包是个坏主意，因为这会在您的交付过程中引入一个额外的步骤。您将拥有许多内置版本，有些会升级到高级环境，有些则不会。没关系。您尝试将这些视为用于依赖项版本控制/管理的常规 Nuget 包。这是不同的。只需在不带标签的情况下增加您的内部版本号并推广已签署的内部版本。

您也不应该将部署限制在基于标签的环境中。