如何在VSTS版本管理中处理多种配置? [英] How to handle multiple configurations in VSTS Release management?
问题描述
对于我们的项目，我们使用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环境中.
问题是，该发行版是与Test Web.config一起为Test环境创建的.将此构建转移到暂存环境的一般方法是什么?为此，我需要暂存Web.config.我应该始终建造3次并保留这些文物吗?这将意味着大量的构件/磁盘空间，而这些构件/磁盘空间通常不会部署.
MSDN似乎没有给我答案.有什么想法吗?
我知道这已经发布了将近一年了，但是我只需要自己解决这个问题的答案，所以这就是我做到了.我们使用的是VSTS，所以它与本地TFS可能略有不同.
1.在构建定义中配置多个配置
1.1打开构建定义进行编辑.
1.2在变量"选项卡下，编辑BuildConfiguration变量的值(如果该变量不存在，请添加此变量)，以便它是您要构建的各种配置的逗号分隔列表.这些值中的每一个都必须与源代码中的配置相对应.在我的示例中，我有三种配置-开发，测试和登台.在我的代码中，每个配置都有自己的web.config转换文件，用于指定不同的数据库连接字符串，等等.
1.3在选项"选项卡下，在右侧启用多配置".
1.4在多配置"设置中，在Multipliers字段中输入BuildConfiguration变量的名称.这必须与您在步骤1.2中为其设置值的变量的名称完全匹配.在我的示例中，您可以看到我也选中了Parallel框，并且工作正常.我想如果您遇到麻烦，可以取消选中.
1.5在任务"选项卡下，选择生成"任务.
1.6在Build任务的选项中，您需要更新MSBuild Arguments字段，以便输出目录包含BuildConfiguration变量.这样，构建"任务将为每个配置创建一个单独的输出目录.在这种情况下，BuildConfiguration变量指定为$(BuildConfiguration).
1.7仍在任务"选项卡下，选择发布工件"任务.
1.8将BuildConfiguration变量添加到Path to Publish字段中指定的路径.这再次意味着，当将工件放下以准备发布过程以将其拿起时，每种配置都有其自己的子文件夹.同样，在这种情况下，BuildConfiguration变量被指定为$(BuildConfiguration).
1.9将Artifact Name字段的值更改为BuildConfiguration变量-再次在此处为$(BuildConfiguration).
2.为多个配置配置版本定义
根据您的要求，此位可能不是必需的，但无论如何我都会将其包括在内.这就是我在发布定义中创建多个环境的方式，每个环境都使用与构建过程不同的配置.
2.1.打开发布定义进行编辑.
2.2.在环境"选项卡下，选择要配置的环境.此示例向我展示了如何配置Dev环境.
我正在使用复制文件"任务来发布我的Web应用程序.您可能使用了不同的方法，但是如果您使用的是其他方法，希望这足以将您指向正确的方向.
2.3.选择复制文件"任务.
2.4.修改Source字段的值，使其包含包含适合您正在配置的环境的已构建配置的子文件夹.
2.5.继续并根据您的要求配置其余的环境设置-机器(要将文件发布到的服务器)等.Destination Folder字段至少对于每个环境都必须有所不同. Machines字段也可能会有所不同.
如果您在排队新的构建时看起来像这样，则您会知道您的构建过程正在正确构建多个配置.请注意左侧的多种配置:
我希望这可以帮助其他人使它正常工作！
更新
上述解决方案似乎效果很好.但是，随着我将其中一个应用程序部署到的环境数量的增加(目前为10个，并且还在增加)，我开始寻找一种针对每种环境转换Web.config的替代方法，因为唯一实际的环境之间的区别是数据库连接字符串.
这使我放弃了上述解决方案.取而代之的是，我们的Build过程现在仅适用于一个Web.config转换(而不是针对每个环境进行一次转换)，该转换删除了debug属性，并用标记化的版本替换了数据库连接字符串，其中，数据库服务器，名称等是标记，将由部署"过程填充.
这太整齐了.现在，我们的代码仅包含一个Web.config转换，我们的构建过程现在变得更快，因为我们没有为每个环境生成一个构建，并且数据库密码等作为变量存储，加密和存储在Release配置中./p>
令牌化任务，以转换我拥有的令牌在我的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版本管理中处理多种配置?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
