我正在用TFS完成我的CI设置，我还有最后一部分需要克服。目前，每个CI构建都被推送到章鱼，其中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，它使用构建194二进制文件。然后将其推送到测试环境并开始测试。可能存在多个测试周期，因此我们假设测试人员签署版本1.3.0-rc4。然后可以基于1.3.0-rc4二进制文件制作新版本1.3.0，这是该产品的黄金版本。
首先，这是一个好主意吗？一些反馈将非常感激。
单独地，是否可以根据版本中的标记将部署限制到某些环境？在我的示例中，我永远不会希望将标记为-beta的版本部署到测试环境中 - 只应该使用-rc构建。同样，只应将无标记版本部署到生产环境中。
答案 0 :(得分：2)
这就是你绝对不应该这样做的原因。
当您创建版本1.3.0.194时，Octopus将保证伪像，流程和变量都是快照，这意味着部署将在每个环境中以相同的方式执行。
您可以根据需要编辑这些内容，但由于这些更改，1.3.0.194不会成为更具风险的部署，因为它将无视它们。
如果您创建了版本1.3.0.194，然后对部署过程或变量进行了更改，则这些更改将泄漏到版本1.3.0.194-beta中，并且它将不再是您测试的相同部署。当您更改为版本1.3.0.194-rc时会发生同样的情况 - 更多的更改会泄漏，因为您尚未进行实际测试。
您的部署过程就像您的代码一样，应该进行版本化和测试 - 这就是您在整个部署生命周期中使用相同版本所获得的。
答案 1 :(得分：1)
使用beta / rc标记部署包是一个坏主意，因为这会在您的投放过程中引入额外的一步。你将拥有许多内置版本，有些版本会升级到上层环境，有些版本不会。没关系。您尝试将这些视为用于依赖版本控制/管理的常规Nuget包。这不一样。只需在不使用标记的情况下增加构建数字，并提升已签名的构建。
您不应该基于标记限制部署到环境。