如何避免邮递员中的“环境地狱”？

Question

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

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

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

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

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

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

我怎样才能避免这种情况？如果我可以选择多个环境作为活动环境，那就太好了。然后我可以在“staging”和“serviceC”旁边打勾。

Answer 1

对于特定于 Paw 的解决方案：

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

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

一般来说，这提供了很大的灵活性，因为多个环境域可以在一个请求中一起使用。例如，可以想象一个具有不同环境（us-east-1、us-west、...）的Server 环境域，它们可以与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。

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