如何在C#中自动生成TeamCity版本？

Question

我想知道如何自动化使用当前TeamCity构建服务器构建的.Net/NuGet项目的版本控制。

我现在要做的是:我的C#解决方案是在一个存储库中检查的，我有(并且希望保留)两个构建作业:稳定的和实验性的。在master分支上提交触发一个稳定的构建，在所有特性分支上提交触发一个实验性构建。在最终将其合并回主版以触发下一个稳定版本之前，我使用特殊的分支master-dev来积累更改。

当涉及到对我的项目进行版本控制时，我使用以下版本控制方案：«major».«minor».«buildnum»用于稳定构建，«major».«minor».«buildnum»-Experimental用于实验性构建。到目前为止，我在系统变量中设置了主要版本和次要版本，使用“AssemblyInfo修补程序”构建特性对AssemblyInfo.cs进行相应的修补，并将版本作为参数传递给“NuGet包”构建步骤。

• 这两个工作之间并没有同步，增加的速度要快得多。每当我发布一个稳定的版本，我基本上必须“降级”所有用户的实验版本稳定的版本，因为前者是严格较高的。
• 在每次稳定发布后，必须在TeamCity中更新版本号。

为了简化我的工作流程，如果我可以这样做的话，那就太棒了：( a)自动同步两个作业之间的版本号；( b)在每次“稳定”构建之后自动更新次要版本。最优情况下，我还希望将版本号存储在存储库中(而不是维护TeamCity变量)。就像Maven部署/版本插件一样，“稳定”构建作业需要更新版本并将更改推送到存储库(而不触发新构建)。

我既没有为我找到一个解决这些烦恼的工具(也许可以为此目的开发一个定制的TeamCity插件)，我也没有找到任何关于如何以不同的方式解决这些版本控制问题的真正建议(…)。我错过了显而易见的事情吗？在TeamCity中简化/自动化.Net/NuGet构建版本的其他最佳实践是什么？

谢谢你的指点！

Answer 1

我喜欢使用的一种模式是在构建之前使用powershell脚本更新SolutionInfo或AssemblyInfo文件。然后，当构建完成时，提交已更改的文件。

在更新文件、更新文件、然后立即提交更改以帮助最小化由并行构建剪切版本号的风险之前更改该模式并不困难。

我见过一些人说，您不应该让构建服务器提交到源代码，但我不同意。在源中拥有版本号意味着您所需要的一切都在源中。

Answer 2

您所寻找的是可能的，但是您需要编写一些代码来实现它。

我使用类似于扭曲的mentat的模式，但没有将版本号返回到修订控制中。

根据项目的不同，我有一个C#程序、批处理脚本或powershell脚本，用于更新所有程序集和二进制文件的版本号。我将这些脚本保存在一个名为工厂的文件夹中的项目的修订控制中。通常在名称uvn.extension (例如unv.ps1)下，uvn代表更新版本号。

通常，我使用的版本格式是<major>.<minor>.<patch>.<revision>，其中修订是最后一次提交编号。但是，在修订控制中，<revision>数字总是设置为零。

当新版本的时间临近时，我将使用新版本手动运行uvn.ps1，将<revision>数字设置为零，并将更新文件提交到修订控制中。

对于TeamCity，第一个构建步骤是运行uvn脚本。对于TC构建步骤，以确定在源中找到的当前<major>.<minor>.<patch>版本使用它的版本。对于<revision>数字，设置为使用它正在构建的提交的修订号。接下来的构建步骤负责编译、打包、测试。我不会将修改后的代码提交回修订控制。