在非生产环境中测试生产配置文件

Question

仅在部署到生产环境之前测试生产环境配置文件的最佳方法是什么？

非生产环境的配置文件可以在各自的环境中轻松测试。但是，在生产部署之前，如何测试生产环境呢？

例如，STAGE中的数据库名称与prod中的数据库名称不同。

如果STAGE配置文件具有正确的数据库名称并经过了测试。现在，在配置文件中有一个“typo”错误。除非在生产中部署它，否则将无法发现此拼写错误。

是否有一种方法可以在生产之前测试具有拼写错误的配置文件？

谢谢

- dotnet-practitioner

Answer 1

有些人使用的方法是拥有一个与生产环境完全相同的暂存环境。

在完全启用解决方案之前，您可以在尽可能接近生产环境的环境中进行测试。

- hermiod

Answer 2

你必须确保环境配置相似，大多数值都是默认的，只有一小部分需要在配置文件中进行覆盖（约定优于配置）。

你必须拥有一个类似于PREPROD或STAGING或PROD的环境，其中部署与PROD完全相同，配置文件也相同，除了一些值，如机器信息。在PREPROD上部署可以让你在这种情况下对PROD配置感到放心。

以上两点应该对你有很大帮助。你还可以看看A-B部署或蓝绿部署

- manojlds

Answer 3

在web.config文件的appSettings下，我使用了这个键：

<add key="CurrentEnvironment" value="0"/>
<!--        
    Public Enum Environments
       Development = 0          
       Alpha = 1                
       ReleaseCandidate = 2    
       Production = 3           
    End Enum
-->

正如您在我的注释中所看到的那样，这对应于我的 Helpers.vb 类中的一个枚举，用法如下：

Public Shared CurrentEnvironment As Environments = DirectCast(WebConfigurationManager.AppSettings("CurrentEnvironment"), Environments)

这允许您编写特定于环境的代码，如URL、数据库连接等。

我发现它非常有用。

-- 抱歉是VB.NET代码，但我相信您可以轻松转换 --

基于OP编辑的编辑：

为什么不创建一个单元测试项目？

- Code Maverick

---

为什么呢？这对我们公司非常有效。我只需要一个项目来查看项目周期的各个阶段。在我的 Helpers 类中，我公开了属性和方法，这些属性和方法由项目调用，但根据项目当前所处的阶段而表现出不同的行为。 - Code Maverick

应用程序不应该知道它所处的环境。环境应该知道如何配置部署到其中的应用程序。 - manojlds

根据你的说法，也许是这样，但在我们的应用程序中，根据所处的环境级别，我们有许多完全不同的设置。我使用一个助手类来标准化应用程序使用的属性和方法，以便每个环境级别都以相同的方式编码。唯一的区别是，在助手类的背后，他使用适用于特定环境级别的设置。 - Code Maverick

Answer 4

可能最好的方法是在生产环境中创建一个单独的网站作为“阶段”。然后，您可以首先将新配置应用于该网站进行测试，如果一切正常，再将其迁移到您真实的生产网站上。否则，无法保证其与在生产服务器上的行为相同。

- ashelvey