考虑以下构建配置：
[Build＆amp;套餐] - ＆gt; [部署到TEST] - ＆gt; [部署到LIVE]
我已经设置了这些：
这可以很好地将所有构建链接在一个构建链中，这样我们就可以定期构建和打包，然后在我们准备就绪时，将链扩展到TEST环境中。它可以在这里待测试一周，然后我们运行[Deploy to LIVE]配置，知道我们正在部署我们上周测试的相同二进制文件。太好了！
我们使用两个存储库，代码本身使用“Source”，部署参数使用“Config”。这允许Ops团队修改和跟踪部署/环境设置，而不必强制源VCS存储库增加修订，因此我们避免混淆源问题的环境/配置问题。也很棒。
Config VCS root连接到[Deploy to TEST]和[Deploy to LIVE]配置。
我们刚遇到的问题是，自从我们一周前成功部署到TEST（来源：1002，配置：6）后，我们将部署的设置更改为LIVE，这导致了Config VCS根目录的新版本（配置：7）。现在我们想要使用Config：7将已知良好的Source：1002部署到LIVE，但构建链坚持使用Config：6来维护快照。
我们如何强制TeamCity允许我们在LIVE中使用更新版本的配置，但保持构建链完好无损？
我们已经对Source进行了后续更改，我们现在还不想放入LIVE，因此我不能简单地从头开始重新运行。
答案 0 :(得分：0)
我只是想我会更新这个问题，因为我似乎在为新项目设置管道时遇到了答案。
关键是基本上添加一个新的TeamCity构建配置，专门用于从VCS获取配置XML文件并将它们存储为工件，例如： [获取配置]。
我从[Build＆amp; Sons]中删除了Config VCS root。包]配置从而将其与构建链断开连接，并将其附加到[Get Config]配置。现在，当[Get Config]运行时，它基本上只从Config VCS获取最新的config xml文件，并将它们存储为很好的版本化工件。
然后，我从[Deploy to TEST]添加了一个新的工件依赖到[Get Config]，配置为从“上次成功构建”中获取工件。因此，[Deploy to TEST]将始终使用最新的配置运行，即使我们需要对其进行最后一分钟的更改，而不会影响构建链或扭曲软件包版本。
另一个好处是，如果我们在不知不觉中弄乱配置，使用“运行自定义构建”对话框，我们将恢复并使用较旧的[Get Config]构建来运行具有已知良好配置的部署。