建议部署到多个Azure环境(开发,测试,生产)的方法是什么? [英] What is the recommended approach for deploying to multiple Azure environments (dev, test, production)?

查看:145
本文介绍了建议部署到多个Azure环境(开发,测试,生产)的方法是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个使用mvc5的C#Web应用程序.它当前在Azure上运行,我有一个开发,测试和生产实例.我需要做些什么以确保在将应用程序推送到每个环境时数据库连接字符串将自动更改?我知道这可以通过web.config来实现,因为您可以定义Web.Debug.Config等,但是对于Azure上的不同辅助角色,我将如何处理呢?我一直在互联网上寻找解决方案.简而言之,我想对多个web.config文件使用相同的方法,但对Azure.

I have an C# web application using mvc5. It currently runs on Azure and I have a dev, test, and production instances. What do I need to do to ensure that the database connection strings will automatically change as the application is pushed to each environment? I know this is possible with web.config as you can define Web.Debug.Config, etc, but how would I go about this for different worker roles on Azure? I have been all over the internet looking for a solution. In a nutshell, I would like to do the same approach used for the multiple web.config files but for Azure.

作为一些其他背景,对于我的解决方案,我将我的存储库分解为一个单独的项目,在那里我尝试从配置文件中获取连接字符串(假设domain.dll是包含它的库的名称).首先,这在我仅使用web.config时起作用,但是当我不得不从另一个工作角色运行域DLL文件时,配置开始返回null;因为当从其他工作进程(非Web)运行时,此代码将无法运行.这似乎引入了一个有趣的问题,如果我需要在Web外部和Azure外部使用domain.dll代码怎么办?我如何仍保持Azure和web.config提供的连接字符串优势?

As some additional background, for my solution I have my repositorybase broken out into a separate project and there I am trying to grab the connection string from the configuration files (let's say domain.dll is the name of the library that contains it). As first this worked when I was only using web.config but when I had to run my domain DLL files from another worker role the configuration began to return null; because this code would not run when run from a different worker process(non web). This seems to introduce an interesting problem, what if I need to use the domain.dll code outside the web and outside of Azure? How do I still maintain the connection string benefits that Azure and web.config provide?

推荐答案

假设:您使用的是Web服务,而不是Web站点.有区别.

有两种方法可以满足您的需求:

There are 2 ways to get what you need:

  1. 对于辅助角色,您几乎可以像在web.config中一样进行app.config转换.只有您需要使用 SlowCheetah .有一个nuget包,还有VS扩展来创建转换文件.这种方法实在令人费解.我从不喜欢它,所以转到第二个选项.

  1. For worker role you can do app.config transformations almost in the same way you do in web.config. Only you'll need to do it with SlowCheetah. There is a nuget package for that, also there is VS extension to create transform files. There is too much faffing-about with this method. I never liked it, so move on to second option.

如果运行Web服务,则可以将连接字符串指定为工作人员角色配置的一部分.转到您的Azure项目并打开worker角色的属性:

If you run Web-Services, you can specify connection strings as part of worker-role configuration. Go to your Azure project and open properties of your worker-role:

您可以在其中添加数据库连接字符串.并为您运行的每个环境(开发,测试,生产)创建配置.并为每个环境放置不同的连接字符串.

There you can add database connection string. And create a configuration for every environment you run (dev, test, prod). And place a different connection string for every environment.

要获取连接字符串,请执行以下操作:

To get your connection string you execute:

CloudConfigurationManager.GetSetting("DatabaseConnectionString")

部署站点后,您将在Azure Portal的Configure选项卡中看到这些配置值.

Once your site is deployed you'll see these configuration values in Configure tab in Azure Portal.

这篇关于建议部署到多个Azure环境(开发,测试,生产)的方法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆