Build a CI/CD pipeline for API Management

APIs have become mundane. They have become the de facto standard for connecting apps, data, and services. In the larger picture, APIs are driving digital transformation in organizations.

With the strategic value of APIs, a continuous integration (CI) and continuous deployment (CD) pipeline has become an important aspect of API development. It allows organizations to automate deployment of API changes without error-prone manual steps, detect issues earlier, and ultimately deliver value to end users faster.

This blog walks you through a conceptual framework for implementing a CI/CD pipeline for deploying changes to APIs published with Azure API Management.

The problem

Organizations today normally have multiple deployment environments (e.g., Development, Testing, Production) and use separate API Management instances for each environment. Some of these instances are shared by multiple development teams, who are responsible for different APIs with different release cadences.

As a result, customers often come to us with the following challenges:

• How to automate deployment of APIs into API Management?
• How to migrate configurations from one environment to another?
• How to avoid interference between different development teams who share the same API Management instance?

We believe the approach described below will address all these challenges.

CI/CD with API Management

The proposed approach is illustrated in the above picture. In this example, there are two deployment environments: Development and Production. Each has its own API Management instance. The Production instance is managed by a designated team, called API publishers. API developers only have access to the Development instance. 

The key in this proposed approach is to keep all configurations in Azure Resource Manager templates. These templates should be kept in a source control system. We will use Git as an example. As illustrated in the picture, there is a Publisher repository that contains all configurations of the Production API Management instance in a collection of templates:

• Service template: Contains all service-level configurations (e.g., pricing tier and custom domains).
• Shared templates: Contains shared resources throughout an API Management instance (e.g., groups, products, and identity providers).
• API templates: Includes configurations of APIs and their sub-resources (e.g., operations and policies).
• Master template: Ties everything together by linking to all templates.

API developers will fork and clone the Publisher repository. In most cases, they will focus on API templates for their APIs and should not change the shared or service templates.

When working with Resource Manager templates, we realize there are two challenges for API developers:

• First, API developers often work with Open API specifications and may not be familiar with Resource Manager schemas. To simplify creation of templates, we created a utility tool to automate the creation of API templates based on Open API specifications.
• Second, for customers who have already been using API Management, another challenge is how to extract existing configurations into Resource Manager templates. We created another tool to generate templates based on existing configurations.

Once developers have finished developing and testing an API, and have generated the API template, they will submit a pull request to the Publisher repository. API publishers can validate the pull request and make sure the changes are safe and compliant. Most of the validations can be automated as part of the CI/CD pipeline. When the changes are approved and merged successfully, API publishers will deploy them to the Production instance. The deployment can also be easily automated with Azure Pipelines.

With this approach, the deployment of API changes into API Management instances can be automated and it is easy to promote changes from one environment to another. Since different API development teams will be working on different sets of API templates, it also reduces the chances of interference between different teams.

Next steps

You can find the guidance, examples, and tools in this GitHub repository. Please give it a try and let us know your feedback and questions.

We realize our customers bring a wide range of engineering cultures and existing automation solutions. The approach and tools provided here are not meant to be a one-size-fits-all solution. That's why we published and open-sourced everything on GitHub, so that you can extend and customize the solution.

Source: Azure Blog Feed