Col*_*ear 12 cloud virtual-machine azure cloud-hosting
目前,我们拥有开发云服务(acme-dev-service)和生产云服务(acme-prod-service).我们在解决方案中的当前设置有一个名为acme.application的云服务项目,该项目使用.cscfg和.csdef文件的转换,将项目部署到两个环境(生产和开发).我不喜欢转换方法,因为它对我来说感觉有点像黑客.所以在做了一些研究之后,似乎你可以有多个配置文件来解决一些问题,但是我遇到了问题因为你只允许一个服务定义.这对我们不起作用,因为生产环境需要额外的证书以及与我们的开发环境不同的hostHeader绑定.
所以我们似乎无法摆脱使用转换.所以我想我的问题归结为我是否在错误的光线下查看Azure服务项目文件?我们真的应该将一个Azure项目映射到一个Azure云服务吗?我应该有一个用于生产的Azure项目和第二个用于开发的Azure项目吗?有一个更好的方法吗?或者是在Azure中使用多个环境的最佳实践?
CSDefinition文件是真正的踢球者.如果你有一个值,你需要在两个环境(dev/test/stage/production等)之间有所不同,那么你真的有三个选择:
1)在部署之前手动修改该值.呃....好吧....你有两个选择.
1)点击MS Build流程并确定您选择了哪个云配置(用于确定将使用哪个版本的.cscfg文件)然后让构建在构建之后和打包之前修改.csdef(有一段时间,文件在打包之前被复制到另一个目录,这是您想要进行更改的地方).这可能很棘手,虽然我已经看到它已经完成,甚至在SDK早期就已经完成了.这里是一个博客帖子解释在他的使用WebConfigTransformRunner做那一个例子:http://fabriccontroller.net/blog/posts/apply-xdt-transforms-to-your-servicedefinition-csdef-file/.我不认为这是你最好的选择,因为它是不透明的.现在发生的事情并不明显,并且在你维护代码之后出现的人不会知道这个小宝石,并且会花费很长时间试图找出为什么他们在某个地方放入csdef的某些价值在他们发布到不同的环境.
2)使用您提到的两种Azure Project方法.您可以在所选的构建工具中设置构建定义,以确定要构建和发布的Azure项目.我个人认为这是处理不同.csdef文件的最佳方式.它很直接,不需要修改csproj文件.我并不反对csproj文件更改,它只是没有过于明显它已经完成,并且作为一个继承了这样的事情的人说话,当人们做那种事情并且他们无法告诉时,这并不容易找到你呢.
| 归档时间: |
|
| 查看次数: |
3855 次 |
| 最近记录: |