Multiple Environment per Instance
If you want your users to see the documentation in production, but "Try It" in your staging environment we'd have to deploy a separate APIM instance and manage content in both.
Below is a brain dump of how I imagine this feature could be used in various aspects of the APIM solution.
apiminstance.azure-api.net < this would be the primary
environment.apiminstance.azure-api.net < this would be the environment specific or a custom domain per environment
There would be no environment.apiminstance.portal.azure-api.net site
Also if we could set the default environment to use for the Try It button that'd be fantastic.
Each environment should have its own set of properties so we could clone the live site properties but change things like backend urls or auth providers, etc.
The APIs and operations should be defined for all environments but provide the option to disable/enable an API in a specific environment. E.g. rollout a new beta API/operation to a specific environment.
Subscriptions should be for all environments.
A product should be able to target specific or all environments so that a product for Beta Testers would be defined to give them access to a Beta environment that may expose new APIs or functionality in that environment.
John Ha commented
Has there been any update to this being under review? Is there currently a workaround aside from spinning up multiple APIM instances per environment? For example, maybe have a policy that checks which Product the user is subscribed to and allows us to return a regular response or mock response. Though this would still be a workaround for the desired multiple environment per instance solution.
I would like to get a hook in this trade, what would be the best way to work with dev / test and production environments? Because we are starting to implement the solution, and we would like the best practices!
Adam Weigert commented
Yes. We are moving from an APIM instance per environment to a developer instance and a production instance. We are using products to manage the environment relationship and policies in the product scope to change the backend systems. This is fairly cumbersome with multiple products, e.g. consumers and then needing 1 to N versions of that product, one for each environment.
The con of this approach is that we don't really have a good test bed for trying changes outside of the developers unless we let the other developer teams use the developer instance, which is not what we want as it impacts their stability during their development efforts.
What this model does help us do is be much better about the changes since the changes could impact production. Things like understanding the impact on changes to APIs and the need for versioning as well as better test plans for the dev instance are necessary for success instead of nice to haves.
Thank you, Adam. Would you still want support for multiple environments within a single service instance if we provide ability to effortlessly copy configuration between service instances?