如何在VSTS版本管理中处理多个配置？

Question

对于我们的项目，我们使用Visual Studio Team Services来维护代码和构建。对于这个项目，我还想设置发布管理。 （https://www.visualstudio.com/en-us/features/release-management-vs.aspx）

对于Test，Staging和Production环境，我们有不同的Web.config文件，这些文件是针对特定环境进行转换的。

我确实设置如下（MSBuild构建步骤）：

• 有一个非常构建的运行，它正在为Cloud Service部署ServiceConfiguration.cscfg和DeploymentPackage.cspkg（ / t：Publish ）和目标环境测试（ /创建构建工件号码：TargetProfile =测试）
• 使用VSTS构建任务发布工件，以便使用版本管理进行部署。
• 在成功的每晚构建之后，创建一个版本，下载工件并自动部署到测试环境。

问题是，为测试环境和Test Web.config创建了发布。将此构建移至Staging环境的一般方法是什么？我需要Staging Web.config。我应该总是建立3次并保留这些文物吗？这意味着构建的很多工件/磁盘空间大部分时间都不会被部署。

MSDN似乎没有给我一个答案。有什么想法吗？

Answer 1

我知道这已经发布差不多一年了，但是我必须为自己找出同样问题的答案，所以我就是这样做的。我们正在使用VSTS，因此它可能与内部部署的TFS略有不同，我不知道。

1。在构建定义

中配置多个配置

1.1打开构建定义进行编辑。

1.2在“变量”选项卡下，编辑BuildConfiguration变量的值（如果它不存在则添加此变量），以便它是您希望构建的各种配置的逗号分隔列表。这些值中的每一个都必须与源代码中的配置相对应。在我的例子中，我有三个配置 - 开发，测试和暂存。在我的代码中，每个配置都有自己的web.config转换文件，指定不同的数据库连接字符串，依此类推。

1.3在“选项”选项卡下，在右侧启用“多配置”。

1.4在多配置设置中，在BuildConfiguration字段中输入Multipliers变量的名称。这必须与您在步骤1.2中设置值的变量的名称完全匹配。在我的示例中，您可以看到我还检查了Parallel框，并且工作正常。我想如果你遇到麻烦，可以取消选中。

1.5在“任务”选项卡下，选择“构建”任务。

1.6在Build任务的选项中，您需要更新MSBuild Arguments字段，以便输出目录包含BuildConfiguration变量。这样，Build任务将为每个配置创建一个单独的输出目录。在此上下文中，BuildConfiguration变量指定为$(BuildConfiguration)。

1.7仍在“任务”选项卡下，选择“发布工件”任务。

1.8将BuildConfiguration变量添加到Path to Publish字段中指定的路径。这再次意味着当工件被丢弃以准备发布过程来获取它们时，每个配置都有自己的子文件夹。同样，在此上下文中，BuildConfiguration变量指定为$(BuildConfiguration)。

1.9将Artifact Name字段的值更改为BuildConfiguration变量 - 再次，$(BuildConfiguration)此处。{/ p>

2。配置多个配置的版本定义

根据您的要求，这个位可能没有必要，但无论如何我都会包含它。这就是我在发布定义中创建多个环境的方式，每个环境都使用与构建过程不同的配置。

2.1。打开发行版定义进行编辑。

2.2。在“环境”选项卡下，选择要配置的环境。此示例显示了我配置Dev环境。

我使用“复制文件”任务发布我的Web应用程序。您可能正在使用不同的方法，但希望如果您使用其他方法，这将足以指出您正确的方向。

2.3。选择“复制文件”任务。

2.4。修改Source字段的值，使其包含子文件夹，其中包含适合您正在配置的环境的构建配置。

2.5。继续根据您的要求配置其余的环境设置 - 机器（您要将文件发布到的服务器）等。Destination Folder字段至少必须是不同的你的环境。 Machines字段也可能会有所不同。

如果排队新构建时，您的构建进程正在构建多个配置。请注意左侧的多个配置：

我希望这有助于其他人实现这一目标！

<强>更新 上述解决方案似乎运行良好。但是，随着我部署其中一个应用程序的环境数量的增加（目前为10并且正在计算），我开始寻找另一种方法来转换每个环境的Web.config环境之间唯一的实际区别是数据库连接字符串。

这使我放弃了上述解决方案。相反，我们的构建过程现在只使用一个Web.config转换（而不是每个环境一个转换），它会删除debug属性并用标记化版本替换数据库连接字符串，其中数据库服务器，名称等等将由部署过程填充的令牌。

这更加整洁。我们的代码现在只包含一个Web.config转换，我们的构建过程现在要快得多，因为我们不为每个环境生成构建，并且数据库密码等存储，加密，作为变量在发布配置。

我所做的主要内容是详细here，但该文章的作者使用了一个名为Tokenizer的工具安装在他的本地TFS盒子上，我已经使用了它我的发布配置中来自Marketplace的好Tokenization Task来转换我在Web.config文件中使用的令牌。