如何确定 TFS 2015 构建中的变更集是从哪里构建的？答案

【问题标题】：How to figure out the changeset a TFS 2015 build was build from?如何确定 TFS 2015 构建中的变更集是从哪里构建的？
【发布时间】：2017-04-07 00:46:15
【问题描述】：

我只分发由我的 TFS 构建定义之一构建的二进制文件，并且每个构建都会收到一个唯一的版本号 (1.0.$yy$dayofyear.$rev)。构建名称的名称包含此版本号。版本号由 PowerShell 脚本设置为程序集版本和二进制文件的版本。我只有 60 天的构建结果保留期（包括在我的放置文件夹中构建的二进制文件），现在我想知道：我怎么可能弄清楚它是从哪个变更集构建的一年前的版本号，以便我可以看看源代码或完全重建二进制文件吗？我是否必须在构建期间以某种方式显式添加变更集信息？我是否必须在构建期间设置的版本号中对变更集号进行编码？这两个想法似乎都不是很巧妙。

【问题讨论】：

标签： c# tfs tfs-2015

【解决方案1】：

您可以添加一个 powershell 脚本或extension task，它将生成发行说明作为 TFS vNext 构建的一部分。你会得到如下的东西：

然后你可以把它存起来，源代码看这个blog

【讨论】：

我更喜欢直接在二进制文件或 TFS 中存储一些信息“版本变更集”。发行说明很容易丢失，因为有人只将二进制文件复制到其他地方。然而，它是一种用于记录相关工作项和提交的有趣机制。会尽量记住您的建议。

【解决方案2】：

前言：XAML 构建。

您可以通过创建发布/修补程序分支并拥有特定于这些分支的构建定义来查看所有构建产品。将构建克隆到分支并使用版本号作为二进制标记的一部分很容易。我更喜欢使用分支版本号方法，并用该版本号标记我的二进制文件。只要您为每个分支中的二进制文件创建唯一的构建定义，您就可以轻松查看过去的构建，并准确查看与之关联的变更集。您所需要的只是二进制文件的版本号，并且您将能够轻松地将其追溯到源头。

【讨论】：

是的，我在回答中提到了这一点。 :)
抱歉，我忘了说我正在使用 vNext 构建定义。
适用于分支和为该分支构建的相同基本原则。由于保留规则非常严格，我建议保留已发布的版本。如果您有构建定义，您将知道解决方案位于哪个分支，并且您将能够查看历史记录并与二进制文件的构建日期/时间相关联。
您对保留天数有何建议？是否有可能配置构建，以便在放置位置中的二进制文件在几天后被删除时保留“元”信息？这对我来说也是一个可选的解决方案。
是的，如果您创建一个分支并遵循该分支的命名约定和该分支的构建，并且您使用相同的约定标记您的二进制文件，那么您可以引用已部署的二进制文件，这将带你回到分支并构建创建它们。

【解决方案3】：

我终于想出了一个 PowerShell 脚本，我将它作为一个附加的构建步骤挂接到我的构建定义中，紧随其后的步骤类似于建议的 here，它在所有 AssemblyInfo.cs 文件中设置版本属性：

$systDefinitionId = $env:SYSTEM_DEFINITIONID
$buildDefVersion = $env:BUILD_DEFINITIONVERSION
$buildDefName = $env:BUILD_DEFINITIONNAME
$buildSourceVersion = $env:BUILD_SOURCEVERSION
$buildSourceBranch = $env:BUILD_SOURCEBRANCH

$SrcPath = $env:BUILD_SOURCESDIRECTORY
$AllVersionFiles = Get-ChildItem $SrcPath AssemblyInfo.cs -recurse
$AllVersionFilesCount = ($AllVersionFiles | Measure-Object).Count

Write-Verbose "Updating $AllVersionFilesCount AssemblyInfo.cs files in path ""$SrcPath"" with source information."  -Verbose

Write-Verbose "ID of build definition:      $systDefinitionId" -Verbose
Write-Verbose "Version of build definition: $buildDefVersion" -Verbose
Write-Verbose "Name of build definition:    $buildDefName" -Verbose
Write-Verbose "Changeset to build:          $buildSourceVersion" -Verbose
Write-Verbose "Branch to build from:        $buildSourceBranch" -Verbose

foreach ($file in $AllVersionFiles)
{
(Get-Content $file.FullName) |
    %{$_ -replace 'AssemblyProduct\(""\)', "AssemblyProduct(""$buildDefName / $buildSourceVersion"")" } |
    %{$_ -replace 'AssemblySourceBranch\(""\)', "AssemblySourceBranch(@""$buildSourceBranch"")" } |
    %{$_ -replace 'AssemblySourceChangeset\(0\)', "AssemblySourceChangeset($buildSourceVersion)" } |
    %{$_ -replace 'AssemblyBuild\(""\)', "AssemblyBuild(@""$buildDefName / ID: $systDefinitionId / Version: $buildDefVersion"")" } |
Set-Content $file.FullName -Force
}

我正在修改AssemblyProduct 属性，将构建定义名称和用于创建二进制文件的变更集写入其中。稍后，此信息将在 Windows 资源管理器中的详细信息选项卡上的 exe 或 dll 的属性中可见。

此外，我还定义了自定义属性AssemblySourceBranch、AssemblySourceChangeset 和AssemblyBuild 以携带更详细的信息。它们都具有相同的结构，因此为简洁起见仅提供AssemblySourceChangeset的源代码：

[AttributeUsage(AttributeTargets.Assembly, AllowMultiple = false)]
public class AssemblySourceChangesetAttribute : Attribute
{
  public AssemblySourceChangesetAttribute(uint changeset)
  {
    Changeset = changeset;
  }

  public uint Changeset { get; }
}

如果“公开”可见产品字段中的信息不足以重建二进制文件，仍然可以反映 exe 或 dll 并读取那些在源分支上有信息的自定义属性， id 和存储的构建定义的版本。

【讨论】：

您自己修复总是更好，因为解决方案最适合您的情况！:)