environment hierarchy and inheritance

[erikruser]

I have several postman environments that are very similar to one another, where they share the same set of variables with most having the same value but a few are different. But since environments are independent of one another, there is severe duplication and the environments rapidly get out of sync with one another.

It would be nice, therefore, to be able to specify that one environment inherits from another. I.E. if I am currently in environment A which inherits from environment B and refer to a variable {{foo}}, if foo is not defined in environment A it will look to see if it exists in environment B. If the variable is not defined in B but B inherits from C, it will look for the value in C, and so forth.

If I could do this, then I would only have to define those variables in environment A whose values differ from those in environment B and it will always stay in sync.

[vvs11]

@erikruser That's an interesting feature request. Could you help us understand your use-case for environments a bit more and how do you end up with so much duplication. Also, consider trying out collection variables if that could help you reduce the duplication of environments

[erikruser]

I have a service that I maintain. It has several other services that it depends on. My service lives in several different environments, e.g. Dev, Test, Staging, Prod. Dev is my personal environment. Test is a shared environment for my team, and Staging is shared by all teams. The owner of the downstream service has no interest in spinning up and maintaining an instance for every one of my environments. Instead, they spin up an instance for the shared Staging environment, and one general nonprod instance for other teams to interface with from their various nonprod environments. All services use bearer token for authentication. In all nonprod environments, since we are behind a firewall, the token is set to a common value that everybody knows for simplicity sake. It is obviously configured to a super secret secure value in production.

So in my collection, all of my requests have their values parameterized like POST {{downstreamService.host}}/path/to/endpoint POST {{myService.host}}/path/to/endpoint Authorization Bearer {{bearerToken}}

I have a postman environment defined for each of Dev, Test, Staging, and Prod. All 3 variables must exist in all 4 environments. The variable {{myService.host}} obviously has a different value in all 4 environments. {{downstreamService.host}} has the same value in the Dev and Test environments, and {{bearerToken}} has the same value in Dev, Test, and Staging.

As this is a large enterprise application, there are in fact far more than 3 nonprod environments and dozens of downstream services that are shared between different combinations of nonprod environments. So since every variable has to be copied to every environment, the reality is the duplication described above times several dozen.

[JohanOhlin]

At my work, we have several products, running in several environments (local, dev, qa, sandbox and prod) and different testing scenarios for each environment. Due to this, I currently need a long list of environments to swap between. Whenever I make changes to requests in my collections with new environment variables, I also need to go through all my environments to update accordingly, and that never gets done since I don’t have all new data available (I might need a new ID that I manually have to lookup for each environment). As a result, my environments won’t work when it’s time to use them, and I can’t see directly what properties are missing in them neither since new properties are added sporadically to environments as needed.

A solution that would work for us well would be if environments could be in a hierarchy, like this:

• Global (already exists today, but I can’ use it since we have different properties for different products)
• Product (web site 1, web site 2 etc)
• Environment (dev, qa, sandbox, prod etc)
• Scenario (already exists today)

Settings set on a lower level would override higher levels, as expected. I can’t imagine our company is the only one with such a need.

[ralphv]

Any work being done on this? Very important, makes things much easier. Similar to JMeter.

[vdkhvb]

Being able to set up a directory structure and a hierarchy of environments to put them in would be useful for us too.

[sixeyes]

As I've started to use environments, they've come to be very useful, but I now have 30+ environments, the more I create, the harder it is to manage.

I found this issue because I was hoping for a simple hierarchy to help me manage the growth in environments. I'd not thought about an inheritance hierarchy, but I could use this too.