我知道这已经发布差不多一年了,但是我必须为自己找出同样问题的答案,所以我就是这样做的。我们正在使用VSTS,因此它可能与内部部署TFS略有不同,我不知道。
1.1打开构建定义以进行编辑。
1.2在“变量”选项卡下,编辑该值 BuildConfiguration 变量(如果它不存在则添加此变量),以便它是您希望构建的各种配置的逗号分隔列表。这些值中的每一个都必须与源代码中的配置相对应。在我的例子中,我有三个配置 - 开发,测试和暂存。在我的代码中,每个配置都有自己的web.config转换文件,指定不同的数据库连接字符串,依此类推。
BuildConfiguration
1.3在“选项”选项卡下,在右侧启用“多配置”。
1.4在“多配置”设置中,输入名称 BuildConfiguration 变量在 Multipliers 领域。这必须与您在步骤1.2中设置值的变量的名称完全匹配。在我的例子中,你可以看到我也检查了Parallel框,并且工作正常。我想如果你遇到麻烦你可以取消选中。
Multipliers
1.5在“任务”选项卡下,选择“生成”任务。
1.6在Build任务的选项中,您需要更新 MSBuild Arguments 字段使输出目录包含 BuildConfiguration 变量。这样,Build任务将为每个配置创建一个单独的输出目录。在这种背景下, BuildConfiguration 变量指定为 $(BuildConfiguration) 。
MSBuild Arguments
$(BuildConfiguration)
1.7仍然在“任务”选项卡下,选择“发布工件”任务。
1.8添加 BuildConfiguration 变量到指定的路径 Path to Publish 领域。这再次意味着当工件被丢弃以准备发布过程来获取它们时,每个配置都有自己的子文件夹。再次,在这种背景下, BuildConfiguration 变量指定为 $(BuildConfiguration) 。
Path to Publish
1.9更改的值 Artifact Name 领域到 BuildConfiguration 变量 - 再一次,它是 $(BuildConfiguration) 这里。
Artifact Name
根据您的要求,这个位可能没有必要,但无论如何我都会包含它。这就是我在Release Release中创建多个环境的方式,每个环境都使用Build过程中的不同配置。
2.1。打开发行版定义以进行编辑。
2.2。在“环境”选项卡下,选择要配置的环境。此示例显示了我配置Dev环境。
我正在使用“复制文件”任务来发布我的Web应用程序。您可能正在使用不同的方法,但希望如果您使用的是其他方法,这将足以指出您正确的方向。
2.3。选择“复制文件”任务。
2.4。修改的值 Source 字段,以便它包含子文件夹,其中包含适合您正在配置的环境的构建配置。
Source
2.5。继续根据您的要求配置其余的环境设置 - 机器(您要将文件发布到的服务器)等。 Destination Folder 对于每个环境,字段至少必然不同。该 Machines 场也可能有所不同。
Destination Folder
Machines
您将知道您的构建过程正在构建多个如果在排队新构建时看起来像这样,请正确配置。请注意左侧的多个配置:
我希望这有助于其他人让这个工作!
的 UPDATE 强> 上述解决方案似乎运行良好。但是,随着我正在部署我们的一个应用程序的环境数量增加(目前已经达到10个并且正在计算),我开始寻找另一种转换方式 Web.config 对于每个环境,假设环境之间唯一的实际差异是数据库连接字符串。
Web.config
这使我放弃了上述解决方案。相反,我们的构建过程现在只能使用一个 Web.config 转换(而不是每个环境一个),它删除debug属性并用标记化版本替换数据库连接字符串,其中数据库服务器,名称等是将由部署过程填充的标记。
这更加整洁。我们的代码现在只包含一个 Web.config 转换,我们的构建过程现在要快得多,因为我们没有为每个环境生成构建,并且数据库密码等作为Release配置中的变量进行存储,加密。
我所做的一切都是详尽的 这里 ,但该文章的作者使用一个名为Tokenizer的工具安装在他的本地TFS盒子上,我用的非常好 标记化任务 从我的发布配置中的市场转换我在Web.config文件中使用的标记。