跨环境管理配置文件 [英] Manage configuration files across environments

查看:261
本文介绍了跨环境管理配置文件的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您如何(您的公司)如何管理您构建的应用/系统的配置文件?让我告诉你我们是如何做的,问题是什么。

How do you (your company) manage the config-files of the apps/systems you build? Let me tell you how we do it, and what the problem is.

我正在一家公司工作,我们开发大约15个开发人员的软件。我们构建部署在托管服务提供商的业务线应用程序。
我们的一个主要应用程序包括一个网站和大约十个WCF服务。一些服务相互连接。

I'm working at a company where we develop software with about 15 developers. We build line-of-business web apps that are deployed at our managed hosting provider. One of our main apps consists of one web site and about ten WCF services. Some of the services are connected to each other.

我不知道这是一个大系统,还是小的,但我的意见是,这也是我们的方式很长一段时间才能让我们在不同的环境(测试,验收和生产)中运行。

I don't know if this is a big system, or small, but my opinion is that is takes us way too long to get things up and running in our different environments (test, acceptance and production).

我们的Visual Studio项目中每个环境都有配置文件。所以一个 web.test.config ,一个 web.acc.config ,一个 web。 prod.config 和一个 web.config 进行开发。他们都有相同的钥匙,但价值观可能会有所不同,这取决于他们的环境。

We have config-files per environment in our Visual Studio projects. So a web.test.config, a web.acc.config, a web.prod.config and a web.config for development. They all have the same keys in them, but the values can be different, depending on the environment they are meant for.

如果我快速计算一下appsettings webapp的web.config我计数32.我计算5个端点。我们有四个环境(dev,test,acc和prod),这意味着128个appsettings和20个端点总共为一个Web应用程序。我们可以很容易地犯错误,特别是在截止期限结束的时候,我们都是人,所以这样的事情发生在每个人身上:我们改变了一个配置文件,但是在构建和部署之前忘记了登录。或者我们在Web服务器上进行更改,并忘记在四个web.config中更改它。或者我们只更改四个配置文件中的三个。等等。
然后我们在我们的托管提供商拥有基础架构。默认情况下,每个端口都关闭。因此,如果一个WCF服务需要与其他服务器上的另一个WCF服务通信,则必须在防火墙中打开一个端口。我们在测试中做到这一点,但是在Acceptance中,我们必须再次执行此操作,我们已经忘记了哪些端口必须被打开,所以它更像是试用和错误的:我的服务无法连接到数据库,大概是端口关闭。同样的事情在生产中再次发生。根据SLA,我们的托管服务提供商可能需要几天才能在防火墙中打开一个端口。所以,迅速成为一个漫长的过程。最终需要大约两个月的时间来测试,验收和生产运行。

If I do a quick count of the appsettings in the web.config for the webapp I count 32. And I count 5 endpoints. We have four environments (dev, test, acc and prod) this means 128 appsettings and 20 endpoints in total for one web app. We can easily make mistakes, especially when deadlines are closing in. We are all people so things like this happen to everyone: we make a change in a config-file, but forget to check in before we build and deploy. Or we make a change on the webserver and forget to change it also in the four web.configs. Or we Change only three of four config files. And so on. And then we have the infrastructure at our managed hosting provider. By default every port is closed. So if one WCF service needs to talk to another WCF service on a different server, a port has to be opened in a firewall. We do this in Test, but in Acceptance we have to do it again, and we have forgotten which ports have to be opened, so it's more like trial-and-error: oh my service can't connect to the database, probably the port is closed. And the same stuff happens in production again. Our managed hosting provider can take a few days to open a port in a firewall, according to the SLA. So, thuis quickly becomes a pretty long process. And in the end it takes us about two months to have Test, Acceptance and production up and running.

所以,我的问题是:你如何管理配置和基础设施和周围的过程?

So, my question is: how do you manage the configurations and the infrastructure and the process around it?

推荐答案

Config4 * 项目(免责声明:我是其主要开发人员)没有与.Net或WCF开箱即用的集成,因此对您来说可能没有用。但是,Config4 *中的其中一个功能与您的问题相关:可以将if-then-else语句嵌入到配置文件中,以便该文件可以针对不同的环境(如开发,测试,接受和生产)。

The Config4* project (disclaimer: I am its primary developer) does not have an out-of-the-box integration with .Net or WCF, so it is probably not useful to you. However, one of the features in Config4* is relevant to your question: it is the ability to embed if-then-else statements in a configuration file, so that the file can "adapt" itself for different environments (such as development, testing, acceptance and production).

您可能可以修改该概念,使用您在.Net / WCF项目中使用的任何配置语法(I'我不熟悉这些技术,但我猜测他们可能使用基于XML的配置文件)。特别是,您可以使用Python编写一个脚本,它使用if-then-else语句在映射 name = value 对c $ c>,然后使用一些 print 语句来生成针对环境量身定制的一组配置文件。这样的脚本的伪代码大纲是:

You may be able to modify that concept to work with whatever configuration syntax you are using in your .Net/WCF-based project (I'm not familiar with those technologies, but I'm guessing they probably use XML-based configuration files). In particular, you could write a script using, say, Python, that uses if-then-else statements to set environment-specific name=value pairs in a map, and then use some print statements to generate a set of configuration files tailored for an environment. A pseudo-code outline of such a script is:

#--------
# Set up configuration variables suitable for a specified environment
#--------
cfg["variable1"] = "default value";
cfg["variable2"] = "another default value";
if (environment == "testing") {
  cfg["variable1"] = "override default value for this environment";
  cfg["variable3"] = "value suitable for this environment";
  ...
} else if (environment == "production") {
  ...
}
#--------
# Now use print statements to generate configuration files
# Alternatively, use the _name=value_ pairs in the map to
# perform global search-and-replace on template versions of
# configuration files.
#--------
...

奖励积分,脚本还可以生成需要为环境执行的测试清单,例如检查是否需要在以下端点之间打开防火墙端口:...

For bonus points, the script could also generate a checklist of tests that need to be performed for the environment, for example, "Check if a firewall port needs to be opened between the following endpoints: ..."

这篇关于跨环境管理配置文件的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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