八达通部署-多通道管理版本号

Question

我们刚刚开始使用八达通部署。

我们有三个频道

• Beta ( QA生命周期)不能进一步推广)
• 稳定(全生命周期-可升级到UAT，分期和生产)
• 修补程序(生命周期可以跳过任何环境)

是否有一种方法，使每个通道创建不同的版本号，但使用相同的种子其数字？

即

• Beta增量修改+有通道名称：1.0.1-beta、1.0.2-beta、1.0.3-beta等
• 稳定增量次要：1.1.0、1.2.0、1.3.0等
• 修补程序增量修改：1.1.1、1.1.2、1.1.3等

虽然这在我看来是可取的-是否有理由不这样做呢？

Answer 1

使用部署自动化，您希望在部署之间保持尽可能多的相同--八达通有助于实现这一点。

例如，Octopus将对发行版的过程、变量和包进行版本化，这样对这些版本的更改就不会在整个发行版的整个生命周期中适用。

因此，当您将代码的1.1.0弹到Octopus中时，它会生成1.1.0版本，并快照该版本的流程和变量，从而将它们与任何更改隔离开来。

如果您上传代码的1.1.0BETA，然后决定“它是发布的候选版本”，那么您将上传1.1.0，它将是不同的代码、不同的版本以及流程和变量的不同快照。然后，您将不得不从零开始贯穿整个生命周期。如果您已经在1.1.0测试版上执行了测试，那么这在1.1.0中是无效的--所以您必须重复工作。

按照“开箱即用”的方式，您可以上传1.1.0并将其流过QA环境，或者将其作为一个不好的发布阻止它，或者将其作为一个好版本来推广--确保所有事情都是一致的，并且您只需要做一次。

你能用另一种方式管理"BETA“、"RC”和"RTM“的标签吗？

Answer 2

您应该使用构建服务器对包进行版本化(比如Jenkins、TFS.)有很多插件和格式模板用于版本控制。特别是八达通是一个部署工具，而不是版本控制工具。

与Jenkins MSbuild (Jenkins构建章鱼部署给我)

• 2016.4.28.2-dev
• 2016.4.28.1-main
• 2016.3.25.1-hotfix ${BUILD_YEAR}.${BUILD_MONTH}.${BUILD_DAY}.${BUILDS_TODAY}-branchname

与TFS构建开放TFS构建定义过程，打开高级并检查“版本号格式”您应该使用这个。

$(Date:yy.MMdd.HH.mm)

Answer 3

“有理由不这样做吗？”是的有。您希望“八达通”强制执行与哪个频道一起使用的版本。章鱼通道使用基于版本范围和SemVer标记的版本控制规则进行控制。您的两个通道在SemVer术语中是不可区分的，因此需要更改包版本号格式以允许通道版本规则工作。在这种基础上，实现您想要的将意味着发布版本号与包版本号不相对应(如果您从包的版本号中获得版本号，这对我来说一直是明智的选择，以避免在两个地方管理版本号，而且我还假设您同意发行版1.2.3包含具有相同版本号的包是明智的)。但是，在发布版本号上稍作让步，您可以接近您想要的.

您的Beta通道很好，没问题:在该通道的版本规则上给出beta的预发布标记。但问题在于区分这两种情况：

• 稳定增量次要：1.1.0、1.2.0、1.3.0等
• 修补程序增量修改：1.1.1、1.1.2、1.1.3等

遗憾的是，不可能根据整个版本号创建规则(例如，使用正则表达式：\.0$)。我们希望这条规则和你完全一样。因此，除非您愿意手动为每个可能的版本添加一个以.0结尾的版本规则(我假设不是.)那麽，我们必须作出一个小小的让步，以配合八达通的需要。

您需要选择这两个通道中的一个来拥有SemVer预发布标记，就像Beta一样。假设我们向-hotfix修补程序版本添加了一个后缀。然后，您需要为热修复通道设置版本规则，以便将hotfix作为预发布标记。您必须更改稳定的通道，使其具有^$的版本规则(意味着没有标记)，以防止该通道中使用其他通道的版本。

上面的内容为您提供了您想要的东西，但所有修补程序发行版都有一个-hotfix后缀，这是一个小小的让步。如果版本号不是测试版，并且不以.0结尾，那么很容易获得自动构建来决定在创建包时添加该后缀。