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

Question

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

对于测试,登台和生产环境,我们有不同的Web.config文件,这些文件针对特定环境进行了转换.

我确实设置如下(MSBuild构建步骤):

• 有一个很好的构建运行,它为Cloud Service部署ServiceConfiguration.cscfg和DeploymentPackage.cspkg(/ t:Publish)和目标环境测试(/ p:TargetProfile = Test)创建构建工件.
• 工件随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)这里.

2.为多个配置配置版本定义

根据您的要求,这个位可能没有必要,但无论如何我都会包含它.这就是我在Release Release中创建多个环境的方式,每个环境都使用Build过程中的不同配置.

2.1.打开发行版定义以进行编辑.

2.2.在"环境"选项卡下,选择要配置的环境.此示例显示了我配置Dev环境.

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

2.3.选择"复制文件"任务.

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

2.5.继续根据您的要求配置其余的环境设置 - 机器(您要将文件发布到的服务器)等.Destination Folder对于每个环境,该字段至少必须是不同的.该Machines领域也可能有所不同.

如果在排队新构建时它看起来像这样,那么您将知道您的构建过程正在构建多个配置.请注意左侧的多个配置:

我希望这有助于其他人让这个工作!

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

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

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

我在这里详细介绍了我所做的要点,但是该文章的作者使用了一个名为Tokenizer的工具安装在他的本地TFS盒子上,我在我的Release配置中使用了来自Marketplace 的非常好的Tokenization Task转换我在Web.config文件中使用的标记.