CODEWITHSUNDEEP
postman
stianlagstad
stianlagstad

Reputation: 3302

How can I avoid "environment hell" in postman?

Say I have two environments (test and production) with two different URLs. I also have two services (serviceA and serviceB) that needs different header values. I could deal with this with four environments in Postman:

  1. testServiceA: url for test, header value for serviceA
  2. testServiceB: url for test, header value for serviceB
  3. productionServiceA: url for production, header value for serviceA
  4. productionServiceB: url for production, header value for serviceB

Here I have duplication of both the URLs and the headers. As I add another url, I need six environments in total:

  1. testServiceA: url for test, header value for serviceA
  2. testServiceB: url for test, header value for serviceB
  3. productionServiceA: url for production, header value for serviceA
  4. productionServiceB: url for production, header value for serviceB
  5. stagingServiceA: url for staging, header value for serviceA
  6. stagingServiceB: url for staging, header value for serviceB

And as I add another service which requires a changed header value, I need another 3:

  1. testServiceA: url for test, header value for serviceA
  2. testServiceB: url for test, header value for serviceB
  3. productionServiceA: url for production, header value for serviceA
  4. productionServiceB: url for production, header value for serviceB
  5. stagingServiceA: url for staging, header value for serviceA
  6. stagingServiceB: url for staging, header value for serviceB
  7. testServiceC: url for test, header value for serviceC
  8. productionServiceC: url for production, header value for serviceC
  9. stagingServiceC: url for staging, header value for serviceC

How can I avoid this? It would be great if I could choose multiple environments as active. Then I could place a checkmark next to "staging" and "serviceC" for example.

Upvotes: 19

Views: 984

Answers (1)

Jonathan Montane
Jonathan Montane

Reputation: 396

For a solution specific to Paw:

Paw makes has the concept of environment domains, which allows for easier control on your environment values. Basically an environment domain can have multiple environments, which are representations of the same environment value.

In your case, you could have 3 environments domains (serviceA, serviceB, serviceC), for which you would have 3 environments (test, staging, production)

Paw environment demo

In general, this allows for a lot of flexibility, as multiple environment domains can be used together in a single request. For instance, one could imagine a Server environment domain with different environments (us-east-1, us-west, ...), which could combine with, say a Version environment domain (v1.0, v1.1, v2.0, etc.), and combine them into a single request to check whether version 2.0 works on us-east-1, and so on.

For a solution specific to Postman:

You can use some {{}} intricacies to supercharge some environments. Environment variables can refer to each other:

Postman environment demo

Now, when you refer to the environment variable {{some-important-header}}somewhere, it will actually refer to the {{{{mode}}-some-important-header}}, which in this case is {{test-some-important-header}}, or -1. Every time you want to change mode, you have to change the environment variable value mode to the correct value, like production, or staging.

It's not cleanest solution, but it avoids creating a bunch of environments due to coupling.

Upvotes: 14

Related Questions