API Management Made Easier with a CI/CD Pipeline

APIs have become humdrum. They have established themselves as the de facto standard for linking data, apps, and services. From a bigger perspective, APIs are driving digital change in enterprises.

A combination of continuous integration (CI) pipeline and continuous deployment (CD) pipeline has become a key part of API development given the strategic significance of APIs. It enables enterprises to automate API update deployments without relying on error-prone manual methods, spot issues early, and ultimately provide value to end users faster.

This blog outlines a conceptual architecture for constructing a CI/CD pipeline for delivering API updates.

The Concern

Today, most organizations have numerous deployment environments (e.g., development, testing, and production) and employ distinct API management instances for each. Some of these instances are shared by numerous development teams, each of which is in charge of a distinct API with a different release cycle.

As a result, consumers frequently seek help for the following issues:

 • How can I automate API deployment into API Management?
 • How can configurations be moved from one environment to another?
 • How can various development teams that use the same API management instance avoid interfering with each other?

Solutions to the Identified Issues

There are two deployment environments, development and production. Each has its own instance of API management. The production instance is managed by a specialized team of API publishers, while the development instance is accessible to API developers.

The key to this proposed solution is that all configurations are kept in resource manager templates that should be stored in a version control system. A good example is Git. A publisher repository provides all production API management instance configurations as templates:

 • Service template: All service-level settings are included in the service template (e.g., pricing tier and custom domains).
 • Shared templates: Contains resources that are used across an API Management instance (e.g., groups, products, and identity providers).
 • API templates: API setups and sub-resources are included (e.g., operations and policies).
 • Master template: Connects everything by connecting to all templates.

API developers will fork and clone the publisher repository. Most of the time, they will concentrate on API templates for their APIs and should not alter the shared or service templates.

Working with resource manager templates reveals two issues for API developers:

 •First and foremost, API developers frequently work with Open API requirements and may be unfamiliar with resource manager schemas. A utility application that automates the production of API templates based on Open API guidelines comes in handy in making the whole process of template development easier.
 •Second, another problem for clients who have previously used API management is figuring out how to extract old configurations into resource manager templates. Luckily, there're tools developed to produce templates based on current setups.