在多种环境Azure云服务项目配置（.csdef和.cscfg） [英] Azure cloud service project configuration (.csdef and .cscfg) in multiple environments

问题描述

目前，我们有一个开发云服务（ACME-DEV-服务）和生产的云服务（ACME-PROD-服务）。我们目前在我们的解决方案设置有一个名为acme.application云服务项目，该项目采用.cscfg和.csdef文件转化为部署该项目的两个环境（生产和开发）。因为这感觉就像一个黑客位给我的，我不喜欢的变换方法。所以，做一些研究之后，似乎你可以有哪些解决问题的某些多个配置文件，但我遇到的问题，因为你只允许一个服务定义。由于生产环境需要额外的证书，以及比我们的开发环境不同hostHeader绑定这并不适合我们呢。

Currently we have a development cloud services (acme-dev-service) and a production cloud service (acme-prod-service). Our current setup in our solution has a cloud service project called acme.application that uses transformation of the .cscfg and .csdef files for deploying the project to the two environments (production and development). I don’t like the transformation method because it feels like a bit of a hack to me. So after doing some research it seems that you can have multiple configuration files which solves some of the issue but I am running into problems because you are only allowed one service definition. This doesn’t work for us because the production environment requires extra certificates as well as different hostHeader bindings than our dev environment does.

如此看来，我们真的不能使用该转换脱身。所以我想我的问题归结为我在错误的光线看的Azure服务项目文件？我们确实应该显示人Azure项目一Azure云服务？我应该有生产和第二Azure项目发展的Azure项目？
有没有更好的方式来做到这一点？或在Azure中具有多个环境中工作的最佳实践？

So it seems we cant really get away from using the transformations. So I guess my question boils down to am I looking at the Azure Service Project files in the wrong light? Should we really be mapping one Azure Project to one Azure cloud service? Should I have an Azure project for Production and a second Azure Project for Development? Is there a better way to do this? Or a best practice for working with multiple environments in Azure?

推荐答案

该CSDefinition文件是这里真正的踢球者。如果你有一个值，你需要两个环境（开发/测试/舞台/制作等）之间的不同，那么你真的有三种选择：

The CSDefinition file is the real kicker here. If you have a value you need to be different between two environments (dev/test/stage/production, etc.) then you really have three options:

1）手动修改展开前的值。 Errr ....好吧....你有两个选择。

1) Manually modify the value before a deployment. Errr....Okay....you have two options.

1）自来水进入的MS建立过程，并确定已选择哪个云配置（用于确定该.cscfg文件的版本将被使用），然后有生成修改.csdef构建和前后一包装（有当文件已被复制到不同的目录只是包装前，这是您要做出变化的时间）。这可能会非常棘手，但我见过它做，因此我在早期的SDK天甚至已经完成。这里是一个博客文章，解释他的使用WebConfigTransformRunner能够做到这一点的一个例子：<一href=\"http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/\">http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/.我真的不认为这是最好的选择，因为它是不透明的。这不是很明显是怎么回事，有人谁后你走来维持code不会知道这个小宝石，还要花永远试图找出为什么他们投入csdef某处一定的价值以某种方式得到后覆盖他们发布到不同的环境。

1) Tap into the MS Build process and determine which cloud configuration you have selected (the one used to determine which version of the .cscfg file will be used) and then have the build modify the .csdef after the build and prior to packaging (there is a time when the file has been copied to a different directory just before packaging and this is where you want to make the change). This can be tricky, though I've seen it done and have even done so myself in the early SDK days. Here is a blog post explaining one example where he's using WebConfigTransformRunner to do just that: http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/. I don't really think this is your best option because it is opaque. It's not evident what is going on and someone who comes along after you to maintain the code will not know about this little gem and will spend forever trying to figure out why some value they put into the csdef somewhere is somehow getting overwritten after they publish to a different environment.

2）使用你提到的两个Azure项目的做法。您可以选择决定要构建和发布其在Azure项目的构建工具来设置构建定义。我个人认为这是处理不同.csdef文件的最好方法。它的直线前进，并且不需要修改的csproj文件。我不反对的csproj文件的变化，它只是没有过于明显它已经完成，而在作为谁继承了这样的事情一个人，这是不容易发现，当人们做这种事情，他们不在身边，告诉你这件事。

2) Use the two Azure Project approach you mentioned. You can set up build definitions in your Build tool of choice that determine which of the Azure projects you want to build and publish. Personally I think this is the best way to deal with different .csdef files. It's straight forward and doesn't require modifying the csproj files. I'm not opposed to csproj file changing, it's just not overly obvious it was done and, speaking as someone who has inherited things like that, it's not easy to find when people do that kind of thing and they aren't around to tell you about it.

这篇关于在多种环境Azure云服务项目配置（.csdef和.cscfg）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！