将配置设置为发布时未触发发布管理答案

【问题标题】：Release management not triggered when setting configuration to Release将配置设置为发布时未触发发布管理
【发布时间】：2016-01-21 19:56:00
【问题描述】：

我把这分为两个问题，但解决其中任何一个都会解决另一个问题。

问题 1：当我使用下图底部的部分并添加“要发布的配置”时，构建不会触发发布管理。

我查询了几个小时的构建日志，发现当它发现配置“与当前不匹配”时，它停止了发布

如果 ConfigurationsToRelease 匹配当前初始属性值条件 = 假最终属性值条件 = 假最终属性值条件 = 真

在更多的文字之前，我将展示一张总结它的图片： the build definition and ms build logs

在默认情况下，要发布的配置为空白，发布管理将从这一点继续并在日志中写入“发布构建”（作为发生的命令）并且构建将触发发布管理。

如果您查看我的 tfs 构建配置，您会发现它与上面的常规 ms 构建配置完全相同，但我仍然收到不匹配的错误。无论如何，我只有一个对话框可以在构建定义中填写我的配置，如上图中的“配置对话框”所示。

前几天我通过添加发布配置成功地在同一个项目中以这种方式发布了一次或两次，它以某种方式工作，但随后停止工作（工作一两次作为故障，我认为那里缓存了一些东西）但是 99 % 的其他尝试失败了，自从几个月前我第一次尝试它以来，它总是阻止我的触发器从 tfs 释放。 这里有人经历过吗？我看了很多地方，发现只有一个人抱怨它。他的解决方案是删除它（不完全是解决方案）是否有可以解决此问题的构建参数？ (/p:something=something)

问题 2：如果有人可以用不同于 rm 配置的方式解决它，那么我不需要解决问题 1。

对于任何对我什至弄乱构建定义的发布配置部分感兴趣的人来说，这是因为我希望 rm 在 rm 干预之前等待所有转换发生，这似乎是一种方式告诉 rm ，好的伙计，看到了吗？你有 2 个配置等待他们的构建。

问题是，默认情况下，当该配置部分为空白时，rm 会妨碍 tfs build 而 tfs build 会妨碍 rm，类似于循环等待。当 tfs build 正在等待 rm 完成它在第一次构建后运行时，rm 期望两个转换后的文件夹都存在于构建输出中，tfs 想要继续构建第二个配置（和转换）但 rm 已经参与其中，正在寻找它的第二个配置，当找不到它时中断构建，因此永远不会创建第二个配置，而 rm 仍在等待它，而 tfs build 等待 rm 和构建中断。令人困惑？再次阅读并查看下面的图片，因为它很有趣。

为了清楚起见，更多信息： RM 的下一阶段是尝试在构建输出文件夹已经存在之前从它那里获取一些东西。例如，如果我将 Release build 设置为 true ，它只会构建第一个配置（创建一个文件夹，如下图），rm 将在第一步成功（QA.Release），并继续海峡尝试获取 Release 为它的下一阶段，但它尚未由 TFS Build 构建，它等待 rm 完成它在 tfs 构建工作中间的奇怪干预。就像我上面所说的，我确信我已经在我的一个尝试构建中看到它工作过一次或两次。

the tfs output folder whith release build flag on(only one transform happens) \ when off (all two transforms work) + rm error when on (circular wait)

【问题讨论】：

标签： msbuild tfsbuild transformation release-management ms-release-management

【解决方案1】：

如果我正确理解您的情况，我认为您的问题是您正在构建多个配置。这打破了持续交付的核心原则之一，即对于给定的版本，您应该只构建一次，然后按顺序将相同的构建部署到管道中的每个阶段。

为了做到这一点，您的构建需要与阶段无关，这实际上意味着您的所有配置（例如数据库连接字符串）都需要标记化，以便可以为特定阶段（QA、发布）交换正确的值ETC）。我有一篇博文系列here 非常详细地解释了整个过程（对于示例 Web 应用程序）。

【讨论】：

格雷厄姆，生活比连接字符串交换更复杂。
更多建议？所描述的问题尚未解决。

【解决方案2】：

我设法解决了问题 2，通过这样做，问题 1 不再相关。我切换到 ReleaseTfvcTemplate.12.xaml 作为构建模板（在您的 C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin 上找到）

然后在 RM 干预之前构建完成所有配置。

确实看起来像 ReleaseDefaultTemplate.11.1.xaml 中的一个错误，或者这可能是因为我使用了一些额外的 msbuild 参数（这是必需的），或者我使用慢 cheetah 在 Windows 服务上创建转换的事实（转换仅在 Web 应用程序中引入）。

无论哪种方式，我现在都能够执行高级任务，例如使用转换添加\删除在生产中应该不同的标签，例如，我可以在配置文件中保留诊断的使用以供 qa 使用，并将其删除以进行生产以降低那里的详细程度。仍然将 RM PlaceHolders 技术与转换技术结合使用，以享受与环境相关的变化的两个世界，但仍然通过在所有环境中传递相同的构建（dll）来保持原则。

【讨论】：