News Blog /

How ISVs can Build a CI/CD pipeline for API Management

by Spanish Point - Dec 17, 2020
How ISVs can Build a CI/CD pipeline for API Management

Application Programming Interfaces have become the default case for connecting apps, data, and services. APIs are driving digital transformation for many ISVs.

Azure Pipelines is the Continuous Integration and Continuous Delivery (CI/CD) solution for any language, application, or platform. Independent Software Vendors can use it for both enhanced CI/CD functionality, and as a dedicated CI/CD service to use in their DevOps toolchains.

A continuous integration (CI) and continuous deployment (CD) pipeline has become an important aspect of API development. It allows organisations like ISVs, to automate deployment of changes without manual steps, detect issues earlier, and ultimately deliver value to end users faster.

Azure DevOps provides the CI/CD pipeline, starting with a Git repository for managing your application source code and infrastructure code (Azure Resource Manager templates), a Built system for producing packages and other built artefacts, and a Release Management system for setting up a pipeline to deploy your changes through dev, test and production environments.

The problem

ISVs often have multiple deployment environments (e.g., Development, Testing, Production) and use separate API Management instances for each environment. Some of these instances are shared across different teams, who are responsible for different APIs.

As a result, they often face a number of challenges:

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

CI/CD with API Management

CI-CD with API Management workflow graph

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.
  • Shared templates: Contains shared resources throughout an API Management instance.
  • API templates: Includes configurations of APIs and their sub-resources.
  • 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.

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 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. It also reduces the chances of interference between different teams if different API development teams work on different templates.

Want to learn more about Azure DevOps and Application Developement?

Sign up to our upcoming webinar and learn more:

Advantage Of Azure Devops V3


Contact us for a free consultation!