我怎样才能避免＆＃34;环境地狱＆＃34;在邮差？

Question

假设我有两个不同的URL环境（测试和生产）。我还有两个需要不同标头值的服务（serviceA和serviceB）。我可以在Postman的四个环境中解决这个问题：

1. testServiceA：测试的url，serviceA的标头值
2. testServiceB：test的url，serviceB的标头值
3. productionServiceA：生产的url，serviceA的标头值
4. productionServiceB：生产的url，serviceB的标头值

这里我重复了URL和标题。当我添加另一个网址时，我总共需要六个环境：

1. testServiceA：测试的url，serviceA的标头值
2. testServiceB：test的url，serviceB的标头值
3. productionServiceA：生产的url，serviceA的标头值
4. productionServiceB：生产的url，serviceB的标头值
5. stagingServiceA：用于登台的url，serviceA的标头值
6. stagingServiceB：用于登台的url，serviceB的标头值

当我添加另一个需要更改标头值的服务时，我需要另外一个3：

1. testServiceA：测试的url，serviceA的标头值
2. testServiceB：test的url，serviceB的标头值
3. productionServiceA：生产的url，serviceA的标头值
4. productionServiceB：生产的url，serviceB的标头值
5. stagingServiceA：用于登台的url，serviceA的标头值
6. stagingServiceB：用于登台的url，serviceB的标头值
7. testServiceC：测试的url，serviceC的标头值
8. productionServiceC：生产的url，serviceC的标头值
9. stagingServiceC：用于登台的url，用于serviceC的标头值

我该如何避免这种情况？如果我可以选择多个环境作为活动状态，那将会很棒。然后我可以在＆＃34; staging＆＃34;旁边放置一个复选标记。和＆＃34; serviceC＆＃34;例如。

Answer 1

针对Paw特有的解决方案：

Paw make具有环境域的概念，可以更轻松地控制您的环境值。基本上，环境域可以具有多个环境，这些环境是相同环境值的表示。

在您的情况下，您可以拥有3个环境域（serviceA，serviceB，serviceC），您将拥有3个环境（测试，登台，生产）

通常，这允许很多灵活性，因为可以在单个请求中一起使用多个环境域。例如，可以想象一个Server环境域具有不同的环境（us-east-1，us-west，...），可以与Version环境域结合使用（ v1.0，v1.1，v2.0等），并将它们合并为一个请求，以检查版本2.0是否适用于us-east-1，依此类推。

针对Postman特有的解决方案：

您可以使用一些{{}}复杂性来增强某些环境。 环境变量可以互相引用：

现在，当您在某处引用环境变量{{some-important-header}}时，它实际上会引用{{{{mode}}-some-important-header}}，在本例中为{{test-some-important-header}}或-1。每次要更改模式时，都必须将环境变量值mode更改为正确的值，例如production或staging。

这不是最干净的解决方案，但它避免了由于耦合造成的一堆环境。