Teamcity 每周发布版本控制和工作流程答案

【问题标题】：Teamcity Weekly Release Versioning and WorkflowTeamcity 每周发布版本控制和工作流程
【发布时间】：2011-12-10 13:47:20
【问题描述】：

我正在尝试在 TeamCity 中启动并运行每周版本，但我很难理解我将如何对其进行版本化。目前版本控制如下

[major].[minor].[buildnumber].[svnrevision]  

major = major release  
minor = incremented on release (weekly-basis) to production  
buildnumber = teamcity's autoincremented build number  
svnrevision = revision number from svn

这是否意味着每周，在创建标签后，我必须为新版本创建单独的构建配置，这样我才能像这样增加次要版本？

1.1.{0}.%build.vcs.number.*%

到

1.2.{0}.%build.vcs.number.*%

并将trunk 中的新构建配置 指向tags\release-1.1.0 文件夹？

没有更简单的方法吗？

【问题讨论】：

我不明白为什么您在标记构建后会从主干指向标记。您不想继续在主干上开发并从中构建吗？
已编辑。我的意思是将我为标签创建的新构建配置指向发布文件夹。

标签： build-process versioning teamcity

【解决方案1】：

我想我有点困惑，为什么随着代码库版本号的变化，你会将构建配置从主干更改为标签/发布文件夹。

如果我这样做，我只需创建一个从主干构建的配置。每周一次，您可以在 TeamCity 配置屏幕中将版本号从 1.1.x.x 提升到 1.2.x.x，然后继续从主干构建。下周你将它升级到 1.3.x.x 并继续从主干构建。

通常这些标签只是为了及时快照，它是用于及时进行特定构建的确切来源。我希望您的标签构建文件夹看起来更像 \tags\release-1.1.232.3232 等。

有时您可能需要使用特定标签并从中创建一个分支。也就是说，如果您需要在发布下一个版本（来自trunk）之前对以前的版本进行一些错误修复。在这种情况下，我将创建一个新配置来进行分支构建，代码库将类似于 \branches\release-1.1.0

现在您有一个主干配置，该配置可能是 1.2 或 1.3，并且会不断增加，而分支配置将是 1.1 或类似的配置。稍后您可能会将分支配置用于另一个版本号，因为错误修复是在 1.1 中完成的，就像您使用标签建议的那样。

在我看来，再读一遍，也许你使用分支的概念作为标签......

【讨论】：

我并没有完全改变。在这种情况下，我维护了两个构建配置，当需要发布错误修复时，我会从标签分支，然后将更改合并回它。然后构建配置在我的标签文件夹上运行。我的工作流程需要改变吗？
您需要更改的是让构建配置从分支而不是标签文件夹运行。正如我之前指出的那样，标签应该只是及时的快照（一旦制作它们就不应更改）。分支用于进行与主干不同的开发。如果您从标签创建分支，则永远不要在标签上检查它。看看这里的第一个答案 - stackoverflow.com/questions/16142/…
射击。我一直都做错了。我之前读过那篇文章，但将标签理解为我之后构建的快照。感谢您的指正。但是，增量是否仍然是一项手动任务？
就像你说的，现在你有一个主干配置和一个分支配置。我每周都会手动更新未成年人。分支配置可能落后一个版本，也可能不是一个版本？

【解决方案2】：

在 TeamCity 6 及更高版本中，您可以有多个构建步骤。

您可以在实际构建之前创建一个初始构建步骤，该步骤使用自定义 MSBuild 任务。这将检查所有项目链接到的全局 AssemblyInfo.cs 文件（有关更多详细信息，请参阅Automatic assembly version number management in VS2008），从文件中获取版本号，增加次要修订，写回新值，并签入更新的文件。

额外的构建步骤将运行构建和标记。

您可以使用服务消息从构建脚本向 TeamCity 传达更新，包括报告内部版本号，请参阅http://confluence.jetbrains.net/display/TCD65/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber

【讨论】：

teamcity如何从文件中获取版本号？
答案已更新。我肯定会走这条路线来保持流程自动化，否则如果您必须每周手动更改构建版本，维护可能会变得难以忍受。