我怎样才能避免邮递员的"环境地狱"？

Question

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

1. testServiceA:用于test的url,serviceA的标头值
2. testServiceB:test的url,serviceB的头值
3. productionServiceA:生产的url,serviceA的标头值
4. productionServiceB:生产的url,serviceB的标头值

在这里,我重复了URL和标题.当我添加另一个URL时,我总共需要六个环境:

1. testServiceA:用于test的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:用于test的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:test的url,serviceC的标头值
8. productionServiceC:生产的url,serviceC的标头值
9. stagingServiceC:用于登台的url,serviceC的标头值

我怎么能避免这个？如果我可以选择多个环境作为活动状态,那将会很棒.然后我可以在"staging"和"serviceC"旁边放置一个复选标记.

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版作品在我们东方1,依此类推.

对于邮递员特有的解决方案:

您可以使用一些{{}}复杂的功能来增强某些环境.环境变量可以互相引用:

现在,当你在{{some-important-header}}某处引用环境变量时,它实际上会引用{{{{mode}}-some-important-header}},在这种情况下是{{test-some-important-header}},或-1.每次要更改模式时,都必须将环境变量值mode更改为正确的值,例如production,或staging.

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