VSTS Release 管理中如何处理多个配置? [英] How to handle multiple configurations in VSTS Release management?

问题描述

对于我们的项目，我们使用 Visual Studio Team Services 来维护代码和构建.对于这个项目，我还想设置发布管理.(

1.3 在选项选项卡下，在右侧启用多配置.

1.4 在 Multi-configuration 设置中，在 Multipliers 字段中输入 BuildConfiguration 变量的名称.这必须与您在步骤 1.2 中为其设置值的变量名称完全匹配.在我的示例中，您可以看到我还选中了 Parallel 框，并且工作正常.我想如果您遇到问题，可以取消选中此项.

1.5 在任务选项卡下，选择构建任务.

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

1.7 仍然在 Tasks 选项卡下，选择 Publish Artifact 任务.

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

1.9 将 Artifact Name 字段的值更改为 BuildConfiguration 变量 - 再次，这里是 $(BuildConfiguration).

2.为多个配置配置发布定义

根据您的要求，这一点可能不是必需的，但无论如何我都会包括在内.这就是我在发布定义中创建多个环境的方式，每个环境都使用与构建过程不同的配置.

2.1.打开您的版本定义进行编辑.

2.2.在 Environments 选项卡下，选择您要配置的环境.此示例向我展示了如何配置开发环境.

我正在使用复制文件"任务来发布我的 Web 应用程序.您可能使用了不同的方法，但希望如果您使用不同的方法，这足以为您指明正确的方向.

2.3.选择复制文件任务.

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

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

如果您将新构建排入队列时看起来像这样，您就会知道您的构建过程正在正确构建多个配置.请注意左侧的多个配置:

我希望这能帮助其他人完成这项工作！

更新上述解决方案似乎工作得很好.然而，随着我部署其中一个应用程序的环境数量不断增加(目前有 10 个并且还在增加)，我开始寻找一种替代方法来为每个应用程序转换 Web.config环境，因为环境之间唯一的实际区别是数据库连接字符串.

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

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

我所做的事情的要点很详细此处，但是尽管该文章的作者使用了安装在其本地 TFS 盒上的名为 Tokenizer 的工具，但我使用了非常好的 令牌化任务 来自我的发布配置中的市场，用于转换我已经使用的令牌在我的 Web.config 文件中使用.

For our project we are using Visual Studio Team Services to maintain code and builds. For this project I also want to setup release mangement. (https://www.visualstudio.com/en-us/features/release-management-vs.aspx)

For the Test, Staging and Production environment we have different Web.config files which are transformed for the specific environment.

I did set it up as follows (MSBuild Build steps):

• There is a nighly build running, which is creating the build artifacts for the Cloud Service deployment ServiceConfiguration.cscfg and DeploymentPackage.cspkg (/t:Publish) and target environment test (/p:TargetProfile=Test)
• The artifacts are published with a VSTS build task to enable deployment with Release Management.
• After a succesful nightly build, a release is created, the artifacts are downloaded and automatically deployed to the Test environment.

Question is, the release is created for the Test environment along with the Test Web.config. What is the general approach to move this build to the Staging environment? I need the Staging Web.config for this. Should I always build 3 times and keep these artifacts? That would mean a lot of artifacts/diskspace for builds which will not be deployed most of the time.

MSDN doesn't seem to give me an answer. Any ideas?

解决方案

I know it's been almost a year sine this was posted, but I've just had to figure out the answer to this same problem for myself, so here's how I did it. We're using VSTS so it may differ slightly from on-premise TFS, I don't know.

1. Configure Multiple Configurations in the Build Definition

1.1 Open your Build Definition for editing.

1.2 Under the Variable tab, edit the value of the BuildConfiguration variable (add this variable if it doesn't exist) so that it is a comma-delimited list of the various configurations you wish to build. Each of these values must correspond to a configuration in the source code. In my example, I have three configurations - Dev, Test and Staging. In my code, each of these configurations has its own web.config transformation file specifying different database connection strings and so on.

1.3 Under the Options tab, enable Multi-configuration on the right-hand side.

1.4 In the Multi-configuration settings, enter the name of the BuildConfiguration variable in the Multipliers field. This must match exactly the name of the variable that you set the value for in step 1.2. In my example, you can see that I've also checked the Parallel box, and that works fine. I guess if you're having trouble you could uncheck this.

1.5 Under the Tasks tab, select the Build task.

1.6 In the options for the Build task, you need to update the MSBuild Arguments field so that the output directory includes the BuildConfiguration variable. In this way, the Build task will create a separate output directory for each configuration. In this context, the BuildConfiguration variable is specified as $(BuildConfiguration).

1.7 Still under the Tasks tab, select the Publish Artifact task.

1.8 Add the BuildConfiguration variable to the path specified in the Path to Publish field. This again means that when the artifacts are dropped ready for the Release process to pick them up, each configuration has its own subfolder. Again, in this context, the BuildConfiguration variable is specified as $(BuildConfiguration).

1.9 Change the value of the Artifact Name field to the BuildConfiguration variable - once again, it's $(BuildConfiguration) here.

2. Configure Release Definition for multiple Configurations

Depending on your requirements, this bit may not be necessary but I'll include it anyway. This is how I created multiple environments in my Release Definition, each using a different configuration from the Build process.

2.1. Open your Release Definition for editing.

2.2. Under the Environments tab, select the environment you wish to configure. This example shows me configuring the Dev environment.

I'm using the Copy Files task to publish my web application. You may be using a different method, but hopefully this will be enough to point you in the right direction if you're using a different method.

2.3. Select the Copy Files task.

2.4. Modify the value of the Source field so that it includes the subfolder containing the built configuration appropriate for the environment you're configuring.

2.5. Go ahead and configure the rest of the environment settings according to your requirements - the machine (the server to which you're publishing the files), etc. The Destination Folder field at least will necessarily be different for each of your environments. The Machines field may well vary too.

You'll know that your Build process is building multiple configurations correctly if it looks like this when you queue a new build. Note the multiple configurations down the left-hand side:

I hope this helps somebody else to get this working!

UPDATE The solution described above seems to work perfectly well. However, as the number of environments to which I'm deploying one of our applications has grown (currently at 10 and counting), I started to look for an alternative way of transforming the Web.config for each environment, given that the only actual difference between environments was the database connection string.

This has led me to abandon the solution described above. Instead, our Build process now works with only one Web.config transformation (rather than one for each environment) which removes the debug attribute and replaces the database connection string with a tokenized version, where the database server, name and so on are tokens which will be populated by the Deployment process.

This is much tidier. Our code now contains only one Web.config transformation, our Build process is now much faster as we're not producing a build for each environment, and the database passwords and so on are stored, encrypted, as variables in the Release configuration.

The gist of what I've done is detailed here, but whereas the author of that article uses a tool called Tokenizer installed on his on-premises TFS box, I've used the very nice Tokenization Task from the Marketplace in my Release configuration to transform the tokens I've used in my Web.config file.

这篇关于VSTS Release 管理中如何处理多个配置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！