When deploying any code you want to validate it as much as you can before deploying. However with APIs in the APIM you can’t validate the XML Policy or the API logic until it is deployed into the API Management Service (APIM). This means you are limited to the options to validate the code, before checking into the main branch and deploying. In this post I go through some of the options with focus on my suggested design to deploy, validate and destroy the API each CI.
As mentioned, you can’t validate the APIM XML Policies locally, so when trying to test using multiple layers of policy from Products, APIs and Fragments, you need them in APIM to confirm they work. Most of the time engineers will just work directly in the Development APIM and alter the API in this environment. It works as we got everything deployed and the correct access, but you can’t trust the changes as others might have done changes not committed back to main branch. This also raised the issue of others trying to all work on the same API causing conflicts, then could all be wiped out with a deployment from the pipelines. This means the method will only really work if you have tight processes in place to work against these issues.
Ideally we want this as part of the Continuous Integration process, so during the Pull Request(PR) process we can validate the build of the API. This could work with the advancement of APIM Workspaces, as we could deploying a new Workspace during the PR which would be a fresh point in time deployment each time. The challenge with this method is time and money. Workspaces cost a lot to deploy and run, so when doing a few of these the bill can raise a lot and fast. We are also deploy close to a whole new APIM each time, so the deployment process just to validate one small change on an API is a lot, that begs the question is it worth it.
The recommended solution for me is to dynamically deploy each API during the Pull Request stage, but with suffixes appended to the name and URI to enable isolation for testing. This will only work well if your APIs are deployed in an isolated method. I talk about a recommended design for API Management Service in a Shared Design method in Shared Azure API Management Service Design — PR Code. This design demonstrates that each API would be in its own repository, so when we deploy it will only be the API we deploy. If you avoid this model then you will hit issues like the previous examples of too much to deploy, cost and time.
This approach enables the ability to deploy an isolated API version of the PR code, which can then be further developed in the APIM without impacting any other API. You can also test it in an isolated manner via its own URL, Testing features, debugging logs and XML policy validation. This also has 0 overhead cost other than processing power, that shouldn’t be much more than already implemented.
You will be required to consider as part of the Continuous Integration into Main to clean up the resources. With tools like GitHub you can trigger another Workflow on PR close, and with tools like Azure DevOps I would have a trigger on merge to Main to obtain the merged PR ID then delete the resource.
PR Code 